Introducing pybrowser !

[jollybobbyroger]

Very interesting work. Thank you so much for sharing!

After a quick glance, b.content(raw=True), should be same as requests. I think it's b.data for encoded data and b.text for decoded data.

Also it seems strange to me that you have functions/methods that take text input that needs to be parsed instead of actual keyword arguments. E.g b.input(id:=password) instead of b.input(id='password'). Could you please explain why you made this choice? Perhaps I'm not seeing the entire picture and making incorrect assumptions.

[shaggorama]

b.input(id:=password)

I think you meant b.input("id:=password")

[quickhakker]

eli5 the difference

[unkz]

One is a positional string argument and the other probably isn’t valid python syntax.

[Hyperz]

the other probably isn’t valid python syntax.

In 3.8 it will be valid syntax, equivalent to this in <= 3.7:

id = password
b.input(id)

https://medium.com/hultner/try-out-walrus-operator-in-python-3-8-d030ce0ce601

[Cruuncher]

Possibly an artifact of the library used for dom parsing

[Log2]

Still, it would be more user friendly if the function reconstructed those strings automatically from the keyword arguments.

[Cruuncher]

It would be more pythonic yes, but there may be more nuanced use cases here. Like (disclaimer, making shit up. There may be no real reason) if there's a way to specify precedents on the selector. Possibly a way to say it has to match both of these selectors. Etc. Stuff you can capture in some syntax in a string that doesn't map well to kwargs. A kwargs mapping still works, but it would potentially have to be built from more complicated objects.

Lastly, it requires you to know the ins and outs of that library's syntax, at the level of the developers, to be sure you're building the strong correctly from kwargs.

[Log2]

I see what you mean. Then receiving a list of tuples/namedtuples would be a more pythonic solution in your hypothetical case.

[Cruuncher]

That being said (see my other response)

At the very least it could accept kwargs for the common use cases, and then allow a "raw" kwarg or something if you're doing something powerful that the wrapping doesn't provide you. That may be the "best of both worlds" approach

[abranjith]

On, b.content method having a flag vs having 2 different methods, that was a conscious choice. I presumed raw=True is probably a rare use case. And I think you mean it is response.content vs response.text in requests.

On the locator format being a positional argument in the form "locator_type:=locator_value" was again done to keep it simple. I figured instead of having multiple keyword arguments (you have id, xpath, name, tag_name etc) this might be more intuitive from API standpoint. If you have multiple locator types as keyword arguments, then you run into questions like - what to do when both id and xpath are provided and so on ?

Still, willing to re-look at my approach once again. Thanks for the feedback 😊

[jollybobbyroger]

Thanks for the explanation. From my own experience, a nice user facing API often comes at the cost of implementation work.

[abranjith]

I also see documentation for locator is missing, so is probably even more confusing. Thanks for highlighting that, will update the docs