Skip to content
This repository has been archived by the owner on Mar 23, 2023. It is now read-only.

Decide on an interface #3

Open
snarisi opened this issue Mar 1, 2019 · 3 comments
Open

Decide on an interface #3

snarisi opened this issue Mar 1, 2019 · 3 comments

Comments

@snarisi
Copy link
Contributor

snarisi commented Mar 1, 2019

I haven't been very consistent so far but most have followed the puppeteer API, but with snake casing and using kwargs insteads of options dicts. We should clean this up and decide whether to

  • mimic the puppeteer interface exactly,
  • make a "pythonic" version of the puppeteer interface, or
  • do something else entirely

cc @spulec @annieholladay @psarma89

@spulec
Copy link

spulec commented Mar 4, 2019

My vote is to start with a pythonic version as step 1 that matches existing puppeteer functionality.

As step 2, I think it may make sense to add a higher-level abstraction above it to simplify things.

@annieholladay
Copy link

I think i'd agree with steve to make it pythonic. since this is supposed to be a python interface to puppeteer it probably shouldnt matter to puppy's api what puppeteer was written with or it's conventions

@psarma89
Copy link

I would agree with the pythonic version, I think trying to mimic puppeteer interface (pypeteer) was confusing in development and in usage for our current ypuppet implementation. Edge cases came up especially with the snake casing and kwargs that I would prefer not to repeat.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants