[Python-Dev] Fwd: Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Sasha Kacanski]

-- Forwarded message -
From: Sasha Kacanski 
Date: Wed, Mar 30, 2022, 2:55 PM
Subject: Re: [Python-Dev] Re: Are "Batteries Included" still a Good Thing?
[was: It's now time to deprecate the stdlib urllib module]
To: Paul Moore 
Cc: Christopher Barker , Ethan Furman <
et...@stoneleaf.us>, Python Dev 


Agree with Paul,
Best of python always was, you can do almost everything with standard libs,
but then novice becomes better developer and starts exploring libs and
tools that wrap stuff or perform better or has functionality that stdlib
does not support right of the bet they start using variety of libs that
suits their needs.
Regards,
Sasha


On Sun, Mar 27, 2022, 8:06 PM Paul Moore  wrote:

> On Sun, 27 Mar 2022 at 17:11, Christopher Barker 
> wrote:
> >
> > With the json package included, all they need to do is `import json`. If
> that wasn't there, they's look in PyPi for a JSON implementation, and find
> an absolutely astonishing number of options. I just did a search for "JSON"
> >  on PYPI, and it's HUGE -- most of them are for specialized JSON-using
> protocols of some sort. I was actually really surprised that couple I know
> about of the top of my head (ujson, orjson) are actually hard to find.
> >
> > "You can just pip install it" is really not a good solution.
> >
> > In fact, this is an example, I think, of where we should put some effort
> into making the included batteries better -- it's great to have a JSON lib
> built in, but it's too bad that it's not best-of-bread by pretty much any
> definition (speed, memory performance, flexibility) -- there are quite a
> few feature requests open for it -- it would be nice to actually implement
> some of those. (but yes, that's a lot of work that someone(s) would have to
> do)
> >
> > Back to the topic at hand, rather than remove urllib, maybe it could be
> made better -- an as-easy-to-use-as-requests package in the stdlib would be
> really great.
>
> I think that's where the mistake happens, though. Someone who needs
> "best of breed" is motivated (and likely knowledgeable enough) to make
> informed decisions about what's on PyPI. But someone who just wants to
> get the job done probably doesn't - and that's the audience for the
> stdlib. A stdlib module needs to be a good, reliable set of basic
> functionality that non-experts can use successfully. There can be
> better libraries on PyPI, but that doesn't mean the stdlib module is
> unnecessary, nor does it mean that the stdlib has to match the PyPI
> library feature for feature.
>
> So here, specifically, I'd rather see urlllib be the best urlllib it
> can be, and not demand that it turn into requests. Requests is there
> if people need/want it (as is httpx, and urllib3, and aiohttp). But
> urllib is for people who want to get a file from the web, and *not*
> have to deal with dependencies, 3rd party libraries, etc.
>
> The "batteries included" standard library and PyPI complement each
> other. Neither is redundant, and neither implies the other is
> unnecessary.
>
> Paul
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/E2FGXTYOEYLC6GSJGMWBQKHOO62LZPHQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3LOIPKKY73KDH526SKLXJX4FGBCEQMLH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Declarative imports

[Sasha Kacanski]

To me Steve nailed it... static type checker = lean and mean...

On Fri, Apr 8, 2022, 5:03 AM Steven D'Aprano  wrote:

> On Fri, Apr 08, 2022 at 08:24:40AM +, Malthe wrote:
>
> > But firstly, let me present the idea. It is very simple, that Python
> > should have declarative imports,
>
> I'm not sure I understand why you consider this "declarative".
>
> https://en.wikipedia.org/wiki/Declarative_programming
>
> As I see it, this proposal merely adds a unary operator for implicit
> imports.
>
>
>
> > For example, `some_regex = @re.compile(...)`.
> >
> > What happens then is that before anything else in that module, that
> > symbol is imported:
> >
> > from re import compile as _mangled_re_compile
> >
> > It must be the very first thing (hoisting) because when else would it
> > happen?
>
> On-demand. As you say yourself, this could be a dynamic import at the
> time of use.
>
>
> > It's been suggested before to have a shorthand syntax which
> > does a dynamic import at the time of using it but this brings me to
> > the twist:
> >
> > We want typing to pick up these imports.
>
> At the moment static type checkers have to look for two import
> statements: `import spam`, and `from spam import eggs`.
>
>
> With this proposal, they will still need to look for those two import
> statements, but they will also need to parse every expression looking
> for `@` as a unary operator:
>
> result = 2*x**3 - 3*y + @math.sin(x*y) - 5*x*y**2
>
> This does not help typing at all. It just means the type-checker has to
> do more work to recognise imports.
>
>
>
> > And this twist has a second
> > leg which is that we often need to import symbols simply in order to
> > type some argument type or return type. This leads to a great many
> > more imports to type.
>
> Code is read much more than it is written. I would much prefer to have
> explicit imports (by convention, if not necessity) in one place at the
> top of the page, than to mystery symbols where the implicit import could
> be buried far away.
>
> Right now, this is an error:
>
> # Start of module.
> obj = wibble.foo
>
> because wibble is not a built-in nor a global (excluding weird
> shenanigans committed by other modules), so the name "wibble" doesn't
> exist. But with hoisting, that import could be *anywhere* in the file.
> Even in dead code.
>
> # Start of module.
> obj = wibble.foo
> ...
> ...
> # five pages of code later
> for a in obj.method():
> while flag:
> if condition:
> @wibble
>
> That's right, with hoisting you can use a module before you import it.
> Mind. Blown.
>
> Have pity on beginners, casual Python programmers, and the people who
> have to help them. Don't implement this horror.
>
> If it were merely on-demand imports, then we would know that the import
> @wibble would have to appear in actual, executed code before you can use
> wibble. But with hoisting, we don't even have that promise.
>
> It is truly spooky action at a distance. And to save nothing but an
> import line.
>
>
> > A situation where this would come in really handy is in scripting such
> > as how we use Python in Apache Airflow to let users write out simple
> > workflows. A workflow definition which could be a 5-liner quickly
> > becomes a 20-liner – consider for example:
> >
> > default_args = {
> > "start_date": @datetime.datetime(...)
> > }
>
> That's just a three-liner, which becomes a four-liner:
>
> import datetime
> default_args = {
> "start_date": datetime.datetime(...)
> }
>
>
>
> --
> Steve
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/GILL25XYSAPF4FN7LTZC7XLDB7ZX4E4Y/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PVOJ74BCX6YA5L5ZCIHGXT6STKRNK4AI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

[Sasha Kacanski]

Why you don't simplify with api A,B,C and  forth and then follows
explanation ofr what is stable, unstable, semi... So forth

On Wed, May 4, 2022, 6:10 AM Petr Viktorin  wrote:

>
>
> On 29. 04. 22 19:02, Guido van Rossum wrote:
> > On Fri, Apr 29, 2022 at 10:15 AM Petr Viktorin  > > wrote:
> >
> > On 29. 04. 22 16:32, Victor Stinner wrote:
> >  > Ok, let me start with the serious business: API name.
> >  >
> >  > I'm not comfortable with "semi-stable". Python already has a
> "limited
> >  > API" and a "stable ABI". Just by its name, it's unclear what
> >  > "semi-stable" means.
> [...]
> > Nick Coghlan argued against that term:
> [...]
> > But I also like “unstable” better than “semi-stable”. Splitting the
> > internals into “private”/“internal” and “unstable” seems reasonable.
> >
> >
> > I think picking "semi-stable" would be giving in to the OCD nerd in all
> > of us. :-) While perhaps technically less precise, "unstable" is the
> > catchy name with the right association. (And yes, we should keep it
> > stable within bugfix releases, but the name doesn't need to reflect that
> > detail.) The "internal API" isn't an API at all (except for CPython core
> > developers and contributors). The "unstable API" would definitely be an
> > *API* for users outside the core.
> >
> > So let's please go with "unstable".
>
>
> Thanks, you worded that perfectly!
>
> Alright, the PEP now uses “unstable” rather than “semi-stable”. And I
> don't see any issues with the technical details, so I'll see if it can
> still get into Python 3.11. Hopefully Pablo agrees as the Release Manager.
> Thanks for the discussion, everyone!
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/L6IGXJ5OM2GHAFTAEWWB35STT3MBQL2J/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/R64ZKXIU55Q27ES76I3GAYEZLU2CLHF4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

[Sasha Kacanski]

I understand issues and welcome any discussions. For that matter I do not
rush to conclusions. I am not expert in C and Python as the rest of the
folks on this list
but I am pretty good with Python itself. I just suggested naming to be as
simple as possible for all relevant API's including full descriptions in
the code base regarding stable, semi-stable, unstable and so forth. I do
that in my projects with Python libraries I write ...
Sorry for intruding and possibly  clouding the email thread...
Regards,




On Wed, Jun 1, 2022, 4:39 AM Stephen J. Turnbull 
wrote:

> Sasha Kacanski writes:
>
>  > Why you don't simplify with api A,B,C and  forth and then follows
>  > explanation ofr what is stable, unstable, semi... So forth
>
> This is exactly what they're hammering out.  It's not easy for several
> reasons, chief of which is that in each case the boundary is a matter
> of opinion as to the balance among what is most convenient for the
> developers of Python itself, the developers of separately distributed
> C/C++ modules, and for existing modules that were developed before the
> divisions were set and would need to either be changed or to risk
> API incompatibility with future versions of Python.  The nomenclature
> also matters, as individual programmers have various ideas about the
> meaning of terms like "stable", and we want as much agreement as
> possible that the "stable API" is "stable enough", and so on.
>
> If you have specific ideas about which APIs belong where, feel free to
> bring them forward.  But this is not a process that should be rushed
> nor would anyone benefit from pushing it forward more quickly.
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CEYYEGJAYV2O5OC7KUP6D3UH5WORFWS7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Mixed Python/C debugging

[Sasha Kacanski]

Same here, I do Pycharm and it is possible to add clion plugin and go
through C code ...

On Mon, Dec 2, 2019 at 8:34 AM Fabio Zadrozny  wrote:

> Hi Skip,
>
> I just wanted to note that what I usually do in this case is having 2
> debuggers attached.
>
> i.e.: start one any way you want and then do an attach to from the other
> debugger -- in my case as I'm usually on the Python side I usually start
> the Python debugger and then do an attach to from the C++ IDE, but you can
> probably do it the other way around too :)
>
> On Sun, Dec 1, 2019 at 1:57 PM Skip Montanaro 
> wrote:
>
>> Having tried comp.lang.python with no response, I turn here...
>>
>> After at least ten years away from Python's run-time interpreter &
>> byte code compiler, I'm getting set to familiarize myself with that
>> again. This will, I think, entail debugging a mixed Python/C
>> environment. I'm an Emacs user and am aware that GDB since 7.0 has
>> support for debugging at the Python code level. Is Emacs+GDB my best
>> bet? Are there any Python IDEs which support C-level breakpoints and
>> debugging?
>>
>> Thanks,
>>
>> Skip
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/L2KBZM64MYPXIITN4UU3X6L4PZS2YRTB/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ZJOFXW2K42YUMP3MQY6POBLRJKMU2BLU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Aleksandar Kacanski
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AJ2CBQDHOALBBK3F6YCJ42V34SF6HH3K/
Code of Conduct: http://python.org/psf/codeofconduct/