[Python-Dev] Re: The Default for python -X frozen_modules.

2021-09-27 Thread Brett Cannon
On Mon, Sep 27, 2021 at 9:54 AM Eric Snow 
wrote:

> We've frozen most of the stdlib modules imported during "python -c
> pass" [1][2], to make startup a bit faster.  Import of those modules
> is controlled by "-X frozen_modules=[on|off]".  Currently it defaults
> to "off" but we'd like to default to "on".  The blocker is the impact
> on contributors.  I expect many will make changes to a stdlib module
> and then puzzle over why those changes aren't getting used.  That's an
> annoyance we can avoid, which is the point of this thread.
>
> Possible solutions:
>
> 1. always default to "on" (the annoyance for contributors isn't big
> enough?)
> 2. default to "on" if it's a PGO build (and "off" otherwise)
> 3. default to "on" unless running from the source tree
>
> Thoughts?
>

What about opting out when `--with-pydebug` is used? I'm not sure how many
people actively develop in a non-debug build other than testing something,
but at that point I would be having to run `make` probably anyway for
whatever I'm mucking with if it's *that* influenced by a debug build.
___
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/PYX65WVG5ICXEBIY5ZDLDFAJHDU56HLA/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

2021-09-27 Thread Brett Cannon
On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev <
python-dev@python.org> wrote:

> On 26/09/2021 05:21, Steven D'Aprano wrote:
>
> [snip]
>


> > These are not rhetorical questions, I genuinely do not know. I *think*
> > that there was an attempt to make a stable C API back in 3.2 days:
> >
> > https://www.python.org/dev/peps/pep-0384/
> >
> > but I don't know what difference it has made to extension writers in
> > practice. From your description, it sounds like perhaps not as big a
> > difference as we would have liked.
> >
> > Maybe extension writers are not using the stable C API? Is that even
> > possible? Please excuse my ignorance.
>
> PyQt has used the stable ABI for many years. The main reason for using
> it is to reduce the number of wheels. The PyQt ecosystem currently
> contains 15 PyPI projects across 4 platforms supporting 5 Python
> versions (including v3.10). Without the stable ABI a new release would
> require 300 wheels. With the stable ABI it is a more manageable 60
> wheels.
>
> However the stable ABI is still a second class citizen as it is still
> not possible (AFAIK) to specify a wheel name that doesn't need to
> explicitly include each supported Python version (rather than a minimum
> stable ABI version).
>

Actually you can do this. The list of compatible wheels for a platform
starts at CPython 3.2 when the stable ABI was introduced and goes forward
to the version of Python you are running. So you can build a wheel file
that targets the oldest version of CPython that you are targeting and its
version of the stable ABI and it is considered forward compatible. See
`python -m pip debug --verbose` for the complete list of wheel tags that
are supported for an interpreter.
___
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/E4EA6GW6N5NREEBM4QOA7GTLBGTGD4AV/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: f-strings in the grammar

2021-09-20 Thread Brett Cannon
On Mon, Sep 20, 2021 at 8:58 AM Thomas Grainger  wrote:

> I don't think the python syntax should be beholden to syntax highlighting
> tools, eventually some syntax feature that PEG enables will require every
> parser or highlighter to switch to a similar or more powerful parse tool
>

But that's not how syntax highlighting works in editors. You typically
don't get to choose the parsing tool used for syntax highlighting, you just
define the grammar using whatever is provided by the editor (which has
always been regexes based on my experience). So there's no way to "require"
every editor out there to switch to a PEG parser or equivalent to support
Python's grammar because that's asking every editor to change how syntax
highlighting is implemented at a lower level.

Having said all that, I think as long as we understand that this is a
side-effect then it's fine; syntax highlighting is usually not tied to
semantics in an editor so it shouldn't be a blocker on this. If people care
they simply won't use the same type of quotes in their code (which I bet is
what most people will do unless Black says otherwise ).

But I also think this means we definitely have to get a parser module for
tools together as this is way more potential breakage than just parentheses
for `with` statements and I don't know if formatting tools can just move to
the AST module at that point. 
___
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/I4POAK22LZW4RNFGFFKQ6BILRLCSQO2I/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

2021-09-20 Thread Brett Cannon
On Sun, Sep 19, 2021 at 8:15 AM Steve Holden  wrote:

> I understood that _iterables_ are required to have an __iter__ method, not
> iterators.
>
> Therefore, are we simply discussing whether all iterators should be
> iterable?
>

At this point it's more about how to document this.


> At the moment the CPython implementation does't require that AFAIK.
>

Correct. I plan to go through the docs and clarify things. I opened
https://bugs.python.org/issue45250 to track this.


>
> regards
>  Steve
>
> On Tue, Sep 14, 2021 at 8:39 PM Guido van Rossum  wrote:
>
>> My view of this is:
>>
>> A. It's not an iterator if it doesn't define `__next__`.
>>
>> B. It is strongly recommended that iterators also define `__iter__`.
>>
>> In "standards" language, I think (A) is MUST and (B) is merely OUGHT or
>> maybe SHOULD.
>>
>> On Tue, Sep 14, 2021 at 12:30 PM Brett Cannon  wrote:
>>
>>> Over in https://github.com/python/typeshed/issues/6030 I have managed
>>> to kick up a discussion over what exactly an "iterator" is. If you look at
>>> https://docs.python.org/3/library/functions.html#iter you will see the
>>> docs say it "Return[s] an iterator
>>> <https://docs.python.org/3/glossary.html#term-iterator> object." Great,
>>> but you go the glossary definition of "iterator" at
>>> https://docs.python.org/3/glossary.html#term-iterator you will see it
>>> says "[i]terators are required to have an __iter__()
>>> <https://docs.python.org/3/reference/datamodel.html#object.__iter__>
>>> method" which neither `for` nor `iter()` actually enforce.
>>>
>>> Is there something to do here? Do we loosen the definition of "iterator"
>>> to say they *should* define __iter__? Leave it as-is with an
>>> understanding that we know that it's technically inaccurate for iter() but
>>> that we want to encourage people to define __iter__? I'm assuming people
>>> don't want to change `for` and `iter()` to start requiring __iter__ be
>>> defined if we decided to go down the "remove the __aiter__ requirement"
>>> from aiter() last week.
>>>
>>> BTW all of this applies to async iterators as well.
>>> ___
>>> 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/3W7TDX5KNVQVGT5CUHBK33M7VNTP25DZ/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> *Pronouns: he/him **(why is my pronoun here?)*
>> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>> ___
>> 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/OICGRBPLXO6WXO4CHTGUK46WIHO7PDUU/
>> 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/KHDMNMW6XEPYOZ5AQ22AN6YTN2POMHQE/
> 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/WHUPQJQAKMKSOR54PCSWQQYYKLJ5ZKZS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Discussion about how to manage additions/removals to the stdlib

2021-09-16 Thread Brett Cannon
https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681

This comes from my language summit talk on the stdlib to help clarify some
things about how we manage the stdlib from the perspective of
additions/deletions.

FYI I will be *muting this email thread immediately*, so please participate
on discuss.python.org if you have anything to say (I almost didn't post
here, but I figured I would see if there's any chance people will follow
through on discuss.python.org if directed there and told feedback here will
be ignored).
___
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/KB2CLR6Q2NVSPA2WR4KPP2S4ITOMAHMS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

2021-09-16 Thread Brett Cannon
On Wed, Sep 15, 2021 at 4:06 PM Guido van Rossum  wrote:

> [SNIP]
> Reminder about how for-loops work:
>
> This:
>
> for x in seq:
> 
>
> translates (roughly) to this:
>
> _it = iter(seq)
> while True:
> try:
> x = next(_it)
> except StopIteration:
> break
> 
>

And if anyone wants more details on this, I have a blog post about it at
https://snarky.ca/unravelling-for-statements/ .
___
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/5C7IIVHYX6A25ERQT4RJ3MM6AOXZVBAZ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Should the definition of an "(async) iterator" include __iter__?

2021-09-14 Thread Brett Cannon
Over in https://github.com/python/typeshed/issues/6030 I have managed to
kick up a discussion over what exactly an "iterator" is. If you look at
https://docs.python.org/3/library/functions.html#iter you will see the docs
say it "Return[s] an iterator
 object." Great, but
you go the glossary definition of "iterator" at
https://docs.python.org/3/glossary.html#term-iterator you will see it says
"[i]terators are required to have an __iter__()

method" which neither `for` nor `iter()` actually enforce.

Is there something to do here? Do we loosen the definition of "iterator" to
say they *should* define __iter__? Leave it as-is with an understanding
that we know that it's technically inaccurate for iter() but that we want
to encourage people to define __iter__? I'm assuming people don't want to
change `for` and `iter()` to start requiring __iter__ be defined if we
decided to go down the "remove the __aiter__ requirement" from aiter() last
week.

BTW all of this applies to async iterators as well.
___
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/3W7TDX5KNVQVGT5CUHBK33M7VNTP25DZ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: A better way to freeze modules

2021-09-13 Thread Brett Cannon
On Sat, Sep 11, 2021 at 7:08 PM Gregory Szorc 
wrote:

> Thanks for all the replies, everyone! I'll reply to a few comments
> individually. But I first wanted to address the common theme around
> zipimport.
>
> First, one idea that nobody mentioned (and came to me after reading the
> replies) was to possibly leverage zipimport for freezing the standard
> library instead of extending the frozen importer. I strongly feel this
> option is preferable to extending the frozen importer with additional
> functionality. I suspect the Python core developers would prefer to close
> importer feature gaps / bugs with zipimport over the frozen importer. And
> since zipimport is actually usable without having to build your own
> binaries, improvements to zipimport would more significantly benefit the
> larger Python ecosystem. If zipimporter gained the ability to open a zip
> archive residing in a memory address or a PyObject implementing the buffer
> protocol, [parts of] the standard library could be persisted as a zip file
> in libpython and the frozen importer would be limited to bootstrapping the
> import subsystem, just like it is today. This avoids adding additional
> complexity (like supporting __file__ and __cached__) to the frozen
> importer. And it keeps the standard library using a commonly-used importer
> in the standard library, just like it is today with PathFinder.
>
> Onto the bigger question that can be summarized as "why not use zipimport:
> why do we need something different?" I sympathize with this reasoning.
> zipimport exists, it is functional, and it is widely used and has
> demonstrated value.
>
> Performance is a major reason to build something better than zipimport.
>
> I response to your replies, I implemented a handful of benchmarks for
> oxidized_importer and also implemented a pure Rust implementation of a zip
> file importer to collect some hard data. You can reproduce my results by
> cloning https://github.com/indygreg/PyOxidizer.git and running `cargo
> bench -p pyembed-bench`. At time of writing, the benchmarks materialize the
> full standard library on the filesystem, in a zip archive (with no
> compression), and in the "Python packed resources" format. It then fires up
> a Python interpreter and imports ~450 modules comprising the standard
> library. I encourage you to obtain your own numbers and look at the
> benchmark code to better understand testing methodology. But here are some
> results from Linux on my Ryzen 5950x.
>
> * zipimporter is slower than PathFinder to import the entirety of the
> standard library when the disk cache is hot. 201.81ms for zipimporter vs
> 174.06ms for PathFinder.
> * My pure Rust zip importer is faster than zipimporter and PathFinder for
> the same operation. 161.67ms when reading zip data from memory; 164.45ms
> when using buffered filesystem I/O (8kb read operations).
> * OxidizedFinder + Python packed resources are the fastest of all.
> 121.07ms loading from memory.
> * Parsing/indexing the container formats is fast in Rust. Python packed
> resources parses in 107.69us and indexes in 200.52us (0.2ms). A zip archive
> table of contents is parsed in 809.61us and indexes in 1.205ms. If that
> same zip archive is read/seeked using filesystem I/O, the numbers go up to
> 4.6768ms and 5.1591ms.
> * Starting and finalizing a Python interpreter takes 11.930ms with
> PathFinder and 4.8887ms with OxidizedFinder.
>

Now this is for importing 450 modules, correct? My suspicion is that import
load for something that's start-up sensitive is not common. While there's
an obvious performance difference between e.g. 202ms and 174ms, that may be
at the extreme end. If you assume average import time per module and you
assume about 100 modules imported then the difference is 45ms versus 39ms
which is negligible. So while I appreciate the collection of these numbers
and seeing there's room for improvement, I also don't think it's best for
us to focus on the worst-case scenario.


>
> I won't post the full set of numbers for Windows, but they are generally
> higher, especially if filesystem I/O is involved. PathFinder is still
> faster than zipimporter, however. And zipimporter's relative slowness
> compared to OxidizedFinder is more pronounced.
>
> There are many interesting takeaways from these numbers. But here are what
> I think are the most important:
>
> * The Rust implementation of a zip importer trouncing performance of
> zipimporter probably means zipimporter could be made a lot faster (I didn't
> profile to measure why zipimporter is so slow. But I suspect its
> performance is hindered by being implemented in Python.)
>

Being implemented in Python is very much on purpose for zipimporter as it
used to be in C and no one wanted to work on it then. Having it in Python
has made tweaking how it functions much easier.


> * OxidizedFinder + Python packed resources are still significantly faster
> than the next fastest solution (Rust implemented zip importer).
>

I 

[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

2021-09-08 Thread Brett Cannon
On Wed, Sep 8, 2021 at 12:49 PM Yury Selivanov  wrote:

> We have already merged it, the fix is part of the rc2.
>

Thanks! (If we were on Discourse I would have left a ♥ instead )


>
> yury
>
>
> On Wed, Sep 8 2021 at 12:48 PM, Brett Cannon  wrote:
>
>> On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov 
>> wrote:
>>
>>> Comments inlined:
>>>
>>> On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum 
>>> wrote:
>>>
>>>> First of all, we should ping Yury, who implemented `async for` about 6
>>>> years ago (see PEP 492), and Joshua Bronson, who implemented aiter() and
>>>> anext() about 5 months ago (see https://bugs.python.org/issue31861).
>>>> I've CC'ed them here.
>>>>
>>>
>>> Looks like PyAiter_Check was added along with the aiter/anext builtins.
>>> I agree it's unnecessary to check for __aiter__ in it, so I let's just fix
>>> it.
>>>
>>>
>>>
>>>>
>>>> My own view:
>>>>
>>>> A. iter() doesn't check that the thing returned implements __next__,
>>>> because it's not needed -- iterators having an __iter__ methor is a
>>>> convention, not a requirement.
>>>>
>>>
>>> Yeah.
>>>
>>>
>>>> You shouldn't implement __iter__ returning something that doesn't
>>>> implement __iter__ itself, because then "for x in iter(a)" would fail even
>>>> though "for x in a" works. But you get an error, and anyone who implements
>>>> something like that (or uses it) deserves what they get. People know about
>>>> this convention and the ABC enforces it, so in practice it will be very
>>>> rare that someone gets bitten by this.
>>>>
>>>> B. aiter() shouldn't need to check either, for exactly the same reason.
>>>> I *suspect* (but do not know) that the extra check for the presence of
>>>> __iter__ is simply an attempt by the implementer to enforce the convention.
>>>> There is no *need* other than ensuring that "async for x in aiter(a)" works
>>>> when "async for x in a" works.
>>>>
>>>
>>> I agree.
>>>
>>
>> [SNIP]
>>
>>
>>
>>> Bottom line: let's fix PyAiter_Check to only look for __anext__. It's a
>>> new function so we can still fix it to reflect PyIter_Check and not worry
>>> about anything.
>>>
>>
>> I don't know if Pablo wants such a change in 3.10 since we are at rc2 at
>> this point, so this might have to wait for 3.11 (although there's no
>> deprecation here since it's a loosening of requirements so it could go in
>> straight away).
>>
>
___
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/3ZNA6R65UG26OHB5CNVRWN7YBJYMXV7U/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

2021-09-08 Thread Brett Cannon
On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov 
wrote:

> Comments inlined:
>
> On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum  wrote:
>
>> First of all, we should ping Yury, who implemented `async for` about 6
>> years ago (see PEP 492), and Joshua Bronson, who implemented aiter() and
>> anext() about 5 months ago (see https://bugs.python.org/issue31861).
>> I've CC'ed them here.
>>
>
> Looks like PyAiter_Check was added along with the aiter/anext builtins. I
> agree it's unnecessary to check for __aiter__ in it, so I let's just fix it.
>
>
>
>>
>> My own view:
>>
>> A. iter() doesn't check that the thing returned implements __next__,
>> because it's not needed -- iterators having an __iter__ methor is a
>> convention, not a requirement.
>>
>
> Yeah.
>
>
>> You shouldn't implement __iter__ returning something that doesn't
>> implement __iter__ itself, because then "for x in iter(a)" would fail even
>> though "for x in a" works. But you get an error, and anyone who implements
>> something like that (or uses it) deserves what they get. People know about
>> this convention and the ABC enforces it, so in practice it will be very
>> rare that someone gets bitten by this.
>>
>> B. aiter() shouldn't need to check either, for exactly the same reason. I
>> *suspect* (but do not know) that the extra check for the presence of
>> __iter__ is simply an attempt by the implementer to enforce the convention.
>> There is no *need* other than ensuring that "async for x in aiter(a)" works
>> when "async for x in a" works.
>>
>
> I agree.
>

[SNIP]



> Bottom line: let's fix PyAiter_Check to only look for __anext__. It's a
> new function so we can still fix it to reflect PyIter_Check and not worry
> about anything.
>

I don't know if Pablo wants such a change in 3.10 since we are at rc2 at
this point, so this might have to wait for 3.11 (although there's no
deprecation here since it's a loosening of requirements so it could go in
straight away).
___
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/VLPPCXB3T2AP65VGUTRPYDOKGHEGZUUN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP-535 (Rich comparison chaining) Discussion?

2021-08-31 Thread Brett Cannon
Link to the PEP: https://www.python.org/dev/peps/pep-0535/

On Tue, Aug 31, 2021 at 8:52 AM Angus Hollands  wrote:

> Hi all,
>
> PEP 535 was deferred until Python 3.8. I would like to discuss the PEP
> given that some time has passed, and I _personally_ would benefit from its
> acceptance.
>
>
> ## A little about me:
> As a reasonably long-time Python user (well, 16 years), I have gradually
> moved from using only the core language to working within the DSLs (NumPy
> et al.) of the Scientific Python ecosystem. Most recently, I've been using
> Awkward Arrray (https://github.com/scikit-hep/awkward-1.0), which
> generalises the regular NumPy array programming paradigm into "jagged" data
> structures, and was initially aimed at the High Energy Physics (HEP)
> domain.
>
>
> ## TL;DR of the PEP's Motivations:
> Various aspects of NumPy's API have become a "lingua-franca" in the
> Scientific Python domain, such as strongly-overloaded index operations. One
> such overload allows "mask arrays" — arrays with boolean entries
> corresponding to a per-element mask — to select a subset of the array.
> These mask arrays are conveniently built from the rich comparison operators
> that Python supports, e.g.
> ```python
> x = np.array(...)
> y = x[(2 < x) & (x < 8)]
> ```
>
> As discussed in PEP 535, the limitation on comparison chaining (namely
> that it is not possible for rich comparisons) makes the above syntax more
> clunky than it might otherwise be. The main repercussion of this limitation
> is lower readability:
> - operator precedence of bitwise and/or requires a reasonable number of
> parentheses (
> https://docs.python.org/3/reference/expressions.html#operator-precedence)
> - repetition of the rich-object (array)
>
> With PEP 535 (and the necessary library changes), this would look more like
> ```python
> x = np.array(...)
> y = x[2 < x < 8]
> ```
> This is already well described in the PEP, so I'll leave the example there!
>
>
> ## Community Survey
> The Oct 2020 Python Developers Survey (
> https://www.jetbrains.com/lp/python-developers-survey-2020/) suggests
> that 62% of respondents use NumPy. Additionally, 37% of respondents list
> "Simple syntax, syntactic sugar, easy to learn" and 30% list "Easy to write
> & read code, high-level language" amongst their three most liked features
> in the Python language (to clarify, these answers may overlap by
> respondent!)
>
> >From these results, I would make a tentative case that this PEP would
> have a reasonable impact on the Python community, given that libraries
> benefitting from this proposal (e.g. NumPy) are used by a "majority" of
> those surveyed.
>
>
> ## Conclusion
> This is a bit of a long opener to this list (apologies!). Is there any
> interest in pushing this PEP along?
>
> Thanks,
> Angus Hollands
> ___
> 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/ET7BPR57Q6MT6TUG4SXPSALRC3P3ZY35/
> 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/RGK7JOEO6BY44EEG67LBYAUOPWKLDWYS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

2021-08-30 Thread Brett Cannon
On Sun, Aug 29, 2021 at 2:01 PM Serhiy Storchaka 
wrote:

> 29.08.21 23:16, Brett Cannon пише:
> > If you look at
> >
> https://github.com/python/cpython/blob/b11a951f16f0603d98de24fee5c023df83ea552c/Python/ceval.c#L2409-L2451
> > <
> https://github.com/python/cpython/blob/b11a951f16f0603d98de24fee5c023df83ea552c/Python/ceval.c#L2409-L2451
> >
> > you will see that `async for` requires that the iterator returned from
> > `__aiter__` define `__anext__`. But if you look at aiter() which uses
> > PyObject_GetAiter() from
> >
> https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57/Objects/abstract.c#L2741-L2759
> > <
> https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57/Objects/abstract.c#L2741-L2759
> >
> > and PyAiter_Check() from
> >
> https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57/Objects/abstract.c#L2769-L2778
> > <
> https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57/Objects/abstract.c#L2769-L2778
> >
> > you will notice that aiter() requires `__anext__` *and* `__aiter__` on
> > the async iterator that gets returned from __aiter__.
> >
> > Now the docs for aiter() at
> > https://docs.python.org/3.10/library/functions.html#aiter
> > <https://docs.python.org/3.10/library/functions.html#aiter> points out
> > that the async iterator is expected to define both methods as does the
> > glossary definition for "asynchronous iterator"
> > (https://docs.python.org/3.8/glossary.html#term-asynchronous-iterator
> > <https://docs.python.org/3.8/glossary.html#term-asynchronous-iterator>).
> >
> > So my question is whether the discrepancy between what `async for`
> > expects and what `aiter()` expects on purpose?
> > https://bugs.python.org/issue31861 <https://bugs.python.org/issue31861>
> > was the issue for creating aiter() and I didn't notice a discussion of
> > this difference. The key reason I'm asking is this does cause a
> > deviation compared to the relationship between `for` and `iter()` (which
> > does not require `__iter__` to be defined on the iterator, although
> > collections.abc.Iterator does). It also makes the glossary definition
> > being linked from
> >
> https://docs.python.org/3.10/reference/compound_stmts.html#the-async-for-statement
> > <
> https://docs.python.org/3.10/reference/compound_stmts.html#the-async-for-statement
> >
> > incorrect.
>
> PyIter_Check() only checks existence of __next__, not __iter__ (perhaps
> for performance reasons).
>

Or maybe no one thought to require __iter__ for iterators?


>
> I just ported changes from PyPy in SQLite tests
> (https://github.com/python/cpython/pull/28021) because a test class with
> __next__ but without __iter__ passed tests on CPython but failed on PyPy.
>

I'm going to wait to hear from anyone who may have been involved with
implementing aiter() and `async for` before proposing various ways to align
them with iter() and `for`.
___
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/KFI4DBTF33Q6HYFCBSYWGOTGRWY5YGHP/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Discrepancy between what aiter() and `async for` requires on purpose?

2021-08-29 Thread Brett Cannon
If you look at
https://github.com/python/cpython/blob/b11a951f16f0603d98de24fee5c023df83ea552c/Python/ceval.c#L2409-L2451
you will see that `async for` requires that the iterator returned from
`__aiter__` define `__anext__`. But if you look at aiter() which uses
PyObject_GetAiter() from
https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57/Objects/abstract.c#L2741-L2759
and PyAiter_Check() from
https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57/Objects/abstract.c#L2769-L2778
you will notice that aiter() requires `__anext__` *and* `__aiter__` on the
async iterator that gets returned from __aiter__.

Now the docs for aiter() at
https://docs.python.org/3.10/library/functions.html#aiter points out that
the async iterator is expected to define both methods as does the glossary
definition for "asynchronous iterator" (
https://docs.python.org/3.8/glossary.html#term-asynchronous-iterator).

So my question is whether the discrepancy between what `async for` expects
and what `aiter()` expects on purpose? https://bugs.python.org/issue31861
was the issue for creating aiter() and I didn't notice a discussion of this
difference. The key reason I'm asking is this does cause a deviation
compared to the relationship between `for` and `iter()` (which does not
require `__iter__` to be defined on the iterator, although
collections.abc.Iterator does). It also makes the glossary definition being
linked from
https://docs.python.org/3.10/reference/compound_stmts.html#the-async-for-statement
incorrect.
___
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/ZADNVL7SGH24QXBNPKMN33ELFSXRI2VJ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Notes on PEP 8

2021-08-26 Thread Brett Cannon
On Wed, Aug 25, 2021 at 10:38 PM Christopher Barker 
wrote:

> As I was working on removing Python 2 references from PEP 8 (PR:
> https://github.com/python/peps/pull/2059), I tried to avoid any other
> copy-editing.
>
> However, I noted a few things that maybe could use some attention:
>
> stdlib or not?
> ##
>
> Right at the top, it says:
>
> "This document gives coding conventions for the Python code comprising the
> standard library in the main Python distribution."
>
> However, it has become a de facto standard for all Python code, and in the
> document itself, there is frequent wording akin to "Identifiers used in the
> standard library must be ASCII compatible ...", and even advice for third
> party libraries.
>
> Which I think is acknowledging that PEP 8 is indeed not only about the
> standard library.
>
> So maybe there should be a bit of text about that at the top.
>

I wouldn't be opposed to that personally. I think a lot of people just
think PEP 8 is a doc for the community when it is actually for Python
itself and it happens to be very convenient for others to use. Although we
obviously understand that people do use it in situations outside of the
stdlib, so I don't think saying, "if you're going to use this in a way we
didn't mean it to, here's some advice".

-Brett


>
> Name Mangling
> #
>
> In the sections on "Method Names and Instance Variables" and "Designing
> for Inheritance", the discussion of name mangling (leading __ names) is a
> bit redundant. Nothing incorrect or misleading -- just a copy-editing issue.
>
> Maybe I'll do a copy-editing PR 
>
> -CHB
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> 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/WCTRPSZSC2XO4NG5CKMOBLK2P7UUY7RE/
> 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/X2R6TKU3HO6DGCJCCSXEVW6VB5O6KPDT/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Steering-council] Re: A ban from Core Developer spaces.

2021-08-26 Thread Brett Cannon
On Thu, Aug 26, 2021 at 12:10 AM Simon Cross 
wrote:

> Hi Thomas,
>
> Could I ask a bit about the thinking behind extending the ban to a
> year?


It wouldn't view it as an extension as much as Ethan took immediate action
while the SC was simultaneously working on what to do about the situation.
So they were separate actions and the SC's action happened to be longer and
broader.


> A year is a long time and to me feels similar to asking someone
> to go away and never come back. It's much longer than is needed to go
> away and think about things.
>

Marco was given a previous 3 month suspension on discuss.python.org (as
Marco himself pointed out on the email thread in question). Speaking for
myself, Marco was given a chance previously to take some time to think
about how he approached communicating and it didn't seem to be enough time.

I will also note that Marco publicly asked me to ban him for life in one of
his emails in the thread as well.


>
> Re the future of python-dev: That sounds a bit ominous. Is the
> Steering Council considering removing python-dev? Eek.
>

I am purposefully not replying to this as I don't want to spark a
conversation on this topic in this email thread.

-Brett


>
> Yours sincerely,
> Simon Cross
> ___
> Steering-council mailing list -- steering-coun...@python.org
> To unsubscribe send an email to steering-council-le...@python.org
> https://mail.python.org/mailman3/lists/steering-council.python.org/
> Member address: br...@python.org
>
___
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/LGK7H7LJEA3EKDRZ7TSCIIREUK5VYTQR/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] My apologies to the list

2021-08-25 Thread Brett Cannon
I just wanted to apologize for any angst or noise my replies to Marco
caused folks. I should have known that correcting Marco on how to address
me would have triggered an outsized reply (the real intent of that overall
email was to communicate the process of banning someone to the rest of the
list so people didn't leave faster than we addressed it; obviously didn't
work). It appears my judgement was more impaired than I realized while I
have been sick.

As such, I have amended my rules for when I *don't* read OSS emails (this
excludes SC business):

   1. At least one day every weekend (to avoid having my whole week ruined
   by mean people)
   2. Outside of work hours one month out of the year (to prevent burn-out)
   3. On vacation (to unplug appropriately)
   4. While I am ill (to prevent impaired judgement)

I have actually gone as far as to separate my personal email and OSS/
python.org email accounts into separate email providers so that I can
enforce this separation cleanly.
___
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/ONUW2TMLJPQ54FSQBC2IKYMBEXGCSJHR/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

2021-08-25 Thread Brett Cannon
On Wed, Aug 25, 2021 at 10:32 AM Mike Miller 
wrote:

>
> How about moving Python 2 notes into a section at the bottom?
>

I don't think that's useful. PEP 8 is still meant for the stdlib which is
obviously not using Python 2, so it just becomes baggage. Plus if people
want to refer to the old version they have the version history. And for
anyone who wants to keep the old version they can copy or fork it.


>
>
> -Mike
> ___
> 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/76JIO4AF7WMJ5475FTIHTK6GR2O52OOF/
> 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/7UKHJ2OBYBGJLT25SAXWM3OAXN7MQEXK/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Problems with dict subclassing performance

2021-08-18 Thread Brett Cannon
This is what I get for checking my email while I have pneumonia ...

On Tue, Aug 17, 2021 at 1:25 PM Marco Sulla 
wrote:

> On Sun, 15 Aug 2021 at 22:30, Marco Sulla 
> wrote:
> > Oh, this is enough. The sense of the phrase was very clear and you all
> > have understood it. Remarking grammatical errors is a gross violation
> > of the Netiquette. I ask __immediately__ the intervent of a moderator,
> > even if I quite sure, since I'm mister No One and you are Terry Reed
> > and Steven D'Aprano, that this will be against me X-D
>
> Ahahhaahh, call me Marco "Cassandra" Sulla.
>
> Mr. Cannon,


I rarely correct people about this, but it's actually *Dr.* Cannon; if
you're going to insult me, please use the proper title at least.


> I was sure about your response. Please ban me, it will be
> a pleasure to be banned by you for specious reasons. It's your
> specialty.
>

To provide transparency to everyone else, due to this now escalating to a
personal attack against me I actually can't participate in any vote on the
Conduct WG about how to respond to this thread. So in spite of Marco's
request, sarcastic or otherwise, I actually can't participate in giving him
the requested ban (if that's what occurs from this; as I said, I no longer
have a say in the matter).

But I also can't take such a unilateral action of a ban on my own anyway
since a permanent ban is not in any one person's power to begin with. As a
refresher about how it worked last time there was a permanent ban: the
issue was referred to the Conduct WG, they made a recommendation to the SC,
and the SC made the final decision based on that recommendation (which,
once again, I will have to recuse myself from since I can no longer be
trusted to be impartial).

-Brett


>
> I want to remember here that you banned me from the Py Forum because I
> said "Even a child can understand my code", and you _demanded_ my
> excuses. Since I found the accusation ridiculous, I've made my excuses
> to all children that do not understand my code. You banned me and even
> Steven defended me.
>

> I've been the moderator for a forum for years, and let me say, you are
> not a good moderator. You are hard-mannered. See Tim. He calmed me
> down with two posts. You all have to learn from him, as coders,
> moderators and human beings.
>
> That said, please ban me permanently, because I'll _never_ give you my
> excuses. What I said is the pure truth.
>

> PS: as a side note, I started to get downvotes from when this useless
> polemic started. Since, I repeat, I have more than 13k reputation on
> SO, and since the question had about 20 votes without dirty tricks, as
> Steven subtly insinuates, all of this makes me laugh. Do your worst,
> you all little men. As a Mister No One, I will be **PROUD** to be
> banned as Stephan Krah.
>
>
> On Mon, 16 Aug 2021 at 18:52, Brett Cannon  wrote:
> >
> >
> >
> > On Sun, Aug 15, 2021 at 2:55 PM Marco Sulla <
> marco.sulla.pyt...@gmail.com> wrote:
> >>
> >> On Sun, 15 Aug 2021 at 23:33, Tim Peters 
> >> wrote:ople have said now, including me, they had no idea what
> >> > you meant.by "I pretend your immediate excuses". It's not a complaint
> >> > that it's expressed inelegantly, but that they can't make _any_ sense
> >> > of it. By my count, this is at least the second time you've declined
> >> > to explain what you meant, but instead implied the person who said
> >> > they couldn't understand it was being dishonest.
> >>
> >> I repeat, even the worst AI will understand from the context what I
> >> meant. But let me do a very rude example:
> >
> >
> > Rude examples are never necessary and are not acceptable (don't forget
> we have kids who participate on this mailing list).
> >
> > I have referred the whole thread to the Conduct WG so they can settle
> who was out of line. Otherwise I advise everyone to mute this thread.
>
___
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/R7MO25Q3UM4J2OMS6ENM4WQ2W26PYLAN/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: python-dev thread w/ Marco Sulla

2021-08-16 Thread Brett Cannon
On Mon, Aug 16, 2021 at 1:37 PM Jonathan Goble  wrote:

> On Mon, Aug 16, 2021 at 4:04 PM Nathan C. Fox 
> wrote:
>
>> Yes, it was intended to go to python-dev, even though it's not about
>> Python development. It's part of a discussion about a pretty hostile and
>> off-topic thread that has unfolded over the last week on this mailing list.
>>
>
> Brett's original post here reads as though it was intended as a private
> email to a moderator, though.
>

Not that it really makes a difference at this point, but no, it was not
meant for this mailing list.
___
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/AGJLFJMBZLOL2HF2FE5HGZBDNHNGMO44/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Problems with dict subclassing performance

2021-08-16 Thread Brett Cannon
On Sun, Aug 15, 2021 at 2:55 PM Marco Sulla 
wrote:

> On Sun, 15 Aug 2021 at 23:33, Tim Peters 
> wrote:ople have said now, including me, they had no idea what
> > you meant.by "I pretend your immediate excuses". It's not a complaint
> > that it's expressed inelegantly, but that they can't make _any_ sense
> > of it. By my count, this is at least the second time you've declined
> > to explain what you meant, but instead implied the person who said
> > they couldn't understand it was being dishonest.
>
> I repeat, even the worst AI will understand from the context what I
> meant. But let me do a very rude example:
>

Rude examples are never necessary and are not acceptable (don't forget we
have kids who participate on this mailing list).

I have referred the whole thread to the Conduct WG so they can settle who
was out of line. Otherwise I advise everyone to mute this thread.
___
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/ZVWHZJQU3QTL3GVRLHQHP4WZJWZP2O2P/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] python-dev thread w/ Marco Sulla

2021-08-16 Thread Brett Cannon
https://mail.python.org/archives/list/python-dev@python.org/thread/JRFJ4QH7TR35HFRQWOYPPCGOYRFAXK24/

I can't be objective with Marco as I believe we have recorded issues with
him previously (as with Steven if you take Marco's initial side with this).

The thing that pushed me over the edge to report this was
https://mail.python.org/archives/list/python-dev@python.org/message/O3JB3FE33KMT3OHZCVH3XO6VNJTGH5NL/
.
___
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/TX44HOPXBSHDPA5ZXCAUGWTQDHCTD723/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 558, the simplest thing I could come up with

2021-08-16 Thread Brett Cannon
On Sat, Aug 14, 2021 at 8:01 PM Nick Coghlan  wrote:

> Bringing the public record up to date with a brief off-list discussion
> between Mark, Nathaniel and I:
>
> * Mark hasn't convinced me that getting rid of the frame value cache
> entirely for optimised frames is a good idea, so he's going to write that
> proposal up as a competing PEP. Once it has been drafted and is ready for
> review, he will request the SC assign a PEP delegate.
> * On the PEP 558 front, Mark's proposal has highlighted a few
> inefficiencies in my reference implementation, where the code still
> implicitly updates the frame value cache in cases where the cache being up
> to date may not matter to the proxy API client. So I'll be working on
> another iteration of the implementation that ensures each caching proxy
> instance (at worst) only pays the O(N) cache refresh price on the first
> less than O(N) operation that relies on the cache being up to date, rather
> than paying it every time "f_locals" is retrieved from the frame object.
>
> We still have plenty of time before 3.11b1, so we expect it will be a
> month or two before the two proposals are in a position to be compared
> directly.
>

I think I can speak for the SC by saying, "please, take as much time as you
want" . We are still trying to get out for our PEP review backlog as it
is.

-Brett


>
> Cheers,
> Nick.
>
> On Fri, 30 Jul 2021, 5:25 pm Nick Coghlan,  wrote:
>
>>
>>
>> On Fri, 30 Jul 2021, 2:30 pm Nathaniel Smith,  wrote:
>>
>>>
>>> >
>>> > For [proxy] versus [snapshot], a lot depends on what we think of
>>> changing the semantics of exec(). [proxy] is definitely more consistent and
>>> elegant, and if we could go back in time I think it's
>>> what we'd have done from the start. Its compatibility is maybe a bit
>>> worse than [snapshot] on non-exec() cases, but this seems pretty minor
>>> overall (it often doesn't matter, and if it does just write
>>> dict(locals()) instead of locals(), like you would in non-function
>>> scope). But the change in exec() semantics is an actual language
>>> change, even though it may not affect much real code, so that's what
>>> stands out for me.
>>>
>>> I *think* (please correct me if I'm wrong) that what that calls
>>> [PEP-minus-tracing] is now corresponds to the current PEP draft, and
>>> [proxy] corresponds to Mark's draft at the beginning of this thread?
>>>
>>
>> At the locals() level, PEP 558 is now [snapshot] (due to your original
>> analysis showing that it was strictly better than what I had at the time),
>> while Mark's draft is indeed [proxy].
>>
>> Cheers,
>> Nick.
>>
>>
>>
>>> -n
>>>
>>> --
>>> Nathaniel J. Smith -- https://vorpus.org
>>>
>> ___
> 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/EU2TU6R2HDV6NLZQ56MSDIRMG6EHSOJO/
> 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/U4K7OFXLQTNW667XAVEJPTPFSDTSWXB4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 467 feedback from the Steering Council

2021-08-14 Thread Brett Cannon
Barry Warsaw wrote:
> On Aug 4, 2021, at 07:31, Victor Stinner vstin...@python.org wrote:
> > On Tue, Aug 3, 2021 at 7:54 PM Ethan Furman et...@stoneleaf.us wrote:
> > I would rather keep `bchr` and lose the `.fromint()` methods.
> > I would prefer to only have a bytes.byte(65) method, no bchr()
> > built-in function. I would prefer to keep builtins namespace as small
> > as possible.
> > The Steering Council is also pretty adamantly against adding a new bchr() 
> > built-in.

FYI the PEP still mentions `bchr`.

-Brett

> > bytes.byte() name is similar to bytes.getbyte(). I cannot find "int"
> > in the name of other bytes methods.
> > .byte() seems fine to me too.  I’m not a fan of smushedwords but .fromint() 
> > seemed better than .fromord().
> -Barry
___
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/5XGSSSTSDGG3QSEQSC2IUVNEAKWKLQXS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

2021-08-12 Thread Brett Cannon
On Thu, Aug 12, 2021 at 6:04 AM Jack DeVries  wrote:

> On a broader note, how does the deployment pipeline for documentation
> work? It seems to me that for branches that are in pre-release (3.10) or
> active development (3.11), the documentation should be continuously
> deployed, while deployment of changes to earlier documentation should
> follow minor releases for those versions.
>
> Sorry this question is naive -- I don't know how it works currently. Would
> it be possible to set something like this up?
>

If you look at the version picker on docs.python.org you will see that we
already have the docs for 3.10 and 3.11 available. I don't know if they are
updated per release right now or per commit.

-Brett


>
> On Thu, Aug 12, 2021, 3:02 AM Serhiy Storchaka 
> wrote:
>
>> 11.08.21 21:35, Brett Cannon пише:
>> > So my question is whether we want to push to be more diligent about
>> > updating What's New by b1 so people can provide feedback during the
>> > betas beyond just reporting breaking changes?
>>
>> I think that What's New should be updated as soon as possible,
>> immediately after the addition of the feature. I started contributing to
>> Python after reading What's New for one of early alphas of 3.3 (and the
>> questioned feature was changed later). There were other examples, when
>> features were advertised in alphas, but were changed after getting a
>> feedback before betas.
>>
>> ___
>> 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/RQQ2QEV3OKCMAJGHLB52SKXLAIL7BB34/
>> 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/V7E6UQPHXQSQZQSDFBLOGTS4AGGGPLJF/
> 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/YS3354SXYCFFD7ZQWQQZEYY4YCUMPFYH/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Should we try to get a complete draft of What's New by b1?

2021-08-11 Thread Brett Cannon
Not to specifically pick on Eric V. Smith, but yesterday a co-worker came
to me asking about `KW_ONLY` for dataclasses and wanting to provide
feedback (
https://docs.python.org/3.10/library/dataclasses.html#dataclasses.KW_ONLY).
I said we had reached RC and so it was pretty much too late; the alphas and
betas are when one should provide feedback.

But then I realized you wouldn't even know about this new feature unless
you read What's New ... and that's when I found out this new feature isn't
mentioned (yet). As of right now the only dataclass feature documented in
the What's New is something about slots (
https://docs.python.org/3.10/whatsnew/3.10.html#dataclasses).

So my question is whether we want to push to be more diligent about
updating What's New by b1 so people can provide feedback during the betas
beyond just reporting breaking changes?
___
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/YTXDZRAVW3VNVMJUCFZYRWNECZFKEFDH/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

2021-08-09 Thread Brett Cannon
On Mon, Aug 9, 2021 at 8:31 AM Eric V. Smith  wrote:

> I'd like to revive the discussion of PEP 649
> [https://www.python.org/dev/peps/pep-0649/] that started shortly before
> development of 3.10 features was closed. This is Larry's PEP to defer
> evaluation of __annotations__ until it's actually accessed. During the
> discussion the decision was made to back out the change that made "from
> __future__ import annotations" (PEP 563
> [https://www.python.org/dev/peps/pep-0563/]) the default behavior for
> 3.10.
>
> My understanding is that PEP 649 is currently in front of the SC.


Correct.


> But do
> we need to have any additional discussion here?


I think it's worth discussing whether PEP 649 is the solution we want to
see as the solution to this problem or not?


> My recollection is that
> we backed out the PEP 563 change because we didn't feel we had enough
> time to come to a good decision one way or the other before 3.10.
>

Correct.


>
> Personally, I'd like to see PEP 649 accepted. There are a number of
> issues on bpo where people expect dataclass's field.type to be an actual
> Python object representing a type, and not a string. This field is
> copied directly from __annotations__. If we stick with PEP 563's string
> annotations, I'll probably just close these issues as "won't fix", and
> tell the caller they need to convert the strings to Python objects
> themselves. If 649 is accepted, then they'll all get their wish, and in
> addition I can remove some ugly logic from dataclasses.
>
> Do we need to do anything here to move forward on this issue? I've
> chatted with Larry and Mark Shannon, who have some additional thoughts
> and I'm sure will chime in.
>

I think the question is whether we have general consensus around PEP 649?

-Brett


>
> --
> Eric
>
> ___
> 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/2MEOWHCVDLPABOBLYUGRXVOOOBYOLLU6/
> 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/OQN6ALRTEDMRYVLKQIG3YHTNSKYTKWEJ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)

2021-07-29 Thread Brett Cannon
On Thu, Jul 29, 2021 at 3:47 AM Mark Shannon  wrote:

> Hi everyone,
>
> I would like to repeal PEP 509. We don't really have a process for
> repealing a PEP. Presumably I would just write another PEP.
>

Yeah, it's probably a new PEP explaining why the first PEP turned out to
not work out since it's undoing a "big" decision. Otherwise it's like
withdrawing the PEP post-acceptance.

-Brett


>
> Before I do so, I would like to know if anyone thinks we should keep
> PEP 509.
>
> The dictionary version number is currently unused in CPython and just
> wastes memory. I am not claiming that we will never need it, just that
> we shouldn't be required to have it. It should be an internal
> implementation detail that we can add or remove depending on requirements.
>
> Thoughts?
>
> Cheers,
> Mark.
> ___
> 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/GV4CW3T7SUTJOYSCP6IJMV4AHDNNZIPV/
> 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/FLPV7EETKZ5F5AQCS3EDVVIKFJEB7V7A/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: importing does not dispatch to __builtins__.__getitem__ to lookup __import__

2021-07-14 Thread Brett Cannon
On Wed, Jul 14, 2021 at 10:17 AM Patrick Reader 
wrote:

> Hi there,
>
> I've noticed that, when a frame's __builtins__ is a subclass of dict with
> an overridden __getitem__ method, this overriden method is not used by the
> IMPORT_NAME instruction to lookup __import__ in the dictionary; it uses the
> lookup function of normal dictionaries (via _PyDict_GetItemIdWithError).
> This is contrary to the behaviour of the similar LOAD_BUILD_CLASS, as well
> as the typical name lookup semantics of LOAD_GLOBAL/LOAD_NAME, which all
> use PyDict_CheckExact for a "fast path" before defaulting to
> PyObject_GetItem, which is unexpected.
>
> Perhaps more seriously, if __builtins__ is not a dict at all, then it gets
> erroneously passed to some internal dict functions resulting in a
> mysterious SystemError ("Objects/dictobject.c:1440: bad argument to
> internal function") which, to me, indicates fragile behaviour that isn't
> supposed to happen.
>
> I'm not sure if this intended, so I didn't want to open an issue yet. It
> also seems a highly specific use case and changing it would probably cause
> a bit of a slow-down in module importing so is perhaps not worth fixing. I
> just wanted to ask here in case this issue had been documented anywhere
> before, and to check if it might actually be supposed to happen before
> opening a bug report.
>

At this point it's basically a feature request since it's been like that
for so long.


> I cannot find evidence that this behaviour has changed at all in recent
> history and it seems to be the same on the main branch as in 3.9.6.
>

I believe it's been like that for as long as I have worked on importlib
which is over a decade. The lookup also skips over any global definition of
__import__ and goes straight to __builtins__.


> A short demo of these things is attached.
>
> Links to relevant CPython code in v3.9.6:
>
> IMPORT_NAME:
> https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L5179
>
> BUILD_CLASS:
> https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2316
>
> LOAD_NAME:
> https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2488
>
> LOAD_GLOBAL:
> https://github.com/python/cpython/blob/v3.9.6/Python/ceval.c#L2546
>
> Thanks,
>
> Patrick Reader
> ___
> 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/ZQMF6XC76J4APJPB3X6PGATG6CV5NN44/
> 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/LFF7RUZPYWPKQWB243IQLBIUEI3UKIK3/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Python3 OSF/1 support?

2021-07-14 Thread Brett Cannon
On Wed, Jul 14, 2021 at 9:36 AM Chris Johns  wrote:

> As someone who has ported Python 3 to another "less commonly used"
> system (RISC OS) I just do semi-regular updates rather than trying to
> keep it it totally up to date with "main".
>
> I have some vague recollection of there being talk about a "second tier"
> of systems where there is at least a maintainer and build bot, but I'm
> not sure what, it anything, came from that.
>

Nothing as of yet. People mentioned clarifying and cleaning up how we
define platform support, but no one has taken the time to try and tackle
that issue.

-Brett


>
> Cheers
>
> Chris
>
> On 14/07/2021 15:44, Senthil Kumaran wrote:
> > On Wed, Jul 14, 2021 at 04:30:33AM +, Jay K wrote:
> >> Hi. I have an Alpha/OSF machine up and running.
> >> It is little slow, but it works ok.
> >>
> >> I would like to run Python3 on it.
> >>
> >> I have it "compiling and working". It was easy enough so far.
> >>https://github.com/python/cpython/pull/27063
> >>
> >> Admitted, I haven't figured out what is happening with the
> posixsubprocess
> >> module.
> >>
> >> Yes? No? Maybe?
> >>
> >> I can possibly provide ongoing "support" (I don't expect it will be
> much) and a
> >> buildbot (if really required),
> >> if I can get it working a bit more, if this is approved, etc. I haven't
> looked
> > It is difficult to maintain support for less commonly used systems. If
> > you maintain it personally (like using a cron) and look at the results
> > over time, you could see the difficulty in maintaining the support.
> >
> > Personally, my vote is a -1 here. In the PR, another core-dev, Ronald
> > had commented that support for explicitly removed a few years ago.
> >
> ___
> 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/VSQD4TVVI42I5NMDZ4OE43ZAPJV5M66G/
> 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/VQYFKTLDLIO5AEH7GAMZEOQMONDWFN5Y/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Is the Python review process flawed?

2021-07-01 Thread Brett Cannon
On Thu, Jul 1, 2021 at 4:54 PM  wrote:

> Okay so I just code a little bit and I used the multiprocessing module but
> my code didn't work and I found the solution on Stack Overflow and it
> turned out to be not my mistake (which has never happened before I think).
> Instead I found out it's a bug in Python and the issue on Github was linked
> so I opened it and I was surprised to see what's going on "behind the
> scenes".
>
> Yes I have basically no experience in maintaining any big project. So when
> you're saying "You don't know what it's like and therefore your complaint
> doesn't make sense" then you're not wrong and I just have to believe you.
> But I think this is a dangerous argument because it could also be used to
> shut up anything and anybody. (I'm not saying this is the case here.)
> Therefore, this argument should rarely be used in my opinion. From an
> outsider's perspective it just looks really weird that a bugfix from 2017
> hasn't become a priority to get merged, like the process is flawed. That's
> all. I didn't mean to attack any one of you. I want to make that clear
> because it feels like some of you got kinda defensive about it.
>

We do get defensive because people on a regular basis come to us asking,
"why haven't you fixed this?" and we have to explain why, and some people
accept the answer and others continue to push us which in all honesty
becomes exhausting. Add on that not everyone asking in an understanding,
kind way and it makes one not want to even reply most of the time.


>
> "There's been quite a bit of discussion on both of them" - None of the
> discussions left any questions unanswered. Except for the question of when
> the pull request will get merged.
>
> "Merging something is also a responsibility to whoever does it" - And it's
> also a responsibility to fix bugs, no? I don't get why you're so afraid of
> (maybe!) introducing a new bug when there already (certainly!) is a bug.
>
> "Oops. I'm really sorry for giving false hopes, then, because I don't
> think I'm motivated to review this PR. I'm not really maintaining
> multiprocessing these days, anymore" - No worries dude. This not about one
> person or one bug. I'm sorry that the issue that I stumbled upon turned out
> to be one where you said you'd put it on your list.
>
> "What if that one line change is even more wrong than before?" - Yes of
> course there's a risk. Just like there was a risk when you merged the
> original code which contained the bug, right?! At some point you have to
> say yes that looks okay let's merge it, even though there is a slight
> chance it could contain a mistake. And it is not obvious to me (and many
> other people who commented in those github threads) what else would
> possibly be needed. After all, there are currently actual people who are
> affected by the bug - and you're only talking about hypothetical people
> being affected by a possibly wrong bugfix.
>

As Eric points out in his own follow-up, sometimes the fix is worse than
the bug it's fixing. Add to that the feeling when people descend upon you
for breaking their code that was working due to a "bugix" which from their
view wasn't, and it makes you very cautious about accepting any PR w/o
having a solid understanding of the ramifications. I have people come up to
me at PyCon US about code I have changed over a decade ago to complain
about it. It's exhausting sometimes.


>
> "When I got the shutil.which feature merged, the PR had been open for I
> believe 11 years" - Totally different topic. I explicitly said in my
> initial message, that I'm talking about a bugfix, not a new feature.
>
> "If you would like more value out of it or to speed up the process, you
> can provide your own reviews." - Seriously? I can't help but feel like that
> comment sounds kinda arrogant. I hope I'm misunderstanding you. Look at
> that link and Stack Overflow post again how many people commented and voted
> that the patch fixed their issues. How many more people do you want?
>

A SO comment is not a code review. What was being requested is someone not
only validating the fix but making sure the code is solid, meets coding
guidelines, has appropriate tests, etc. There is much more to maintaining
the code than just whether it functions appropriately.


>
> "*maintainer attention* is actually the scarcest resource in many open
> source projects, and Python is no exception." - Then get more people to do
> this? Don't tell me Python isn't big enough to find some companies or funds
> to sponsor a few people to work the dreaded reviewer job a few hours a week?


Welcome to open source and why it is perpetually underfunded. The PSF just
got funding for the first time in Python's 30 year history this year to
hire someone to work on Python full-time. I get 20% for open source from my
employer and I am very lucky to get that plus whatever time I spend away
from family and friends in my spare time (like now while I reply to this
during a holiday).

Or 

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Brett Cannon
On Tue., Jun. 22, 2021, 14:50 Glenn Linderman, 
wrote:

> On 6/22/2021 12:52 PM, Brett Cannon wrote:
>
>
>
> On Mon, Jun 21, 2021 at 4:09 PM Glenn Linderman 
> wrote:
>
>> On 6/21/2021 2:31 PM, Christopher Barker wrote:
>>
>>
>> By contrast, requiring a github account for reporting bugs also makes
>>> python an unwelcoming place for non-developers in general. Github is a
>>> developers' social network, "mere" users are much less likely to want to
>>> be part of it. Many will just silently abandon their bug report.
>>
>>
>> But you don’t need to be “part of it” in any meaningful way. One only
>> needs to create an account, which could be quite anonymous, and even
>> temporary.
>>
>> And is no harder, and probably easier, than creating an account on a
>> Python-specific site.
>>
>> Also: cPython is a large, complex, and mature project. I don't think many
>> non-developers can even identify a true bug, much less write a helpful big
>> report. There are many other ways to be involved in and contribute to the
>> Python community that don't require a gitHub (or any) account.
>>
>> I understand the issue here — I feel that way about businesses that use
>> Facebook for their website. But in that case, I can’t even read it without
>> a Facebook account. I don’t mind needing an account to contribute to a
>> conversation.
>>
>> And while GitHub  has become the dominant player in Open Source
>> development— it has not (yet?) reached out to control much else.
>>
>> -CHB
>>
>>
>> With all due respect to Microsoft, who has contributed significantly to
>> Python development, and continues to do, some people don't care for some of
>> Microsoft's policy and actions, and Microsoft owns GitHub, so your last
>> paragraph is somewhat naive, at best.
>>
>> So what is the difference between a GitHub account, and Microsoft account?
>>
>
> They are entirely different and separate; there's no relation there at all.
>
>
> Good, but given the Skype experience, it is questionable how long they
> will stay that way.
>

You can choose to view that as a one-off or indicative of a pattern. I'm
choosing the former (you can use the LinkedIn acquisition as support for my
view).


> One thing I will remind people is I personally have led the work to move
> this project from:
>
>1. SourceForge to our own infrastructure
>2. Mercurial to git
>3. Our own infrastructure to GitHub for code management
>
> So if GitHub were to do something we don't like we can always move
> platforms again.
>
>
> Indeed, but platform churn slows contributions, too.
>

Sure, but I don't think anyone is about to argue we should have stayed on
SF. Nor are there plans to switch off of GitHub.

Regardless, there are no plans to halt what was decided when we accepted
PEP 581. Most of the concerns which have been brought up in this thread
were already expressed back then (the account merge one I didn't remember,
hence why I replied).

>
___
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/IL6TJJXAIZODIQ5CNSIVV2LN4R43ZJKP/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Brett Cannon
On Mon, Jun 21, 2021 at 4:09 PM Glenn Linderman 
wrote:

> On 6/21/2021 2:31 PM, Christopher Barker wrote:
>
>
> By contrast, requiring a github account for reporting bugs also makes
>> python an unwelcoming place for non-developers in general. Github is a
>> developers' social network, "mere" users are much less likely to want to
>> be part of it. Many will just silently abandon their bug report.
>
>
> But you don’t need to be “part of it” in any meaningful way. One only
> needs to create an account, which could be quite anonymous, and even
> temporary.
>
> And is no harder, and probably easier, than creating an account on a
> Python-specific site.
>
> Also: cPython is a large, complex, and mature project. I don't think many
> non-developers can even identify a true bug, much less write a helpful big
> report. There are many other ways to be involved in and contribute to the
> Python community that don't require a gitHub (or any) account.
>
> I understand the issue here — I feel that way about businesses that use
> Facebook for their website. But in that case, I can’t even read it without
> a Facebook account. I don’t mind needing an account to contribute to a
> conversation.
>
> And while GitHub  has become the dominant player in Open Source
> development— it has not (yet?) reached out to control much else.
>
> -CHB
>
>
> With all due respect to Microsoft, who has contributed significantly to
> Python development, and continues to do, some people don't care for some of
> Microsoft's policy and actions, and Microsoft owns GitHub, so your last
> paragraph is somewhat naive, at best.
>
> So what is the difference between a GitHub account, and Microsoft account?
>

They are entirely different and separate; there's no relation there at all.

One thing I will remind people is I personally have led the work to move
this project from:

   1. SourceForge to our own infrastructure
   2. Mercurial to git
   3. Our own infrastructure to GitHub for code management

So if GitHub were to do something we don't like we can always move
platforms again.
___
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/7BKMC5OUXXFXZAKD5HOZ7KZO5YTTDEB7/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

2021-06-05 Thread Brett Cannon
On Sat., Jun. 5, 2021, 07:38 Robin Becker,  wrote:

> On 04/06/2021 19:29, Steve Dower wrote:
> ...
> >
> > While we were investigating the reliably broken behaviour, we figured
> that related behaviour was
> > *unreliably* broken on all platforms.
> >
> > Specifically, if you imported a module through a relative path (resolved
> to CWD), changed the CWD, cleared the module
> > cache, and reimported, you would still get the original module, contrary
> to the intent of getting the newly resolved
> > module. ("Correct" code would have also cleared the import path caches,
> not just sys.modules.) This was because the
> > module info was cached using the relative path, and so would be used
> later even though its absolute path had changed.
> >
> > Someone reported this change in 3.8 and we decided to revert it in
> existing released, because the bugfix was for an
> > obscure enough situation that it really wasn't worth breaking any
> existing versions. For unreleased versions, it's
> > better to fix it so that imports will be more reliable in the future.
>
>
> Unfortunately we are using these relative imports to implement plugins for
> an xml language processor so this is likely
> not just an accident of ordering the failing tests. I agree we have to get
> a plugin module a bit more directly using the
> import internals. I still think we might need to control sys.path as
> presumably the plugin code could have imports of
> parallel modules.
>
> I'm beginning to understand that messing about with
> sys.path/modules/meta_path etc etc is a lot harder than it used to be.
>

How so? The key details have not changed since Python 3.4 when module specs
were introduced. And meta path, etc. are 2.7 concepts.


> Incidentally I find that I am able to import a namespace module directly;
> this code doesn't crash (at least in python >= 3.6
>
> ###
> #timpA.py don't run with any meaningful directory A
> import importlib
> def main():
>  module = importlib.import_module('A')
>  print('module=%r' % module)
>
> if __name__=='__main__':
>  main()
> ###
>
> in python 3.6-3.9 this prints out "module=" in
> 3.10.0b1 it prints
> "module= at 0x7f1c8a22fe20>)>".
> I thought I had to use pkgutils or pkg_resources to mess with these
> new-fangled packages.
>

Nope, that has never been required since the concept of namespace packages
were introduced to import.


> Likewise I find that the python statement 'import A' also doesn't fail and
> A is  a namespace.


Yep, that's expected.

I feel quite stupid now :(
>

As soon as you step outside the norm there are a lot of details to
understand; import is very much following the "Complex is better than
complicated" zen. So no need to feel stupid, there's a lot to keep track of
when you start to dive into the details.

-Brett

--
> Robin Becker
> ___
> 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/KMJAQUGSXINVBLQOMREURUFN4LVCEIVX/
> 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/KQFXVNNCYYOEBZJTNRXTT7RQBDRTR5LC/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

2021-05-27 Thread Brett Cannon
I've gotten some questions privately about my responses on this topic and
so I wanted to take the opportunity to clarify a couple of things.

First, I totally support the technical work that Guido, Eric, and Mark have
planned. This whole line of questions is not meant to act as stop energy
for this specific project in any way. I apologize if that didn't come
across in my emails.

Second, this is totally a process question from my POV. The answer in the
end might be that a PEP is not even necessary and it's more about sharing a
design doc, or maybe it's a PEP as Standards Track, or maybe an
Informational PEP is the right thing in the end; I simply don't know and
hence my questions on this topic. I'm just trying to figure out how we as a
group want to discuss and handle projects of this size going forward in
case getting corporate support to start tackling these bigger projects
becomes more normal.

On Wed, May 26, 2021 at 1:00 PM Brett Cannon  wrote:

>
>
> On Wed, May 26, 2021 at 4:23 AM Mark Shannon  wrote:
>
>> Hi Brett,
>>
>> On 26/05/2021 3:56 am, Brett Cannon wrote:
>> >
>> >
>> > On Tue., May 25, 2021, 12:58 Guido van Rossum, > > <mailto:gu...@python.org>> wrote:
>> >
>> > On Tue, May 25, 2021 at 12:34 PM Brett Cannon > > <mailto:br...@python.org>> wrote:
>> >
>> >
>> > I personally think it should be a Standards Track PEP. This PEP
>> > isn't documenting some detail like PEP 13 or some release
>> > schedule, but is instead proposing a rather major change to the
>> > interpreter which a lot of us will need to understand in order
>> > to support the code (and I do realize the entire area of "what
>> > requires a PEP and what doesn't" is very hazy).
>> >
>> >
>> > Does that also mean you think the design should be completely hashed
>> > out and approved by the SC ahead of merging the implementation?
>> > Given the amount of work, that would run into another issue -- many
>> > of the details of the design can't be fixed until the implementation
>> > has proceeded, and we'd end up with a long-living fork of the
>> > implementation followed by a giant merge. My preference (and my
>> > promise at the Language Summit) is to avoid mega-PRs and instead
>> > work on this incrementally.
>> >
>> > Now, we've done similar things before (for example, the pattern
>> > matching implementation was a long-living branch), but the
>> > difference is that for pattern matching, the implementation followed
>> > the design, whereas for the changes to the bytecode interpreter that
>> > we're undertaking here, much of the architecture will be designed as
>> > the implementation proceeds, based on what we learn during the
>> > implementation.
>> >
>> > Or do you think the "Standards Track" PEP should just codify general
>> > agreement that we're going to implement a specializing adaptive
>> > interpreter, with the level of detail that's currently in the PEP?
>> >
>> >
>> > This. Having this as an informational PEP that's already marked as
>> > Active seems off somehow to me. I guess it feels more "we're doing
>> this"
>> > (which I know isn't intended) rather than "this is our plan, what do
>> you
>> > all think? All good?"
>>
>> The PEP is a "we're doing this" document. Maybe it shouldn't be a PEP at
>> all? I've changed its status to "draft" for now.
>>
>
> Thanks!
>
>
>>
>> I want to document what we are doing as publicly as possible and a PEP
>> seems like a good way to do that.
>>
>> I also want to reiterate that the PEP doesn't propose changing the
>> language, libraries, Python API or C API in any way. It is just
>> information about how we plan to speed up the interpreter.
>>
>
> Sure, but it isn't a minor change either; if it was then you would have
> done it already.  This is an architectural shift in how the interpreter
> works, so it isn't a minor thing.
>
>
>> >
>> >
>> > I don't recall other standards track PEPs that don't also spell out
>> > the specification of the proposal in detail.
>> >
>> >
>> > I also am not aware of a PEP that's proposed restructuring the eval
>> loop
>> > like this either.  I'm personally fine with the detail and saying
>> > details may shift as things move forward and le

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

2021-05-26 Thread Brett Cannon
On Wed, May 26, 2021 at 4:23 AM Mark Shannon  wrote:

> Hi Brett,
>
> On 26/05/2021 3:56 am, Brett Cannon wrote:
> >
> >
> > On Tue., May 25, 2021, 12:58 Guido van Rossum,  > <mailto:gu...@python.org>> wrote:
> >
> > On Tue, May 25, 2021 at 12:34 PM Brett Cannon  > <mailto:br...@python.org>> wrote:
> >
> >
> > I personally think it should be a Standards Track PEP. This PEP
> > isn't documenting some detail like PEP 13 or some release
> > schedule, but is instead proposing a rather major change to the
> > interpreter which a lot of us will need to understand in order
> > to support the code (and I do realize the entire area of "what
> > requires a PEP and what doesn't" is very hazy).
> >
> >
> > Does that also mean you think the design should be completely hashed
> > out and approved by the SC ahead of merging the implementation?
> > Given the amount of work, that would run into another issue -- many
> > of the details of the design can't be fixed until the implementation
> > has proceeded, and we'd end up with a long-living fork of the
> > implementation followed by a giant merge. My preference (and my
> > promise at the Language Summit) is to avoid mega-PRs and instead
> > work on this incrementally.
> >
> > Now, we've done similar things before (for example, the pattern
> > matching implementation was a long-living branch), but the
> > difference is that for pattern matching, the implementation followed
> > the design, whereas for the changes to the bytecode interpreter that
> > we're undertaking here, much of the architecture will be designed as
> > the implementation proceeds, based on what we learn during the
> > implementation.
> >
> > Or do you think the "Standards Track" PEP should just codify general
> > agreement that we're going to implement a specializing adaptive
> > interpreter, with the level of detail that's currently in the PEP?
> >
> >
> > This. Having this as an informational PEP that's already marked as
> > Active seems off somehow to me. I guess it feels more "we're doing this"
> > (which I know isn't intended) rather than "this is our plan, what do you
> > all think? All good?"
>
> The PEP is a "we're doing this" document. Maybe it shouldn't be a PEP at
> all? I've changed its status to "draft" for now.
>

Thanks!


>
> I want to document what we are doing as publicly as possible and a PEP
> seems like a good way to do that.
>
> I also want to reiterate that the PEP doesn't propose changing the
> language, libraries, Python API or C API in any way. It is just
> information about how we plan to speed up the interpreter.
>

Sure, but it isn't a minor change either; if it was then you would have
done it already.  This is an architectural shift in how the interpreter
works, so it isn't a minor thing.


> >
> >
> > I don't recall other standards track PEPs that don't also spell out
> > the specification of the proposal in detail.
> >
> >
> > I also am not aware of a PEP that's proposed restructuring the eval loop
> > like this either.  I'm personally fine with the detail and saying
> > details may shift as things move forward and lessons are learned based
> > on the scope and updating the PEP accordingly. But that's just me and I
> > don't know if others agree (hence the reason I'm suggesting this be
> > Standards Track).
>
> Suppose it were a standards PEP, what would that mean if it were rejected?
>

Then we don't do it.


> Rejection of a PEP is a choice in favor of an alternative, but what is
> that alternative?
>

The status quo.


> You can't simply say the "status quo" as that would implicitly prevent
> any development at all on the bytecode interpreter.
>

I don't think that logic holds; if *your *approach happened to be rejected
in terms of how to change how the interpreter works it doesn't mean that
*no* approach would be accepted (and you can tweak this to be about
performance or anything else). PEPs are not submitted where it's "pick from
these 2 options" or "pick this or you can never touch the topic/idea again".

I think this is all a question of process and how do we want to handle
these sort of architectural changes that don't necessarily impact APIs (and
thus users directly), but do impact all of us from a perspective of
maintenance and understanding? Typically we haven't worried about it
because quite frankly none of us have had the

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

2021-05-25 Thread Brett Cannon
On Tue., May 25, 2021, 12:58 Guido van Rossum,  wrote:

> On Tue, May 25, 2021 at 12:34 PM Brett Cannon  wrote:
>
>>
>> I personally think it should be a Standards Track PEP. This PEP isn't
>> documenting some detail like PEP 13 or some release schedule, but is
>> instead proposing a rather major change to the interpreter which a lot of
>> us will need to understand in order to support the code (and I do realize
>> the entire area of "what requires a PEP and what doesn't" is very hazy).
>>
>
> Does that also mean you think the design should be completely hashed out
> and approved by the SC ahead of merging the implementation? Given the
> amount of work, that would run into another issue -- many of the details of
> the design can't be fixed until the implementation has proceeded, and we'd
> end up with a long-living fork of the implementation followed by a giant
> merge. My preference (and my promise at the Language Summit) is to avoid
> mega-PRs and instead work on this incrementally.
>
> Now, we've done similar things before (for example, the pattern matching
> implementation was a long-living branch), but the difference is that for
> pattern matching, the implementation followed the design, whereas for the
> changes to the bytecode interpreter that we're undertaking here, much of
> the architecture will be designed as the implementation proceeds, based on
> what we learn during the implementation.
>
> Or do you think the "Standards Track" PEP should just codify general
> agreement that we're going to implement a specializing adaptive
> interpreter, with the level of detail that's currently in the PEP?
>

This. Having this as an informational PEP that's already marked as Active
seems off somehow to me. I guess it feels more "we're doing this" (which I
know isn't intended) rather than "this is our plan, what do you all think?
All good?"


I don't recall other standards track PEPs that don't also spell out the
> specification of the proposal in detail.
>

I also am not aware of a PEP that's proposed restructuring the eval loop
like this either.  I'm personally fine with the detail and saying details
may shift as things move forward and lessons are learned based on the scope
and updating the PEP accordingly. But that's just me and I don't know if
others agree (hence the reason I'm suggesting this be Standards Track).

-Brett


> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>
___
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/JSKR5GS7OSXYKZFQAYZ4IVXZCC5NXIEX/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

2021-05-25 Thread Brett Cannon
On Thu, May 13, 2021 at 1:38 AM Mark Shannon  wrote:

> Hi Terry,
>
> On 13/05/2021 8:20 am, Terry Reedy wrote:
> > On 5/12/2021 1:40 PM, Mark Shannon wrote:
> >
> >> This is an informational PEP about a key part of our plan to improve
> >> CPython performance for 3.11 and beyond.
> >
> > What is the purpose of this PEP?  It seems in part to be like a
> > Standards Track PEP in that it proposes a new (revised) implementation
> > idea for the CPython bycode interpreter.  Do you not intend this to not
> > constitute approval of even the principle?
>
> I will make it a standards PEP if anyone feels that would be better.
> We can implement PEP 659 incrementally, without any large changes to the
> implementation or any to the language or API/ABI, so a standards PEP
> didn't seem necessary to us.
>
> However, because it is a large change to the implementation, it seemed
> worth documenting and doing so in a clearly public fashion. Hence the
> informational PEP.
>

I personally think it should be a Standards Track PEP. This PEP isn't
documenting some detail like PEP 13 or some release schedule, but is
instead proposing a rather major change to the interpreter which a lot of
us will need to understand in order to support the code (and I do realize
the entire area of "what requires a PEP and what doesn't" is very hazy).

-Brett


>
> >
> > One of the issues in the new project gave formulas for the cost versus
> > benefit calculations underlying specialization.  Depending on your
> > purpose, it might be good to include them.  They certainly gave some
> > clarity to me.
> >
>
> Which ones in particular? I can add something like them to the PEP.
>
> Cheers,
> Mark.
>
>
> ___
> 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/VY3JB3XO4D2E65ZR5IZUDP7MFQJ3JXIF/
> 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/SHR37RVTQGCTNK23ENVG3K57ZHY2K37X/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: python-iterators mailing list on SourceForge

2021-05-25 Thread Brett Cannon
On Fri, May 21, 2021 at 9:25 AM Julien Palard via Python-Dev <
python-dev@python.org> wrote:

> Le 5/11/21 à 8:39 PM, Guido van Rossum a écrit :
> > I doubt that anyone has the keys to the python project on sourceforge
> > any more... :-( We've abandoned that platform nearly two decades ago.
>

> That's right…
>
> Sourceforge staff mentionned there's the list of current admins here:
>
> => https://sourceforge.net/p/python/_members/
>
>
1Password to the rescue as I still have my keys! 


> so if someone see its login there, you can try logging in and unhide the
> mailing list, else I'll try to have sourceforge unhide it by hand.
>

Is there something to do here? The python-iterators mailing list is already
marked as public.

-Brett


>
> --
> [Julien Palard](https://mdk.fr)
>
> ___
> 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/DFE7G73N6LLSVYOZBZ6BHDAOGAGORQ6I/
> 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/C66CRKE5PJJVU2EUB25UY6SBTDMEQE5T/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

2021-05-08 Thread Brett Cannon
On Sat, May 8, 2021 at 2:59 PM Gregory P. Smith  wrote:

>
>
> On Sat, May 8, 2021 at 2:09 PM Pablo Galindo Salgado 
> wrote:
>
>> > Why not put in it -O instead?  Then -O means lose asserts and lose
>> fine-grained tracebacks, while -OO continues to also
>> strip out doc strings.
>>
>> What if someone wants to keep asserts but do not want the extra data?
>>
>
> exactly my theme.  our existing -O and -OO already don't serve all user
> needs.  (I've witnessed people who need asserts but don't want docstrings
> wasting ram jump through hacky hoops to do that).  Complicating these
> options more by combining additional actions on them them doesn't help.
>
> The reason we have -O and -OO generate their own special opt-1 and opt-2
> pyc files is because both of those change the generated bytecode and
> overall flow of the program by omitting instructions and data.  code using
> those will run slightly faster as there are fewer instructions.
>
> The change we're talking about here doesn't do that.  It just adds
> additional metadata to whatever instructions are generated.  So it doesn't
> feel -O related.
>

While I'm the opposite.  Metadata that is not necessary for CPython to
function and whose primary driver is better exception tracebacks totally
falls into the same camp as "I don't need docstrings" to me.


>
> While some people aren't going to like the overhead, I'm happy not
> offering the choice.
>
> > Greg, what do you think if instead of not writing it to the pyc file
> with -OO or adding a header entry to decide to read/write, we place None in
> the field? That way we can
> > leverage the option that we intend to add to deactivate displaying the
> traceback new information to reduce the data in the pyc files. The only
> problem
> > is that there will be still a tiny bit of overhead: an extra object per
> code object (None), but that's much much better than something that scales
> with the
> > number of instructions :)
> >
> > What's your opinion on this?
>
> I don't understand the pyc structure enough to comment on how that works,
>

Code to read a .pyc file and use it:
https://github.com/python/cpython/blob/a0bd9e9c11f5f52c7ddd19144c8230da016b53c6/Lib/importlib/_bootstrap_external.py#L951-L1015
(I'd explain more but it is the weekend and I technically shouldn't be
reading this thread ).

-Brett


> but that sounds fine from a way to store less data if these are stored as
> a side table rather than intermingled with each instruction itself.  *If
> anyone even cares about storing less data.*  I would not activate
> generation of that in py_compile and compileall based on the -X flag to
> disable display of tracebacks though.  A flag changing a setting of the
> current runtime regarding traceback printing detail level should not change
> the metadata in pyc files it emits.  I realize -O and -OO behave this way,
> but I don't view those as a great example. We're not writing new uniquely
> named pyc files, I suggest making this an explicit option for py_compile
> and compileall if we're going to support generation of pyc files without
> column data at all.
>
> I'm unclear on what the specific goals are with all of these option
> possibilities.
>
> Who non-hypothetically cares about a 22% pyc file size increase?  I don't
> think we should be concerned.  I'm in favor of always writing them and the
> 20% size increase that results in.  If pyc size is an issue that should be
> its own separate enhancement PEP.  When it comes to pyc files there is more
> data we may want to store in the future for performance reasons - I don't
> see them shrinking without an independent effort.
>
> Caring about additional data retained in memory at runtime makes more
> sense to me as ram cost is much greater than storage cost and is paid
> repeatedly per process.  Storing an additional reference to None on code
> objects where a column information table is perfectly fine.  That can be a
> -X style interpreter startup option.  It isn't something that needs to
> impacted by the pyc files.  Pass that option to the interpreter, and it
> just discards column info tables on code objects after loading them or
> compiling them.  If people want to optimize for a shared pyc situation with
> memory mapping techniques, that is also something that should be a separate
> enhancement PEP and not involved here.  People writing code to use the
> column information should always check it for None first, that'd be
> something we document with the new feature.
>
> -gps
>
>
>>
>> On Sat, 8 May 2021 at 22:05, Ethan Furman  wrote:
>>
>>> On 5/8/21 1:31 PM, Pablo Galindo Salgado wrote:
>>>  >> We can't piggy back on -OO as the only way to disable this, it needs
>>> to
>>>  >> have an option of its own.  -OO is unusable as code that relies on
>>> "doc"
>>>  >> strings as application data such as
>>> http://www.dabeaz.com/ply/ply.html
>>>  >> exists.
>>>  >
>>>  > -OO is the only sensible way to disable the data. There are two
>>> things to disable:

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

2021-05-08 Thread Brett Cannon
On Fri, May 7, 2021 at 7:31 PM Pablo Galindo Salgado 
wrote:

> Although we were originally not sympathetic with it, we may need to offer
> an opt-out mechanism for those users that care about the impact of the
> overhead of the new data in pyc files
> and in in-memory code objectsas was suggested by some folks (Thomas, Yury,
> and others). For this, we could propose that the functionality will be
> deactivated along with the extra
> information when Python is executed in optimized mode (``python -O``) and
> therefore pyo files will not have the overhead associated with the extra
> required data.
>

Just to be clear, .pyo files have not existed for a while:
https://www.python.org/dev/peps/pep-0488/.


> Notice that Python
> already strips docstrings in this mode so it would be "aligned" with the
> current mechanism of optimized mode.
>

This only kicks in at the -OO level.


>
> Although this complicates the implementation, it certainly is still much
> easier than dealing with compression (and more useful for those that don't
> want the feature). Notice that we also
> expect pessimistic results from compression as offsets would be quite
> random (although predominantly in the range 10 - 120).
>

I personally prefer the idea of dropping the data with -OO since if you're
stripping out docstrings you're already hurting introspection capabilities
in the name of memory. Or one could go as far as to introduce -Os to do -OO
plus dropping this extra data.

As for .pyc file size, I personally wouldn't worry about it. If someone is
that space-constrained they either aren't using .pyc files or are only
shipping a single set of .pyc files under -OO and skipping source code. And
.pyc files are an implementation detail of CPython so there  shouldn't be
too much of a concern for other interpreters.

-Brett


>
> On Sat, 8 May 2021 at 01:56, Pablo Galindo Salgado 
> wrote:
>
>> One last note for clarity: that's the increase of size in the stdlib, the
>> increase of size
>> for pyc files goes from 28.471296MB to 34.750464MB, which is an increase
>> of 22%.
>>
>> On Sat, 8 May 2021 at 01:43, Pablo Galindo Salgado 
>> wrote:
>>
>>> Some update on the numbers. We have made some draft implementation to
>>> corroborate the
>>> numbers with some more realistic tests and seems that our original
>>> calculations were wrong.
>>> The actual increase in size is quite bigger than previously advertised:
>>>
>>> Using bytes object to encode the final object and marshalling that to
>>> disk (so using uint8_t) as the underlying
>>> type:
>>>
>>> BEFORE:
>>>
>>> ❯ ./python -m compileall -r 1000 Lib > /dev/null
>>> ❯ du -h Lib -c --max-depth=0
>>> 70M Lib
>>> 70M total
>>>
>>> AFTER:
>>> ❯ ./python -m compileall -r 1000 Lib > /dev/null
>>> ❯ du -h Lib -c --max-depth=0
>>> 76M Lib
>>> 76M total
>>>
>>> So that's an increase of 8.56 % over the original value. This is storing
>>> the start offset and end offset with no compression
>>> whatsoever.
>>>
>>> On Fri, 7 May 2021 at 22:45, Pablo Galindo Salgado 
>>> wrote:
>>>
 Hi there,

 We are preparing a PEP and we would like to start some early discussion
 about one of the main aspects of the PEP.

 The work we are preparing is to allow the interpreter to produce more
 fine-grained error messages, pointing to
 the source associated to the instructions that are failing. For example:

 Traceback (most recent call last):

   File "test.py", line 14, in 

 lel3(x)

 ^^^

   File "test.py", line 12, in lel3

 return lel2(x) / 23

^^^

   File "test.py", line 9, in lel2

 return 25 + lel(x) + lel(x)

 ^^

   File "test.py", line 6, in lel

 return 1 + foo(a,b,c=x['z']['x']['y']['z']['y'], d=e)

  ^

 TypeError: 'NoneType' object is not subscriptable

 The cost of this is having the start column number and end
 column number information for every bytecode instruction
 and this is what we want to discuss (there is also some stack cost to
 re-raise exceptions but that's not a big problem in
 any case). Given that column numbers are not very big compared with
 line numbers, we plan to store these as unsigned chars
 or unsigned shorts. We ran some experiments over the standard library
 and we found that the overhead of all pyc files is:

 * If we use shorts, the total overhead is ~3% (total size 28MB and the
 extra size is 0.88 MB).
 * If we use chars. the total overhead is ~1.5% (total size 28 MB and
 the extra size is 0.44MB).

 One of the disadvantages of using chars is that we can only report
 columns from 1 to 255 so if an error happens in a column
 bigger than that then we would have to exclude it (and not show the
 highlighting) for that frame. Unsigned short will 

[Python-Dev] Re: Can't sync cpython main to my fork

2021-05-06 Thread Brett Cannon
Just today, GitHub launched a new feature to sync a branch with upstream
via the web UI.

https://github.blog/changelog/2021-05-06-sync-an-out-of-date-branch-of-a-fork-from-the-web

On Thu., May 6, 2021, 15:16 Ethan Furman,  wrote:

> On 5/6/21 7:14 AM, Jelle Zijlstra wrote:
>
>  > Maybe others have different workflows, but I don't see much of a need
>  > for keeping your fork's main branch up to date.
>
> I will occasionally do a `git push origin main` just to shut up the
> messages about being behind/ahead; other than that,
> I have no idea why I would need origin to be up to date.
>
> --
> ~Ethan~
> ___
> 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/CCOTW2ILRNTFIXRMWLVWDBT2FBANZ2Q4/
> 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/N2HVBYVYVEFT7I4PFV2G7MD6JND45A3D/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

2021-04-27 Thread Brett Cannon
On Mon, Apr 26, 2021 at 3:25 PM Stestagg  wrote:

>
>
> On Mon, Apr 26, 2021 at 10:31 PM Brett Cannon  wrote:
>
>>
>>
>> On Mon, Apr 26, 2021 at 9:37 AM Baptiste Carvello <
>> devel2...@baptiste-carvello.net> wrote:
>>
>>> Hi,
>>>
>>> sorry for being late to the party, but I may not be the only one
>>> wondering…
>>>
>>> Le 14/04/2021 à 20:56, Barry Warsaw a écrit :
>>> >
>>> > I’d forgotten that this PEP was in Deferred state.  I think it should
>>> be rejected and I plan on making that change.  importlib.metadata is a much
>>> better approach to programmatically determining package versions.
>>> >
>>> >
>>> https://docs.python.org/3/library/importlib.metadata.html#distribution-versions
>>>
>>> This is indeed the correct approach, thanks for letting me learn this.
>>>
>>> However, I unsuccessfully searched for the canonical way to look up the
>>> distribution name based on either a module name or an imported module
>>> object. Is there one?
>>>
>>
>> If you mean how to tie a module back to its name on PyPI, you should be
>> able to look up the "Name" in the project's metadata:
>> https://docs.python.org/3/library/importlib.metadata.html#distribution-metadata
>> .
>>
>>
> The missing bit here, for me, is how do you map a module back to it's
> project (distribution)?
>
> For example:
>
> ```
> >>> import bs4
> >>> bs4.__version__
> '4.9.1'
> >>> importlib.metadata.metadata('bs4')
> PackageNotFoundError: bs4
> ```
>
> This is because the distribution calls itself 'beautifulsoup4' instead.
>

Unfortunately I thought importlib.metadata would have used the module name
instead of the metadata details, but in hindsight am guessing that the
.dist-info is what it's using to do the lookup and that's based on the
package name instead of the project name.

This is a long-standing issue with projects that use project names which
differ from their module name, but there's no good way without checking
what files a project installed (which is what you're doing below).

-Brett


>
> The same goes for another package: `umap`, for which the distribution is
> called `umap-learn`
>
>
> This is the best I could come up with from reading the docs:
>
> import bs4  #<- This is the module we want the version of
>
> import importlib
> import sys
> from itertools import chain
> from pathlib import Path
>
> loaders = sys.meta_path
>
> target_path = Path(bs4.__file__)
>
> distros = list(chain(*(finder.find_distributions() for finder in
> loaders if hasattr(finder, 'find_distributions'
> distros_files = chain(*(f for f in (d.files for d in distros)))
> distro_files = [(d, d.locate_file(f)) for d in distros if d.files for
> f in d.files]
> matching = [d for d, f in distro_files if f == target_path]
>
> for match in matching:
> print("Found Version:", match.version)
>
> 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/ON5SH2F654I7NEMCYXRH253QRN32LQGG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

2021-04-26 Thread Brett Cannon
On Mon, Apr 26, 2021 at 9:37 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Hi,
>
> sorry for being late to the party, but I may not be the only one wondering…
>
> Le 14/04/2021 à 20:56, Barry Warsaw a écrit :
> >
> > I’d forgotten that this PEP was in Deferred state.  I think it should be
> rejected and I plan on making that change.  importlib.metadata is a much
> better approach to programmatically determining package versions.
> >
> >
> https://docs.python.org/3/library/importlib.metadata.html#distribution-versions
>
> This is indeed the correct approach, thanks for letting me learn this.
>
> However, I unsuccessfully searched for the canonical way to look up the
> distribution name based on either a module name or an imported module
> object. Is there one?
>

If you mean how to tie a module back to its name on PyPI, you should be
able to look up the "Name" in the project's metadata:
https://docs.python.org/3/library/importlib.metadata.html#distribution-metadata
.

-Brett


>
> Looks like it could be computed based on information in
> "*.egg-info/installed-files.txt", but it's far from trivial. Is
> "installed-files.txt" even guaranteed to exist for all distributions?
>
> Cheers,
> Baptiste
> ___
> 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/SVQ777EGE56OIWHIKPCURGPXGMUJ7HCY/
> 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/OMHAJ7WU7TVM6WWQHYPI3AYGORCKUNAK/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 563 and 649: The Great Compromise

2021-04-25 Thread Brett Cannon
On Sat., Apr. 24, 2021, 20:55 Carl Meyer,  wrote:

> Hi Larry,
>
> This is a creative option, but I am optimistic (now that the SC
> decision has removed the 3.10 deadline urgency) that we can find a
> path forward that is workable for everyone and doesn't require a
> permanent compiler feature flag and a language that is permanently
> split-brained about annotation semantics. Since I have access to a
> real-world large codebase with almost complete adoption of type
> annotations (and I care about its import performance), I'm willing to
> test PEP 649 on it (can't commit to doing it right away, but within
> the next month or so) and see how much import performance is impacted,
> and how much of that can be gained back by interning tweaks as
> discussed in the other thread.


Thanks for the kind offer, Carl! I know I would find it useful in
evaluating PEP 649 is we had a real-world perf evaluation like you're
offering.


My feeling is that if the performance
> turns out to be reasonably close in a real codebase, and we can find a
> workable solution for `if TYPE_CHECKING`, we should go ahead with PEP
> 649: IMO aside from those two issues its semantics are a better fit
> for the rest of the language and preferable to PEP 563.
>
> I do think that a solution to the `if TYPE_CHECKING` problem should be
> identified as part of PEP 649. My favorite option there would be a new
> form of import that is lazy (the import does not actually occur until
> the imported name is loaded at runtime). This has prior art in
> previous discussions about "module descriptors"; IIRC Neil Schemenauer
> even had a branch a while ago where all module attributes were
> modified to behave this way (I might be remembering the details
> wrong.)


Nope, you're remembering right; it was Neil. I think he started looking at
this topic at the core dev sprints when they were hosted at Microsoft
(2018?).

It also has overlap with use cases served by the existing
> `demandimport` library used by hg, and `importlib.util.LazyLoader`,
>

I'm not sure if it's diverged, but he's solution was originally a copy of
importlib.util.LazyLoader, so the approach was the same.

although it is strictly more capable because it can work with `from
> module import Thing` style imports as well. If there's any interest in
> this as a solution to inter-module annotation forward references, I'm
> also willing to work on that in the 3.11 timeframe.
>

I know I would be curious, especially if backwards compatibility can be
solved reasonably (for those that haven't lived this, deferred execution
historically messes up code relying on import side-effects and trackbacks
are weird as they occur at access time instead of at the import statement).

-Brett


> Carl
> ___
> 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/VBG2LXU6OHROQ3NPF373L7W4W23B24DE/
> 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/NDM5WTHZUJIZSG7VKWTVNFJ7AGIBCWVG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Asking for clarifications in PEP 646 and postponing to Python 3.11

2021-04-23 Thread Brett Cannon
First, the SC is postponing considering accepting
https://www.python.org/dev/peps/pep-0646/ any further until Python 3.11.
There's unfortunately not enough time before b1 to get requested updates
into the PEP, discuss the PEP again, approve it, and then review an
implementation thoroughly.

Second, this PEP is proposing new syntax for Python but that detail is
barely touched upon. For instance, there isn't a direct proposal of what
grammar changes that should be made. There's also no discussion of what the
exact runtime semantics should be. While a lot could be inferred by "it's
allowing * within indexing contexts" (which is basically what the PEP is
proposing from a syntactic perspective), that isn't a spec.  As such, we
are asking that the PEP be expanded upon to fully explain the proposed
syntactic change, it's impact on the language and it's spec, etc.

Once this update happens, we will be happy to look at the PEP again for
consideration of inclusion in Python 3.11.


-Brett (on behalf of the SC)
___
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/5BVYPRJKQHKDLLN3T7H4WXP2NAD2ITFH/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Keeping Python a Duck Typed Language.

2021-04-22 Thread Brett Cannon
On Thu, Apr 22, 2021 at 4:11 AM Paul Moore  wrote:

> On Thu, 22 Apr 2021 at 11:21, Paul Moore  wrote:
> >
> > On Thu, 22 Apr 2021 at 11:06, Chris Angelico  wrote:
> > >
> > > Someone will likely correct me if this is inaccurate, but my
> > > understanding is that that's exactly what you get if you just don't
> > > give a type hint. The point of type hints is to give more information
> > > to the type checker when it's unable to simply infer from usage and
> > > context.
> >
> > Hmm, I sort of wondered about that as I wrote it. But in which case,
> > what's the problem here? My understanding was that people were
> > concerned that static typing was somehow in conflict with duck typing,
> > but if the static checkers enforce the inferred duck type on untyped
> > arguments, then that doesn't seem to be the case. Having said that, I
> > thought that untyped arguments were treated as if they had a type of
> > "Any", which means "don't type check".
>
> Looks like it doesn't:
>
> > cat .\test.py
> def example(f) -> None:
> f.close()
>
> import sys
> example(12)
> example(sys.stdin)
> PS 12:00 00:00.009 C:\Work\Scratch\typing
> > mypy .\test.py
> Success: no issues found in 1 source file
>
> What I was after was something that gave an error on the first call,
> but not on the second. Compare this:
>
> > cat .\test.py
> from typing import Protocol
>
> class X(Protocol):
> def close(self): ...
>
> def example(f: X) -> None:
> f.close()
>
> import sys
> example(12)
> example(sys.stdin)
> PS 12:03 00:00.015 C:\Work\Scratch\typing
> > mypy .\test.py
> test.py:10: error: Argument 1 to "example" has incompatible type
> "int"; expected "X"
> Found 1 error in 1 file (checked 1 source file)
>

Do note that this is only based on what mypy does, not necessarily what all
Python type checkers do. I.e. it's quite possible pytype, pyre, or pyright
infer more (especially https://pypi.org/project/pytype/ since they
specifically say they infer types).
___
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/Y42GJAJH3BSW5ZDLZQKDZDWNAGRMXDQ3/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: In support of PEP 649

2021-04-15 Thread Brett Cannon
On Thu, Apr 15, 2021 at 12:01 PM Samuel Colvin  wrote:

> I've read the recent discussions
> 
> regarding PEP 649 and PEP 563 with interest, Larry Hastings recently
> contacted me when prompted
> 
> to do so in a related discussion.
>
> I maintain pydantic  which uses
> type annotations to provide runtime data validation.
>
> I'm extremely worried that if PEP 649 gets rejected, pydantic will not be
> able to fully support python 3.10 and may even end up getting abandoned, at
> best it will be much slower and more brittle.
>
> Please, please put pragmatism over principle and accept PEP 649.
>

Please don't phrase the decision in these terms. While for Pydantic PEP 649
is more pragmatic, that does not mean PEP 563 isn't pragmatic for other
people for other reasons. Making this an "us versus them" discussion just
makes the whole situation feel confrontational when instead everyone is
trying to figure out the best thing for everybody when there's no perfect
answer.
___
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/QAH7UBRM2PF3FEB7K4EYDDXJDD4G4CFQ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

2021-04-15 Thread Brett Cannon
On Thu, Apr 15, 2021 at 10:53 AM Antoine Pitrou  wrote:

> On Thu, 15 Apr 2021 10:28:53 -0700
> Brett Cannon  wrote:
> > On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker 
> > wrote:
> >
> > > On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner 
> > > wrote:
> > >
> > >> Paul Bryan:
> > >> > Seems like this is something that should make its way into stdlib?
> > >>
> > >> In the last 10 years, the trend is more to remove anything related to
> > >> packaging *outside* the stdlib :-)
> > >
> > >
> > > Well, maybe all of us don't think that's a good idea ;-)
> > >
> >
> > As an active participant in the PyPA side of the packaging ecosystem and
> > one of the maintainers of 'packaging', I am definitely NOT in favour of
> > moving any of 'packaging' into the stdlib, nor breaking it up. We are
> > taking distutils out of the stdlib for a reason. Backsliding on plans
> that
> > have been in place for years is not something I would want to see happen
> as
> > the motivations have not changed.
>
> This seems gratuitously dogmatic. Version numbers are a simple feature
> that is stably encoded in PEP 440. It's purely computational, does
> not involve reading or saving any persistent state in the filesystem,
> making any network access, etc. Why wouldn't it have its place in the
> stdlib?
>

Technically PyPA specs might start as PEPs but their official home is
packaging.python.org and updates can occur there outside of the PEP
process. In the case of version specifiers (
https://packaging.python.org/specifications/version-specifiers/), they
point back to the original PEP, but that is not universally true nor
guaranteed to hold in the future. In other words I personally don't view
the fact that it's a PEP as a reason to have it in the stdlib (else pretty
much every single packaging PEP is missing).

We also have other things standardized in PEPs and not covered in the
stdlib, e.g. @ as an operator.

So I don't think version comparison occurs often enough to be in the
stdlib, and the fact that an external project exists which isn't interested
in being put in the stdlib suggests to me it isn't worth doing.

But that's a separate topic to discuss at the language summit. :)


>
> > > But anyway, I would say removing anything *related* to packaging
> outside
> > > the stdlib is a bad idea -- requiring an external tool to build a
> package
> > > is OK, but requireing an external use packages, not so much.
> > >
> >
> > You can totally use a package already as things exist today and will in
> the
> > future; you're just wanting a specific way to interpret a package's
> > metadata which I don't view as the same thing.
>
> That specific way is a Python standard (PEP 440). Having the
> functionality in the stdlib would encourage people to use it. Not
> having it in the stdlib encourages people to use adhoc version parsing,
> or worse, naive string comparison.
>

I don't know if I draw the same line since the packaging community is
relying on 'packaging' without issue for this exact thing.


>
> > So asking every Python project to set a
> > __version__ isn't going to change accessibility of version numbers when
> it
> > comes to installed projects.
>
> That doesn't have much to do with the suggestion of shipping a Version
> class in the stdlib, though. Many projects already provide a
> __version__, and that field is often inspected programmatically in
> dependent packages (to work around behaviour changes, for example).
>

But this thread is about standardizing on __version__ which then led to
wanting to bring in some Version object into the stdlib to make that more
useful. So to me they are tied together, else a separate thread should
probably be started if a new module *just *for version parsing support is
desired.
___
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/AYJ4JBTIVQTJY7IQYZMYCUY6VSXSMXXY/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

2021-04-15 Thread Brett Cannon
On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker 
wrote:

> On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner 
> wrote:
>
>> Paul Bryan:
>> > Seems like this is something that should make its way into stdlib?
>>
>> In the last 10 years, the trend is more to remove anything related to
>> packaging *outside* the stdlib :-)
>
>
> Well, maybe all of us don't think that's a good idea ;-)
>

As an active participant in the PyPA side of the packaging ecosystem and
one of the maintainers of 'packaging', I am definitely NOT in favour of
moving any of 'packaging' into the stdlib, nor breaking it up. We are
taking distutils out of the stdlib for a reason. Backsliding on plans that
have been in place for years is not something I would want to see happen as
the motivations have not changed.


>
> But anyway, I would say removing anything *related* to packaging outside
> the stdlib is a bad idea -- requiring an external tool to build a package
> is OK, but requireing an external use packages, not so much.
>

You can totally use a package already as things exist today and will in the
future; you're just wanting a specific way to interpret a package's
metadata which I don't view as the same thing.


>
> Presumably that's why importlib.metadata exists in the stdlib.
>

It's there because of how tightly it binds to the import system; same goes
for importlib.resources.


>
> Version is arguably useful from the package user side. As I believe Victor
> mentioned, there are two uses for version information: display to the user
> -- for which version strings are fine, or programmatic comparison -- for
> which something like the Version object is very helpful. Do we only need to
> use version information programmatically when we are creating (or
> installing) packages? I don't think so -- I know I have code that (poorly)
> does version checking programmatically.
>

No one said that's the *only* use-case, but just because there's more than
that does not mean we should move any packaging code into the stdlib to
support a zero-install use-case.

A key point I want to make here is the version metadata is in every
project's .dist-info/METADATA file. That's what importlib.metadata knows
how to read and hence why people have been suggesting to use it. The
version information is fundamental to the wheel format and in fact you
can't have a wheel without it. So asking every Python project to set a
__version__ isn't going to change accessibility of version numbers when it
comes to installed projects.
___
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/V5WJW2HRRTSUN34ZHTVV2HVSBS4MMBSX/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

2021-04-15 Thread Brett Cannon
On Thu, Apr 15, 2021 at 9:36 AM David Mertz  wrote:

> On Thu, Apr 15, 2021 at 4:55 PM Christopher Barker 
> wrote:
>
>> Presumably that's why importlib.metadata exists in the stdlib.
>>
>
> I was so hopeful about this, but in the end... not really.  I have not
> used this capability before.  Here are a few different situations I know of:
>
> >>> import re, statistics, pandas, vaex, bs4
> >>> for mod in [re, statistics, pandas, vaex, bs4]:
> ... try:
> ... print(mod.__name__, end=" ")
> ... print(mod.__version__)
> ... except:
> ... print("__version__ not present")
> ...
> re 2.2.1
> statistics __version__ not present
> pandas 1.2.4
> vaex {'vaex': '4.1.0', 'vaex-core': '4.1.0', 'vaex-viz': '0.5.0',
> 'vaex-hdf5': '0.7.0', 'vaex-server': '0.4.0', 'vaex-astro': '0.8.0',
> 'vaex-jupyter': '0.6.0', 'vaex-ml': '0.11.1'}
> bs4 4.9.3
>
> >>> for mod in [re, statistics, pandas, vaex, bs4]:
> ... try:
> ... print(mod.__name__, version(mod.__name__))
> ... except Exception as err:
> ... print(mod.__name__, repr(err))
> ...
> re PackageNotFoundError('re')
> statistics PackageNotFoundError('statistics')
> pandas 1.2.4
> vaex 4.1.0
> bs4 PackageNotFoundError('bs4')
>
> It seems like (somehow or another) importlib.metadata is doing something
> perhaps more useful for vaex.  But it is doing distinctly worse for re,
> statistics, and bs4.
>

I don't see how importlib.metadata plays into your code sample since you
didn't import it to use it?


>
> Version is arguably useful from the package user side. As I believe Victor
>> mentioned, there are two uses for version information: display to the user
>> -- for which version strings are fine, or programmatic comparison -- for
>> which something like the Version object is very helpful. Do we only need to
>> use version information programmatically when we are creating (or
>> installing) packages? I don't think so -- I know I have code that (poorly)
>> does version checking programmatically.
>>
>
And is installing a dependency that much of a burden for that code?


>
> I think the key thing that Chris and I are pointing to is that there is a
> definite use for versions that is NOT for package maintainers/creators.
> Interactive use is definitely one such case, and eyeballing something, even
> if it is the oddball use that Vaex has, can help with figuring out an
> issue.  But in actual code, I relatively often do something like this.  Or
> rather, the below is what I would find really nice to be able to do.
>
> ver = robust_version(module)
> if ver >= (5, 2, 1):
> doit_modern_style()
> elif ver < (5, 2, 1):
> doit_old_style
> else:
> doit_unversioned_style()
>
> I'd like code like that to ALWAYS succeed.  No exceptions raised.  And it
> would *usually* use reasonable heuristics to figure out some sort of
> structured version info as well as is possible.  I.e. probably look in
> several places and return some custom object that represents a "best
> effort."  That object might be like NaN in being neither less than nor more
> than other things, in the fallback case.
>

All doable with importlib.metadata and 'packaging'.

-Brett


>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> 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/4575HZHNN45FNOTKH5DSD6NKNRUJGXFU/
> 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/UTTUEIUVQHAIYJSIT3SSS4PBVZX22V7I/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-14 Thread Brett Cannon
On Wed, Apr 14, 2021 at 12:08 PM Guido van Rossum  wrote:

> Let's just wait for the SC to join the discussion. I'm sure they will,
> eventually.
>

FYI the PEP has not been sent to us via
https://github.com/python/steering-council/issues as ready for
pronouncement, so we have not started officially discussing this PEP yet.

-Brett


>
> On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings 
> wrote:
>
>> On 4/14/21 10:44 AM, Guido van Rossum wrote:
>>
>> besides the cost of closing the door to relaxed annotation syntax,
>> there's the engineering work of undoing the work that was done to make
>> `from __future__ import annotations` the default (doing this was a
>> significant effort spread over many commits, and undoing will be just as
>> hard).
>>
>>
>> I'm not sure either of those statements is true.
>>
>> Accepting PEP 649 as written would deprecate stringized annotations, it's
>> true.  But the SC can make any decision it wants here, including only
>> accepting the new semantics of 649 without deprecating stringized
>> annotations.  They could remain in the language for another release (or
>> two? or three?) while we "kick the can down the road".  This is not without
>> its costs too but it might be the best approach for now.
>>
>> As for undoing the effort to make stringized annotations the default, git
>> should do most of the heavy lifting here.  There's a technique where you
>> check out the revision that made the change, generate a reverse patch,
>> apply it, and check that in.  This creates a new head which you then
>> merge.  That's what I did when I created my co_annotations branch, and at
>> the time it was literally the work of ten minutes.  I gather the list of
>> changes is more substantial now, so this would have to be done multiple
>> times, and it may be more involved.  Still, if PEP 649 is accepted, I would
>> happily volunteer to undertake this part of the workload.
>>
>>
>> Cheers,
>>
>>
>> */arry*
>> ___
>> 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/LRVFVLH4AHF7SX5MOEUBPPII7UNINAMJ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> 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/V5ASSMVVAP4RZX3DOGJIDS52OEJ6LP7C/
> 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/7LXQATCTABW7HCSAUGAGFRJFFRLW5DVU/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

2021-04-14 Thread Brett Cannon
On Tue, Apr 13, 2021 at 6:58 PM Inada Naoki  wrote:

> On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings 
> wrote:
> >
> >
> > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> >
> >
> > Because typing is, to many folks, a Really Important Concept, and it's
> confusing to use the same syntax ("x: blah blah") for different purposes,
> in a way that makes it hard to tell whether a particular "blah blah" is
> meant as a type or as something else -- because you have to know what's
> introspecting the annotations before you can tell. And that introspection
> could be signalled by a magical decorator, but it could also be implicit:
> maybe you have a driver that calls a function based on a CLI entry point
> name, and introspects that function even if it's not decorated.
> >
> >
> > I'm not sure I understand your point.  Are you saying that we need to
> take away the general-purpose functionality of annotations, that's been in
> the language since 3.0, and restrict annotations to just type hints...
> because otherwise an annotation might not be used for a type hint, and then
> the programmer would have to figure out what it means?  We need to take
> away the functionality from all other use cases in order to lend clarity to
> one use case?
> >
>
> I don't think we need to take away "general purpose functionality".
> But if we define type hinting is 1st class use case of annotations,
> annotations should be optimized for type hinting.  General purpose use
> case should accept some limitation and overhead.
>
> On the other hand, if we decide general purpose functionality is 1st
> class too, we shouldn't annotation syntax different from Python
> syntax.
>

Has anyone reached out to people like Pydantic, FastAPI, typer, etc. to see
what they think of this PEP? For instance, are they having issues with the
way things are today enough that this is a very clear win for them?

-Brett


>
> But annotations should be optimized for type hinting anyway. General
> purpose use case used only is a limited part of application. On the
> other hand, type hint can be used almost everywhere in application
> code base. It must cheap enough.
>
> Regards,
>
> --
> Inada Naoki  
> ___
> 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/UGFWTZUGH6QZRHF3FKTQHZLYG2ZNX5EG/
> 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/YKVYJMLUWUVT4KMLUNEQYVBZWNAPR4GV/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Typing syntax and ecosystem

2021-04-14 Thread Brett Cannon
On Tue, Apr 13, 2021 at 5:12 PM Hugh Fisher  wrote:

> On Wed, 14 Apr 2021 at 08:21, Barry Warsaw  wrote:
> > I wouldn’t necessarily be opposed to bundling a type checker with the
> interpreter/stdlib, but I think there are some issues with it.  Just off
> the top of my head (there are undoubtedly many more issues to resolve):
> >
> > * Which type checker would we adopt or adapt, if any?
>
> Mypy.
> This has become an implementation issue, not one of which type
> system to adopt. A lot of code, even in the stdlib, has been annotated
> but I'm not aware of multiple different annotations with different
> semantics or type systems being created.
>

But there are feature concerns there as well, e.g. mypy and pytype offer
different "extras", even if the type checkers all align on semantics (which
I know they work on in the typing SIG). There's also variance in
maintenance, code complexity, etc. To me, this is not a clear-cut "mypy
wins" situation.

And I know Luciano said mypy because it's "the type checker hosted in the
python organization on github", but I don't know if the SC would approve
that today (Guido brought mypy into the org during his BDFL days), and
instead my guess is it would have ended up in the psf org like Black did.


>
> For example, type equivalence by name only is used in Ada (or was,
> it's been many years) and probably other languages. In equivalence
> by name, the following code would not pass the type checker.
> x : list[int]
> y : list[int]
> x = y # Type error
>
> But I'm not aware of anyone implementing type by name equivalence
> for Python, and the original PEP 483 seems to explicitly close off that
> possibility. Instead the assumption seems to be Java/C++ structural
> equivalence for types.
>
> Skimming a bunch of current type system related PEPs, I'm not seeing
> anything that a Java/C++ programmer would find unfamiliar. And this is
> probably a good thing.
>
> > * Which parts of the typing system require more frequent release cycles?
> > * Is there a core technology that could be put in the stdlib and still
> allow experimentation?
> > * Would the type checker authors become core developers?
> > * Do the same feature release / deprecation policies apply?
>
> No answers from me.
>

My guess is the closest we would ever come is some ensuretypechecker
situation like we have with ensurepip, but pip is done that way for
bootstrapping reasons and we don't *need *a type checker for bootstrapping.

-Brett


>
> > I would still be opposed to requiring type hinting in Python.
>
> I'm opposed to requiring type hints on everything, I want to still be
> able to write
> x = 1
> x = "hello"
> etc without declaring any kind of type for x.
>
> --
>
> cheers,
> Hugh Fisher
> ___
> 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/OABB53NTCBU6EKYQVVVY4IU2275XO4R4/
> 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/BVQAYB4N3JKHEJ5A6NPSBKT7OWQSYQ3K/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

2021-04-14 Thread Brett Cannon
On Wed, Apr 14, 2021 at 5:00 AM Joachim Wuttke 
wrote:

> gzip compression, using class GzipFile from gzip.py, by default
> inserts a timestamp to the compressed stream. If the optional
> argument `mtime` is absent or None, then the current time is used [1].
>
> This makes outputs non-deterministic, which can badly confuse
> unsuspecting users: If you run "diff" over two outputs to see
> whether they are unaffected by changes in your application,
> then you would not expect that the *.gz binaries differ just
> because they were created at different times.
>
> I'd propose to introduce a new constant `NO_TIMESTAMP` as
> possible value of `mtime`.
>
> Furthermore, if policy about API changes allows, I'd suggest
> that `NO_TIMESTAMP` become the new default value for `mtime`.
>
> How to proceed from here? Is this the kind of proposals that
> has to go through a PEP?
>

For something like this you would open an issue and see if a core developer
is intrigued enough to work with you to see the change occur; no PEP is
necessary.

-Brett


>
> - Joachim
>
> [1]
>
> https://github.com/python/cpython/blob/6f1e8ccffa5b1272a36a35405d3c4e4bbba0c082/Lib/gzip.py#L163
>
> ___
> 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/OTUGLATLYB736SAPPRWSSXWAKM5JHWZN/
> 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/Y2YFL25BF2LNT7VFSZALTZH5S57NA2J6/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Typing syntax and ecosystem

2021-04-12 Thread Brett Cannon
On Mon, Apr 12, 2021 at 2:19 PM  wrote:

> April 12, 2021 4:59 PM, "Brett Cannon"  wrote:
>
> > On Mon, Apr 12, 2021 at 3:01 AM Hugh Fisher 
> wrote:
> >
> >>> Message: 1
> >>> Date: Sun, 11 Apr 2021 13:31:12 -0700
> >>> From: Barry Warsaw 
> >>> Subject: [Python-Dev] Re: PEP 647 Accepted
> >>
> >>>
> >>> This is something the SC has been musing about, but as it’s not a
> fully formed idea, I’m a little
> >> hesitant to bring it up. That said, it’s somewhat relevant: We wonder
> if it may be time to in a
> >> sense separate the typing syntax from Python’s regular syntax.
> TypeGuards are a case where if
> >> typing had more flexibility to adopt syntax that wasn’t strictly legal
> “normal” Python, maybe
> >> something more intuitive could have been proposed. I wonder if the
> typing-sig has discussed this
> >> possibility (in the future, of course)?
> >>
> >> [ munch ]
> >>
> >>>
> >>> Agreed. It’s interesting that PEP 593 proposes a different approach to
> enriching the typing
> >> system. Typing itself is becoming a little ecosystem of its own, and
> given that many Python users
> >> are still not fully embracing typing, maybe continuing to tie the
> typing syntax to Python syntax is
> >> starting to strain.
> >>
> >> I would really like to see either "Typed Python" become a different
> programming
> >> language, or progress to building type checking into the CPython
> implementation
> >> itself. (Python 4 seems to me the obvious release.) The current halfway
> approach
> >> is confusing and slightly ridiculous.
> >
> > Please don't denigrate the hard work people have put in to even bring
> forward the idea of typing in
> > Python by saying it's "slightly ridiculous".
> >
> > -Brett
>
> Aren't people allowed to have their own opinions?


Yes, of course.


>   Please, I hate to see this list descend further and further into such
> knee-jerk reactions.


It wasn't a knee-jerk reaction. I did take the time to think about replying.


>   If criticism of any current implementation of any construct becomes
> off-limits is automatically classed as "denigrating", there is no reason
> for this list to exist.  You might not agreed with the criticism, but you
> should at least be open to discussion.
>

And I didn't try to shut down the discussion. My point was not about the
intent of the message, but how that message was delivered. Being
considerate and acknowledging people's time and effort is important and I
don't think saying something is "ridiculous" does that.

Had the sentences ended at "confusing" or said something like "I don't
think it's as optimal as it could be" or "I think it could be better" are
all fine. But saying that the current approach is "arousing or deserving
ridicule : extremely silly or unreasonable : absurd, preposterous" as defined
by Merriam-Webster <https://www.merriam-webster.com/dictionary/ridiculous>
is not necessary to make the point; it could have been phrased in such a
way as to be a bit more respectful to those who have put in the time and
effort to get things to where they are.
___
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/OGASYCZ7P4YXW2WHGAYOOEBFWMRCJFGM/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Typing syntax and ecosystem

2021-04-12 Thread Brett Cannon
On Mon, Apr 12, 2021 at 3:01 AM Hugh Fisher  wrote:

> > Message: 1
> > Date: Sun, 11 Apr 2021 13:31:12 -0700
> > From: Barry Warsaw 
> > Subject: [Python-Dev] Re: PEP 647 Accepted
>
> >
> > This is something the SC has been musing about, but as it’s not a fully
> formed idea, I’m a little hesitant to bring it up.  That said, it’s
> somewhat relevant: We wonder if it may be time to in a sense separate the
> typing syntax from Python’s regular syntax.  TypeGuards are a case where if
> typing had more flexibility to adopt syntax that wasn’t strictly legal
> “normal” Python, maybe something more intuitive could have been proposed.
> I wonder if the typing-sig has discussed this possibility (in the future,
> of course)?
>
> [ munch ]
>
> >
> > Agreed.  It’s interesting that PEP 593 proposes a different approach to
> enriching the typing system.  Typing itself is becoming a little ecosystem
> of its own, and given that many Python users are still not fully embracing
> typing, maybe continuing to tie the typing syntax to Python syntax is
> starting to strain.
>
> I would really like to see either "Typed Python" become a different
> programming
> language, or progress to building type checking into the CPython
> implementation
> itself. (Python 4 seems to me the obvious release.) The current halfway
> approach
> is confusing and slightly ridiculous.
>

Please don't denigrate the hard work people have put in to even bring
forward the idea of typing in Python by saying it's "slightly ridiculous".

-Brett


>
> The first, a separate programming language, would be like RATFOR and CFront
> in the past and TypeScript today. Typed Python can have whatever syntax the
> designers want because it doesn't have to be compatible with Python, just
> as
> TypeScript is not constrained by JavaScript. A type checker translates
> the original
> Typed Python source into "dynamic" or "classic" Python for execution.
> (Maybe
> into .pyc instead of .py?)
>
> This would mean no overhead for type checking in CPython itself. No need to
> contort the parser into ignoring bits of code that are, in effect,
> syntax checked
> comments. And for the typing in Python enthusiasts, you won't have to
> listen
> to people like me complaining.
>
> The second approach is to assume that type checking in Python is useful and
> popular. Not with me, but I'm willing to accept that I'm in the minority
> and can
> be ignored - after all, I can still write my Python code without type
> annotations.
> If so running a type checker as a separate step, as we do at the moment, is
> like asking C programmers to run the preprocessor by hand.
>
> In today's world of continuous build and integration, it seems silly
> to me to have
> a type checker read the source, scan into lexical tokens, build an
> abstract syntax
> tree, perform semantic analysis with type checking, and then throw it away
> before running an interpreter which reads the same source, scans into
> lexical
> tokens, builds an abstract syntax tree, and executes. On the purely
> pragmatic
> level there is an extra chance for mismatches and things to go wrong; and
> from
> an environmental viewpoint it isn't a great use of resources.
>
> --
>
> cheers,
> Hugh Fisher
> ___
> 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/2DMJPVE4T6SMXIPQJVWOOSYWJX6DA22H/
> 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/ZTXS5JWP5LQ3CRFTXJUREXBB3I5GQTJS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: When we remove 'U' mode of open()?

2021-04-07 Thread Brett Cannon
On Wed, Apr 7, 2021 at 10:01 AM Serhiy Storchaka 
wrote:

> 07.04.21 19:13, Victor Stinner пише:
> > Hi Inada-san,
> >
> > I'm +0 on removing again the flag, but I would prefer to not endorse
> > the responsibility. I am already responsible for enough incompatible
> > changes in Python 3.10 :-D
> >
> > Some context on this "U" open mode. The flag is accepted by many
> > functions opening files. It is deprecated (emit DeprecationWarning)
> > for 9 years (Python 3.3, 2012).
>
> It was silently deprecated before 3.3 (perhaps it was no-op since 3.0).
>
> I added DeprecationWarning with intention to remove this option in all
> functions accepting it. The only non-trivial support of the "U" mode was
> left in ZipFile.open(), and it was broken since beginning.
>

I think at this point the DeprecationWarning has definitely been on long
enough, there was an explicit warning about it in Python 3.9, and 3.10 will
be nearly 2 years removed from 2.7 reaching EOL which is the only place
where "U" may still be used. So I think it's fine to drop "U" in 3.10.
___
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/VTROKN5UOU3EN6F3OLX5RUK7TVETAXKB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: How to attract developer attention to issue tracker items?

2021-04-07 Thread Brett Cannon
On Tue, Apr 6, 2021 at 11:22 PM  wrote:

> Hi developers,
>
> What should / shouldn't I do to attract any python developer response to
> issue tracker items?  I am unsure of the proper procedure to follow so I am
> asking here first.
>

What you're doing here is probably your best bet. Unfortunately the lack of
response might stem from no core devs being interested in curses (but if
any are then hopefully this email will spark their interest).

-Brett


>
> I have filed two issues on the python issue tracker for python curses
> issues:
>
> 1.  # 43715, a documentation update request (suggested additional
> documentation file uploaded)
> 2.  # 43716, a possible ABI issue for the curses.pair_number() function
> return value in a Windows environment
>
> With respect to the documentation issue, I would appreciate any review of
> whether the suggested documentation addition that I uploaded as a text file
> is acceptable as-is or whether further refinement or correction is needed.
>
> In the case of the possible ABI issue I am uncertain whether the issue is
> in
> the python interface code or in the underlying curses implementation
> library
> (windows-curses V2.2.0 using PDCurses).  I would appreciate it if anyone
> knowledgeable of the python curses interfacing code could advise me whether
> I need to pursue the issue with the third party library provider or with
> the
> python development team.  At the moment all that I know is that the
> "workaround" that I discovered corrects the issue under Windows but is not
> necessary under linux / ncurses (in my testing I used Ubuntu 20.04 WSL2 to
> confirm that fact).
>
> TIA for your patience with my ignorance of the proper procedures and
> channels.
>
> My environment:
>
> Windows 10 Pro 64 (latest version)
> Python 3.8.9 (tags/v3.8.9:a743f81, Apr  6 2021, 14:02:34) [MSC v.1928 64
> bit
> (AMD64)]
> Windows-curses V2.2.0
>
> Peter
> --
>
> ___
> 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/RBGBZOJ267YUTTZ3JO5XUJBEG66MKL2W/
> 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/B5E3BPIOCALTPIBOJU5Z7KJ3MFUQUSSJ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Weird io.OpenWrapper hack to use a function as method

2021-03-31 Thread Brett Cannon
On Wed., Mar. 31, 2021, 18:56 Inada Naoki,  wrote:

> Do we need _pyio at all?
> Does PyPy or any other Python implementation use it?
>

https://www.python.org/dev/peps/pep-0399/ would suggest rolling back Python
support is something to avoid.


> On Wed, Mar 31, 2021 at 9:36 PM Victor Stinner 
> wrote:
> >
> > Hi,
> >
> > The io module provides an open() function. It also provides an
> > OpenWrapper which only exists to be able to store open as a method
> > (class or instance method). In the _pyio module, pure Python
> > implementation of the io module, OpenWrapper is implemented as:
> >
> > class OpenWrapper:
> > """Wrapper for builtins.open
> >
> > Trick so that open won't become a bound method when stored
> > as a class variable (as dbm.dumb does).


>
> > See initstdio() in Python/pylifecycle.c.
> > """
> > def __new__(cls, *args, **kwargs):
> > return open(*args, **kwargs)
> >
> > I would like to remove this class which is causing troubles in the PEP
> > 597 implementation, but I don't know how. Simplified problem:
> > ---
> > def func():
> > print("my func")
> >
> > class MyClass:
> > method = func
> >
> > func() # A
> > MyClass.method() # B
> > obj = MyClass()
> > obj.method() # C
> > ---
> >
> > With this syntax, A and B work, but C fails with TypeError: func()
> > takes 0 positional arguments but 1 was given.
> >
> > If I decorate func() with @staticmethod, B and C work, but A fails
> > with TypeError: 'staticmethod' object is not callable.
> >
> > Is OpenWrapper the only way to have a callable object which works in
> > the 3 variants A, B and C?
> >
> > A, B and C work if MyClass is modified to use staticmethod:
> >
> > class MyClass:
> > method = staticmethod(func)
> >
> > Victor
> > --
> > Night gathers, and now my watch begins. It shall not end until my death.
> > ___
> > 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/QZ7SFW3IW3S2C5RMRJZOOUFSHHUINNME/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Inada Naoki  
> ___
> 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/BOSZENKZRZCTIYWDRBRLWT4GKHWGDLWP/
> 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/6WKW5LJKEFSRTZFXXCIS3UWI3YOSKP7L/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Where and how can I contribute?

2021-03-26 Thread Brett Cannon
devguide.python.org has some guidelines on how to find easy issues to work
on. You can also ask for help on core-mentors...@python.org.

On Fri, Mar 26, 2021 at 3:32 AM Marco Sulla 
wrote:

> I would contribute to the project in my spare time. Can someone point
> me to some easy task? I know C and the Python C API a little.
> ___
> 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/5EQWUYNGSTWGJONZCFRMK6XWXL36WCLR/
> 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/RPQQAEIIGFJMFNXWRLFZKM4RVCWXXWXR/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Alternative syntax for Python's lambda

2021-03-26 Thread Brett Cannon
That discussion has not even made it here yet; it seems to still only be on
python-ideas and thus that's probably the best place to leave a comment on
the subject (for now).

On Thu, Mar 25, 2021 at 9:55 PM Dan Stromberg  wrote:

>
> Please see https://lwn.net/Articles/847960/
>
> :)
>
> On Thu, Mar 25, 2021 at 2:34 PM Ethan Furman  wrote:
>
>> On 3/25/21 1:06 PM, Dan Stromberg wrote:
>> >
>> > I posted this to LWN, and thought I'd share it here too:
>>
>> This post is nearly completely devoid of context -- could you post a
>> link, or what you are responding to, or something?
>>
>> --
>> ~Ethan~
>> ___
>> 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/4BVRW67UU6KQCDER4FMRTZ4WUMBDTNGJ/
>> 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/3PBF272BZAWWF7XWP3O2PQ25VT4Y5HOO/
> 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/I2HC4OPRD3SHEGKTPRBXG6L3ZP6S3EHQ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Merge Request Review Reminder

2021-03-19 Thread Brett Cannon
On Fri, Mar 19, 2021 at 9:29 AM Faisal Mahmood 
wrote:

> Hello,
>
> Following my previous e-mail last month, thank you for responding.  I
> almost immediately got two reviewers who posted helpful comments on my PR
> which I believe have all been resolved now.
>
> Today, I got a notification to say my branch is stale again so wanted to
> understand what the next steps are.
>
> Is there anything else I can do to get my PR merged? This is my first time
> submitting a PR to Cpython so not sure of the workflow, or if I have missed
> something so would appreciate your guidance.
>

At this point it's up to a core dev to have the time and inclination to
look at the PR and either give feedback or to merge it (unfortunately I
personally lack the knowledge to help out with this PR).

-Brett


>
> SIDE QUESTION: Also, when I originally submitted this PR, I used a
> different Git config and user called "KillerKode" - however I was asked to
> change this, which is totally understandable so I changed everything to my
> name, however the commit history of that PR now contains some commits from
> my old Git config (as KillerKode) and some with my new Git config (as
> Faisal Mahmood).  I am wondering, when this gets merged, how can I make
> sure that the commits are squashed and any history of my previous git
> config (i.e. KillerKode) do not show?
>
> Kind regards,
>
> Faisal.
>
> On Mon, 15 Feb 2021 at 14:20, Faisal Mahmood 
> wrote:
>
>> Hello,
>>
>> I hope you are all well, I currently have an issue / merge request that
>> has become stale and as per the guidelines I am sending this e-mail to
>> request someone to review it for me please.
>>
>> Issue Number: 42861 (https://bugs.python.org/issue42861)
>> Pull Request: 24180 (https://github.com/python/cpython/pull/24180)
>>
>> This is my first contribution to CPython and I am very keen to get this
>> added as I think it is an almost essential enhancement missing from the
>> ipaddress module.  I would greatly appreciate if someone can take a look
>> and give me feedback, I am more than happy to help explain things, as I
>> appreciate this is not the most straightforward thing to do.
>>
>> Effectively, this method allows you to get the next closest network of
>> any prefix size, it works by effectively adding 1 to the host portion of
>> the network.  There is actually a very nice guide someone made on
>> stackexchange explaining how to do this calculation manually, I simply
>> followed this logic and have tested it as much as possible and it seems to
>> work great.  See here:
>> https://networkengineering.stackexchange.com/questions/7106/how-do-you-calculate-the-prefix-network-subnet-and-host-numbers/53994#53994
>>
>> Please let me know if there is anything else I can do to help get this
>> merged.
>>
>> Kind regards,
>>
>> Faisal.
>>
> ___
> 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/DUL55S2S5C5AJO33LAPSL7MAOI5Y76WV/
> 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/7IOSA6ALD42A6SDQX2525UCBTNYTGT2X/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: aiter/anext review request

2021-03-19 Thread Brett Cannon
I personally would be okay with aiter() (with the modern API ) and next()
in the `operator` module. There's already precedent in having things there
that are rarely used directly but still implement the use of a special
method, e.g. operator.index() (
https://docs.python.org/3/library/operator.html#operator.index).

On Fri, Mar 19, 2021 at 10:29 AM Guido van Rossum  wrote:

> I assume that one of the concerns is that these functions are trivial.
> aiter(x) is just x.__aiter__(), and anext(it) is just it.__next__(). I’m
> not convinced that we need aiter(x, sentinel) at all — for iter() it’s
> mostly a legacy compatibility API.
>
> If you use these a lot it’s simple enough to add one-liners to the top of
> your module or to your project’s utilities.
>
> I also feel (but I may be alone in this) that maybe we went overboard with
> the design of async for (and async with).
>
> That said the work itself is impeccable. While you’re waiting for a
> resolution you may want to try working on other contributions!
>
> —Guido
>
> On Fri, Mar 19, 2021 at 09:59 Luciano Ramalho  wrote:
>
>> OK, but it seems clear to me that if there are any lingering doubts it
>> would be better to add the functions to a module than to the built-ins, and
>> later promote them to built-ins if people actually find them widely useful.
>>
>> On the other hand, adding something to built-ins that turns out to be
>> rarely useful adds unnecessary noise and is much harder to fix later
>> without causing further problems.
>>
>> Best,
>>
>> Luciano
>>
>>
>> On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson 
>> wrote:
>>
>>> Thanks for taking a look at this, Luciano.
>>>
>>> Yury immediately replied <https://bugs.python.org/issue31861#msg319520>
>>> to the comment from Jelle that you quoted with the following:
>>>
>>> > Do these really need to be builtins?
>>>>
>>>> We're only beginning to see async iterators being used in the wild, so
>>>> we can't have a definitive answer at this point.
>>>>
>>>> > They seem too specialized to be widely useful; I've personally never
>>>> needed them in any async code I've written. It would make more sense to me
>>>> to put them in a module like operators.
>>>>
>>>> I think putting them to the operators module makes sense, at least for
>>>> 3.8.  Do you want to work on a pull request?
>>>
>>>
>>>
>>> That was on 2018-06-14. On 2018-08-24, I submitted
>>> https://github.com/python/cpython/pull/8895, "Add operator.aiter and
>>> operator.anext". On 2018-09-07, Yury left the following comment
>>> <https://github.com/python/cpython/pull/8895#pullrequestreview-153441599>
>>> on that PR:
>>>
>>> Please don't merge this yet. I'm not convinced that aiter and anext
>>>> shouldn't be builtins.
>>>
>>>
>>>
>>> So there has been some back-and-forth on this, and some more years have
>>> passed, but all the latest signals we've gotten up to now have indicated a
>>> preference for adding these to builtins.
>>>
>>> In any case, as of my latest PR
>>> <https://github.com/python/cpython/pull/23847>, the Python core
>>> developers now have both options to choose from.
>>>
>>> As community contributors, is there anything further we can do to help
>>> drive timely resolution on this one way or another?
>>>
>>> Thanks,
>>> Josh
>>>
>>>
>>> On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho 
>>> wrote:
>>>
>>>> Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra
>>>> in the issue tracker:
>>>>
>>>> Do these really need to be builtins?
>>>>
>>>> They seem too specialized to be widely useful; I've personally never 
>>>> needed them in any async code I've written. It would make more sense to me 
>>>> to put them in a module like operators.
>>>>
>>>>
>>>> (sorry for the weird formatting, posting from an iPad)
>>>>
>>>> On Wed, Mar 17, 2021 at 21:01 Joshua Bronson 
>>>> wrote:
>>>>
>>>>> Dear python-dev,
>>>>>
>>>>> New here (but not to Python).  Brett Cannon recommended I start a
>>>>> thread here (thanks, Brett!).
>>>>>
>>>>> In December, two colleagues and I submitted
>>>>> https://github.com/python/c

[Python-Dev] Re: pth file encoding

2021-03-16 Thread Brett Cannon
On Mon, Mar 15, 2021 at 7:53 PM Inada Naoki  wrote:

> Hi, all.
>
> I found .pth file is decoded by the default (i.e. locale-specific)
> encoding.
>
> https://github.com/python/cpython/blob/0269ce87c9347542c54a653dd78b9f60bb9fa822/Lib/site.py#L173
>
> pth files contain:
>
> * import statements
> * paths
>
> For import statement, UTF-8 is the default Python code encoding.
> For paths, fsencoding is the right encoding. It is UTF-8 on Windows
> (excpet PYTHONLEGACYWINDOWSFSENCODING is set), and locale-specific
> encoding in Linux.
>
> What encoding should we use?
>
> * UTF-8
> * sys.getfilesystemencoding()
> * Keep status-quo.
>

What are packaging tools like pip and setuptools writing .pth files out as?
___
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/GMVXCNGP2J5JFE4ISANASZ5D67UWWVM7/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Reviving PEP 473

2021-03-15 Thread Brett Cannon
Since tweaking the built-in exceptions is so far-reaching, probably at
least discussing each proposed change (one at a time, not 5 at once) would
be the minimum. Otherwise you could do a PEP, but once again you're looking
at a PEP per exception. I think it's really going to come down to how big
of an addition it is per exception, how easy it would be to have a memory
leak, what the API to setting the attribute(s) would look like, etc.

On Sat, Mar 13, 2021 at 1:22 PM Victor Stinner  wrote:

> Context: PEP 473 "Adding structured data to built-in exceptions"
> proposed in 2014.
> https://www.python.org/dev/peps/pep-0473/
>
> Abstract: "Exceptions like AttributeError, IndexError, KeyError,
> LookupError, NameError, TypeError, and ValueError do not provide all
> information required by programmers to debug and better understand
> what caused them. Furthermore, in some cases the messages even have
> slightly different formats, which makes it really difficult for tools
> to automatically provide additional information to diagnose the
> problem. To tackle the former and to lay ground for the latter, it is
> proposed to expand these exceptions so to hold both the offending and
> affected entities."
>
> For example the PEP proposes to add "target" and "attribute"
> attributes to AttributeError.
>
> PS: Please give at least the PEP title for me when you mention a PEP
> only by its number, I'm unable to remember what are the 500+ PEP :-(
>
> Victor
>
> On Sat, Mar 13, 2021 at 7:49 PM Sebastian Kreft  wrote:
> >
> > Hi dev-team, I'm reopening the discussion of PEP 473, which was closed
> due to:
> >
> > The steering council felt the PEP was too broad and not focused enough.
> Discussions about adding more attributes to built-in exceptions can
> continue on the issue tracker on a per-exception basis (and obviously here
> for any broader points, e.g. performance implications as I know that has
> come up before when the idea of storing relevant objects on exceptions).
> >
> > Before the PEP was rejected by the SC, I had submitted
> https://github.com/python/cpython/pull/6271 and the last response said:
> >
> > You may propose a newly revised PEP which overcomes the last SC feedback.
> > But without the accepted PEP, this PR can not be merged.
> >
> > Please clarify how can I proceed with adding some of the specified
> fields to the mentioned exceptions. Should I create a new PEP as suggested
> in the PR or should we create individual BPO issues for each exception
> modification.
> >
> > --
> > Sebastian Kreft
> > ___
> > 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/4XVFFNBHXN5KBTHJGMX6ZTN6KOW4Z7UG/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/PLPUG6MFVHHHVONJK6ZHPORCQYJS5QTH/
> 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/C7UZ7MH3TRT4M3NNYDEDNWX5WIXVOVBX/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [Steering-council] Re: PEP 651, Robust Stack Overflow Handling, Rejection notice

2021-03-05 Thread Brett Cannon
Speaking for myself ...

On Fri, Mar 5, 2021 at 7:04 AM Mark Shannon  wrote:

> Hi,
>
> Thanks for taking the time to consider the PEP.
>
> Although the PEP was rejected, I still believe that the safety
> guarantees in PEP 651 are worth adding to Python in the future.
>
> To do that (maybe for 3.11), I need to understand your concerns better.
>
> Would you clarify a few points for me?
>
> On 03/03/2021 7:19 pm, Python Steering Council wrote:
> > Hi Mark,
> >
> > Thank you for submitting PEP 651. The Steering Council has spent the
> past two weeks reviewing PEP 651. After careful consideration, we have
> decided to reject the PEP. The following were the key points that led us to
> this decision:
> >
> > * The benefits are not compelling enough. Deep recursion is not a common
> tool in
> >Python, and even with PEP 651 it would not be efficient enough to
> make it a common
> >tool.
> >
> > * The benefit of PEP 651 is negated as soon as a non-Python function is
> involved in the
> >recursion, making the likelihood of it being useful even smaller. It
> also creates
> >easy pitfalls for users who do end up relying on recursion.
>
> Could you give an example pitfall?
>
> >
> > * We believe the PEP understates the disruption created by the technical
> solution of
> >multiple Python stack frames per C call. Although this may be
> solvable, it will
> >certainly cause substantial disruption to existing debuggers,
> tracers, and state
> >inspection tools as they need to adapt to this change (which may not
> be trivial).
>
> This is presumably the key objection.
> Is there a particular tool that you feel would be problematic?
> I have only looked at gdb and py-spy.
>

There's also any debugger that has an extension module component, e.g.
debugpy.


>
> >
> > * As the way to approach this will be platform-specific (as some parts
> of the proposal
> >are not portable), this can cause generic Python code to behave
> differently on
> >different platforms, making this kind of code less portable and less
> predictable.
>
>
> There are two issues here. Portability and changes to behaviour.
>
> Regarding portability, I have to admit that PEP is rather vague.
> That's my fault; I should have done more implementation first :(
> FWIW, I have an implementation that should be portable.
>
> https://github.com/python/cpython/compare/master...markshannon:pep-overflow-implementation
>
> Regarding changes to behaviour, I don't see how "generic" Python code
> would behave differently on different platforms, except for cases where
> it already does.
>
> In some cases, the PEP would have improved the situation.
>
> For example:
> sys.setrecursionlimit(5000)
> def f():
>  f()
>
> Currently, it raises a RecursionError on linux, but crashes the
> interpreter on Windows.
> With PEP 651 it would have raised a RecursionError on both platforms.
>
> Am I missing something here?
>

So your example shows a user already comfortable in raising their recursion
limit to work around needing more stack space to reach completion. What is
stopping the user from continuing to raise the limit until they still reach
their memory limit even with PEP 651? If you're worried about runaway
recursion you will very likely hit that with the default stack depth
already, so I personally don't see how a decoupled stack counter from the C
stack specifically makes it any easier/better to detect runaway recursion.
And if I need more recursion than the default, you're going to bump the
recursion depth anyway, which weakens the protection in either the C or
decoupled counter scenarios. Sure, it's currently platform-specific, but
plenty of people want to push that limit based on their machine anyway and
don't need consistency on platforms they will never run on, i.e. I don't
see a huge benefit to being able to say that an algorithm consistently
won't go past 5000 calls on all platforms compared to what the C stack
protection already gives us (not to say there's zero benefit, but it isn't
massive or widespread either IMO). I personally just don't see many people
saying, "I really want to limit my program to an exact call stack depth of
5000 on all platforms which is beyond the default, but anything under is
fine and anything over -- regardless of what the system can actually handle
-- is unacceptable".

Tack on the amount of changes required to give a cross-platform stack count
and limit check compared to the benefit being proposed, and to me that
pushes what the PEP is proposing into net-negative payoff.
___
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/QLVLXHHGTR3Z4ILS5D5FZWMEHXST7HZO/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

2021-02-25 Thread Brett Cannon
On Thu, Feb 25, 2021 at 8:46 AM Thor Whalen  wrote:

> Finally! One of my top python wishes!
>
> Where can I vote?
>

There is no explicit voting, but thanks for sharing your opinion!


>
> How can I get my hands on a back port?
>

Probably can't since it will be new to 3.10 if the PEP gets accepted.


>
> How can I help getting this sooner?
>

As of right now there's nothing to do as the steering council has not even
begun reviewing the PEP yet. If the PEP gets accepted then you can
volunteer to help with the implementation and/or the review of the code.

-Brett


> ___
> 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/2QPAZ26E77MV2AZLDF3Z6DNHWZHQUPH5/
> 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/HWNMML442Q72LQVPUCAYAI3BTKLN4Y2U/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

2021-02-22 Thread Brett Cannon
On Sun, Feb 21, 2021 at 12:28 PM Gregory P. Smith  wrote:

>
> On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes 
> wrote:
>
>> On 21/02/2021 13.47, glaub...@debian.org wrote:
>> > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3
>> platforms. There is no separate configure guard. All platforms that Rust
>> can build for, are always enabled by default. No one in Rust keeps anyone
>> from cross-compiling code for sparc64 or powerpcspe, for example.
>> >
>> > So if you want to copy Rust's mechanism, you should just leave it as is
>> and not claim that users are being confused because "m68k" shows up in
>> configure.ac.
>>
>> A --enable-unstable-platforms configure flag is my peace offer to meet
>> you half way. You get a simple way to enable builds on untested
>> platforms and we can clearly communicate that some OS and hardware
>> platforms are not supported.
>>
>
> I personally wouldn't want to maintain such a check in autoconf, but it'll
> be an isolated thing on its own, that if you or someone else creates, will
> do its job and not bother the rest of us.
>

If we add a compile flag to explicitly make people have to realize they are
running on an unsupported platform then I think it should be a negation
against an allowlist versus a blocklist to be more explicit about what we
would take PRs for.


>
> I think just publishing our list of (1) supported, (2) best-effort
> non-release-blocker quasi-supported, and (3) explicitly unsupported in a
> policy doc is sufficient.  But it's not like any of us are going to stop
> someone from codifying that in configure.ac to require a flag.
>

 I like the idea of making PEP 11 list what platforms *are* supported in
some way, and being off that list means you're not. I also like the idea of
having a tier 1 that will block a release and a tier 2 where we will accept
PRs but it will in no way block releases.

I also think who ends up on either of those tiers should be an SC problem.
Based on how heated this thread has gotten there's obviously some emotional
connection for some folks when it comes to whether a platform is supported
or not and how that is handled. In that sense, letting the SC take on the
burden of saying "no" makes sense. That doesn't mean PEP 11 wouldn't still
list out the *minimum* requirements to add a platform, but I don't think it
should be an automatic thing simply because a machine was donated and a
hand was raised as e.g. #ifdefs have a cognitive cost.

So, my suggestion is to update PEP 11 to:

   - List platforms that can block releases as a "tier 1" supported platform
   - List platforms that are best effort as "tier 2" and which will never
   hold up a release
   - All other platforms will need to manage their patchset externally and
   we will not accept PRs that are specifically for them
   - Specify what the *minimum* requirements are to add support for a
   platform to either tier
   - Have the SC manage what platforms can end up in what tier (and we can
   publish guidelines like conditional tier 2 to prove support exists, what is
   required to graduate to tier 1, removal from tiers, etc.)
___
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/TKEG3OF4BIIVO56BQT37PJEVBLJZCUJL/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Anyone interested in leading a sprint at PyCascades tomorrow?

2021-02-20 Thread Brett Cannon
It's short notice, but PyCascades is hosting sprints on Sunday, Feb. 21
from 09:00 - 12:30 PST tomorrow and the organizers wanted to see if anyone
happened to be up for leading or helping out anyone who wants to sprint on
CPython.

https://2021.pycascades.com/program/sprints/
___
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/VWI3JUSECIX4HT6YAMRAXG54V3OBGS4I/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Security releases of CPython

2021-02-19 Thread Brett Cannon
On Fri, Feb 19, 2021 at 3:10 PM Stestagg  wrote:

>
>
> On Fri, 19 Feb 2021 at 22:50, Christian Heimes 
> wrote:
>
>> On 19/02/2021 23.22, Stestagg wrote:
>> > The thing that stood out from this conversation, for me, is: Releases
>> > are too hard, and there’s a risk of not having enough volunteers as a
>> > result.
>> >
>> > How hard is it to fix that?
>>
>> Actually it's easy to fix!
>>
>> The PSF needs needs sufficient money to hire a couple of people, so the
>> PSF can turn release management and security maintenance from unpaid
>> volunteers into paid fulltime jobs.
>>
> That’s certainly one option. I’d be super surprised if that were the only
> one.
>
> What were the budget requirements for this? How far from the target is the
> PSF?  Is there a plan to hit it?
>

There is no specific drive to hire someone to target security and/or
release management at the moment. We just got enough funding for the first
time to hire a dev-in-residence for Python itself to try to help tackle our
1.4K PR backlog in some fashion that they won't be dedicated to security or
release management.


>
> Are there no technical solutions that might help reduce the cost?
>

If you would like to help out, you can speak with the release managers to
see if they could use help in some way; same goes for the security team.

-Brett


> ___
> 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/55GFSMWJOG7P6NWU4KDHMKJN2OGX5YSG/
> 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/EYP6H3HNLZN4DQ3Y3ROJ63LSMUX3LT7Y/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Clarification on the removal of generator-based coroutines in 3.10

2021-02-19 Thread Brett Cannon
On Thu, Feb 18, 2021 at 9:04 PM Guido van Rossum  wrote:

> On Thu, Feb 18, 2021 at 8:23 PM Luciano Ramalho 
> wrote:
>
>> Thanks for your reply, Guido.
>>
>> On Fri, Feb 19, 2021 at 12:07 AM Guido van Rossum 
>> wrote:
>> > Reading the doc section you link to, it's pretty clear that
>> `@asyncio.coroutine` will be removed.
>>
>> The *Note* right at the top of [1] says "Support for generator-based
>> coroutines is deprecated and is scheduled for removal in Python 3.10."
>>
>> [1]
>> https://docs.python.org/3/library/asyncio-task.html#generator-based-coroutines
>>
>> But PEP 492 [2] says:
>>
>> "Since, internally, coroutines are a special kind of generators, every
>> await is suspended by a yield somewhere down the chain of await calls"
>>
>> [2] https://www.python.org/dev/peps/pep-0492/#await-expression
>>
>> If that part of PEP 492 is no longer accurate, then I have a couple of
>> questions:
>>
>> 1) What Python construct is to be used at the end of a chain of await
>> calls, if not of a generator-based coroutine decorated with
>> `@types.coroutine` and using a `yield` expression in its body?
>>
>> 2) Given that the sole purpose of `@types.coroutine` is to decorate
>> generator-based coroutines to become awaitable, will that decorator
>> also be removed, along with "support for generator-based coroutines"?
>>
>> Best,
>>
>> Luciano
>>
>
> It looks like types.coroutine will remain (it does not contain code to
> warn about deprecation like asyncio.coroutine does), but I don't think it
> is required to end a chain of coroutines -- it may have been an oversight
> that we did not start deprecating it. (But in any case it won't be
> supported by asyncio.)
>
> At the end of the chain you can call the __await__() method which gives an
> iterator, and then you call next() or send() on that iterator. Each
> next()/send() call then represents an await step, and send() in general is
> used to provide an awaited result. Eventually this will raise StopIteration
> with a value indicating the ultimate result (the return value of the
> top-level async def).
>
> The code used to "drive" a chain of await calls is called a trampoline.
> But writing a trampoline is not easy, and the only example I know of is
> asyncio's Task class, in particular its __step() method, which of course is
> beyond complicated because it has to handle so many special cases.
>

I've found https://github.com/dabeaz/curio to be the simplest,
full-featured Python event loop to read.

-Brett


>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> 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/CEQQLON7A5D64V7VAPH7OCTULG2HZPHQ/
> 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/CSRXFPGEZO6LFDHM2Q5USMVWXIIDK42R/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Security releases of CPython

2021-02-19 Thread Brett Cannon
On Fri, Feb 19, 2021 at 2:16 AM Michał Górny  wrote:

> On Thu, 2021-02-11 at 23:24 -0500, Terry Reedy wrote:
> > On 2/11/2021 3:23 PM, Michał Górny wrote:
> > > Hello,
> > >
> > > I'm the primary maintainer of CPython packages in Gentoo. I would like
> > > to discuss possible improvement to the release process in order to
> > > accelerate releasing security fixes to users.
> > >
> > > I feel that vulnerability fixes do not make it to end users fast
> enough.
> >
> > When we introduce a bad regression in a release, including a
> > severe-enough security vulnerability, and discover it soon enough, we
> > have sometimes made immediately releases.
> >
> > Beyond that, your proposal to add several releases per Python version,
> > perhaps double what we do now, runs up against the limits of volunteer
> > time and effort.  As it is now, becoming a release manager is a 7 year
> > commitment, with at least one release about every other month for the
> > first 4.  There are also the 2 people who produce the Windows and macOS
> > installers.  I believe each has done it for at least 7 or 8 years
> > already.  Releases are not just a push of a button.  Make the release
> > job too onerous, and there might not be any more volunteers.
>
> While I understand your concerns and sympathize with them, I don't think
> it's fair to play the volunteer card here.  After all, I am a volunteer
> too, and many distribution packagers are as well.  We also have limited
> time and many other duties, and it just feels unfair for you to be
> dumping the security work on us.
>

I also don't think it's fair to say anyone is "dumping security work" on
you. Volunteerism is about accepting that I can't ask anything of you while
you can't ask anything of me. We all do our best here, but it's making
choices with very finite resources and our release and security approach is
the one we have made based on what we have to work with. If people would
like to see more frequent releases then it will most likely require people
volunteering to help with the security workload as well as with the release
process, both of which are rather thankless jobs unfortunately. But simply
because we have differing views on how to handle security doesn't mean
anyone is actively "dumping" anything on anyone.


>
> The thing is, CPython upstream has the opportunity to do the central
> work that benefits everyone.  You get the first indication
> of the vulnerability, you have the first fix and backport to all
> branches.  It is only the natural next step to make a release with it.
> While I realize it means more work, not doing that means more work for
> a number of other people who are impacted by your prior work.
>
> That said, if the regular release process is too much work, then maybe
> a process similar to security-supported branches would work?  After all,
> I think it reasonable to assume that a large number of CPython users are
> using it via distribution packages and having Python 3.8.x.y source-only
> release will be already a big help to people making these packages.
>

But a very large number of people get their releases from python.org, so if
we do source-only releases without pushing out an install that then causes
a schism between what users get on one platform versus another that goes
beyond simply the delivery mechanism (and this isn't hypothetical;
downstream packages by Linux distros have caused issues for users due to
differing from what python.org pushes out, so we do need to consider this
impact).

-Brett


>
> > > For example, according to the current release schedules for 3.9 and
> 3.8,
> > > the bugfix releases are planned two months apart. While the release is
> > > expected to happen in the next few days, both versions are known to be
> > > vulnerable for almost a month!
> > >
> > > Ironically, things look even worse for security-supported versions.
> > > Please correct me if I'm wrong but both 3.7 and 3.6 seem to be behind
> > > schedule (planned for Jan 15th), and they are known to be vulnerable
> > > since mid-October.
> > >
> > > In my opinion, this causes three issues:
> > >
> > > 1. Users using official releases are exposed to security
> vulnerabilities
> > > for prolonged periods of time.
> > >
> > > 2. When releases happen, security fixes are often combined with many
> > > other changes. This causes problems for distribution maintainers who,
> on
> > > one hand, would like to deploy the security fixes to production
> versions
> > > ASAP, and on the other, would prefer that the new version remained in
> > > testing for some time due to the other changes.
> > >
> > > 3. Effectively, it means that distribution developers need to track
> > > and backport security fixes themselves. In the end, this means a lot of
> > > duplicate work.
> >
> > Perhaps people doing duplicate work could get together to eliminate some
> of
> > the duplication.  It should be possible to filter security commits from
> the
> > python-checkins list by looking at 

[Python-Dev] Re: Python 0.9.1

2021-02-17 Thread Brett Cannon
If we can get a clean copy of the original sources I think we should put
them up under the Python org on GitHub for posterity.

On Wed, Feb 17, 2021 at 6:10 AM Skip Montanaro 
wrote:

> This is getting a bit more off-topic for python-dev than I'd like. I
> will make a couple comments though, then hopefully be done with this
> thread.
>
> > The original ones are here:
> > http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/volume91/Feb/
> > Look at http://ftp.fi.netbsd.org/pub/misc/archive/alt.sources/index.gz
> > for the associating subjects with file names. As far as I can tell,
> > they extract flawlessly using unshar.
>
> Thanks. Will check them out.
>
> > When I see diffs like this (your git vs. the unshar result) I tend to
> > trust unshar more:
>
> ...
>
> Well, sure. I was trying to reverse engineer the original shar files
> from Google's HTML. I was frankly fairly surprised that I got as close
> to perfection as I did. I realized that Google had mangled Guido's old
> CWI email, but didn't worry about it. I also saw the TeX macro
> mangling, but as I wasn't planning to rebuild the documentation, I
> didn't worry too much about that. I expected to need a bunch of manual
> patchwork to get back to something that would even compile.
>
> It's nice to know that in this case, "the Internet never forgets."
>
> 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/J6IOWRUUZ64EHFLGSNBMSNO6RIJEZO22/
> 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/GHZYRQJOMG63MPZ6XJOBQXPCMV46GXOO/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Signature discrepancies between documentation and implementation

2021-02-09 Thread Brett Cannon
On Tue., Feb. 9, 2021, 12:20 Serhiy Storchaka,  wrote:

> 09.02.21 12:22, Erlend Aasland пише:
> > What's the recommended approach with issues like
> https://bugs.python.org/issue43094? Change the docs or the
> implementation? I did a quick search on bpo, but could not find similar
> past issues.
>
> If the documentation and the C implemented function contradict about
> parameter name, we are free to treat the parameter as positional-only.
> User cannot pass the argument as keyword because the documented name
> does not work, and the real name is not exposed to the user.
>

I agree with Serhiy's logic.

-Brett


> In this case, there are two similar functions, create_function() and
> create_aggregate(). Both are documented as having parameter
> "num_params", but real names are different: "narg" and "n_arg". It would
> be confusing to have different spelling of the same parameter in similar
> functions. I am sure that it would be difficult to remember how is it
> spelled in every case. Also, in Python terminology, the semantic of this
> name is the number of parameters, not the number of argument.
>
> So I think that in this particular case the chance of breaking some code
> is insignificant, but possible long-term harm of exposing bad parameter
> names may be significant.
> ___
> 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/JE2E5RJZQPMXHTWIU3NA74YDMEZHGYUK/
> 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/L5KVZMBF6VDLA42KRODHCGNKIGGEMIVL/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Why aren't we allowing the use of C11?

2021-01-28 Thread Brett Cannon
On Thu, Jan 28, 2021 at 8:31 AM Mark Shannon  wrote:

> Hi everyone,
>
> PEP 7 says that C code should conform to C89 with a subset of C99 allowed.
> It's 2021 and all the major compilers support C11 (ignoring the optional
> parts).
>
> C11 has support for thread locals, static asserts, and anonymous structs
> and unions. All useful features.
>
> Is there a good reason not to start using C11 now?
>

Depends on compiler support. I would say that if clang, gcc, and MSVC all
support it then we should consider switching, but if any of them are
lagging we would need to find the common base line (hence why the subset of
C99 when we last talked about this).
___
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/6QFPY3YHZELZDUULAFLA5I3FR4K3NIBE/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

2021-01-26 Thread Brett Cannon
On Tue, Jan 26, 2021 at 1:26 AM Antoine Pitrou  wrote:

> On Tue, 26 Jan 2021 10:36:10 +1100
> Steven D'Aprano  wrote:
> > On Mon, Jan 25, 2021 at 06:17:09PM +0100, Victor Stinner wrote:
> > > Hi Bernat,
> > >
> > > "stdlib_module_names" was my first idea but it looks too long, so I
> > > chose "module_names". But someone on Twitter and now you asked me why
> > > not "stdlib_module_names", so I wrote a PR to rename module_names to
> > > sys.stdlib_module_names:
> > > https://github.com/python/cpython/pull/24332
> > >
> > > At least "stdlib_module_names" better summarizes its definition: "A
> > > frozenset of strings containing the names of standard library
> > > modules".
> >
> > Your first instinct that it is too long is correct.
>
> Disagreed.  This is niche enough that it warrants a long but explicit
> name, rather than some ambiguous shortcut.
>

I agree w/ Antoine that a more descriptive name for such a niche (but
useful!) attribute makes sense.

-Brett


>
> > Just call it
> > "stdlib" or "stdlib_names".
>
> If you call it "stdlib", then you should make it a namedtuple that will
> expose various information, such as "sys.stdlib.module_names".
>


>
> Regards
>
> Antoine.
>
> ___
> 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/CJYWXVBIMDHRJCT4HZMOLJ7XMSVNZF6I/
> 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/PI6IOOBUJ4DLW67VIJQILBXYXSI27X37/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: pathlib.Path: inconsistent symlink_to() and link_to()

2021-01-22 Thread Brett Cannon
On Thu, Jan 21, 2021 at 4:43 PM Barney Gale  wrote:

> Hi Brett,
>
> Per your PR review feedback [0] I left a comment on the bug [1] asking
> when the link_to() method should be scheduled for removal. It didn't elicit
> a great deal of feedback, so I'm raising this again here!
>

Per PEP 387 (https://www.python.org/dev/peps/pep-0387/), the deprecation
needs to last for at least 2 versions (so if this landed in 3.10 then
removal couldn't happen any sooner than 3.12).


>
> The proposed deprecation warning in the docs currently reads:
>
> > This method is deprecated in favor of :meth:`Path.hardlink_to`, as its
> argument order does not match that of :meth:`Path.symlink_to`.
>

I would replace "its argument order" with "the argument order of
:meth:`link_to` to disambiguate what "its" is referring to (my brain kept
associating it with the last noun, which was Path.hardlink_to).


>
> My view is that the removal does not need to happen soon. Any existing
> code will be written by people who have already figured out the argument
> reversal, so the current situation doesn't seem dangerous. That said, a
> speedy deprecation and replacement will remove a guaranteed headache for
> people creating hardlinks in pathlib.
>

The removal can't be any _sooner_ than 3.12, but it can be postponed if
desired/necessary.


>
> Apologies if replying to an old thread is bad form - I'm not well versed
> in mailing list etiquette.
>

Not a problem! Sometimes it's just called for, and you kept the old emails
quoted in your reply which helps.

-Brett


>
> Best,
>
> Barney
>
> [0] https://github.com/python/cpython/pull/18909#discussion_r392416154
> [1] https://bugs.python.org/issue39950#msg365275
>
> On Wed, 11 Mar 2020 at 17:31, Brett Cannon  wrote:
>
>> Antoine Pitrou wrote:
>> > On Wed, 11 Mar 2020 11:17:22 +
>> > Barney Gale barney.g...@gmail.com wrote:
>> > > Hi,
>> > > Pathlib's symlink_to() and link_to() methods have different argument
>> > > orders, so:
>> > > a.symlink_to(b)  # Creates a symlink from A to B
>> > > a.link_to(b)  # Creates a hard link from B to A
>> > >
>> > > I don't think link_to() was intended to be implemented this way, as
>> the
>> > > docs say "Create a hard link pointing to a path named target.". It's
>> also
>> > > inconsistent with everything else in pathlib, most obviously
>> symlink_to().
>> > > Bug report here: https://bugs.python.org/issue39291
>> > > This /really/ irks me. Apparently it's too late to fix link_to(), so
>> I'd
>> > > like to suggest we add a new hardlink_to() method that matches the
>> > > symlink_to() argument order. link_to() then becomes
>> deprecated/undocumented.
>> > > I think that's a good idea.
>>
>> +1 from me as well; new method and deprecate the old one.
>>
>> > Regards
>> > Antoine.
>> ___
>> 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/EID35RFJJQBHL4WKSO5DM36O7DDVDEKP/
>> 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/6IOGUMHE7AMJGBJ3KKLMQJU4EJDBYPEL/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] The SC is accepting PEP 632: deprecating distutils

2021-01-21 Thread Brett Cannon
On behalf of the SC, I'm happy to announce that we have chosen to accept
PEP 632. Congrats, Steve, and thanks for the work on the PEP!

I'll let Steve outline what the next steps are for implementing the PEP.
___
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/TXU6TVOMBLQU3SV57DMMOA5Y2E67AW7P/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

2021-01-13 Thread Brett Cannon
On Wed, Jan 13, 2021 at 7:25 AM Serhiy Storchaka 
wrote:

> 12.01.21 22:38, Julien Palard via Python-Dev пише:
> > During the development of cpython 3.10, Sphinx was bumped to 3.2.1.
> >
> > Problem is Sphinx 3 have some incompatibilities with Sphinx 2, some that
> > we could work around, some are bit harder, so we may need to bump
> > `needs_sphinx = '3.2'` (currently it is 1.8).
>
> Sphinx version in the current Ubuntu LTS (20.04) is 1.8.5. Would not it
> cause problems with builting documentation on Ubuntu?
>

Why can't contributors install from PyPI? The venv created by the
Docs/Makefile does a pip install, so I don't see why what version of Sphinx
is packaged via APT is a critical blocker in upgrading Sphinx.
___
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/Y7ZM24JX4OIQBBWTKVWUMK74LQIWGAG6/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

2021-01-12 Thread Brett Cannon
On Tue, Jan 12, 2021 at 6:31 PM Larry Hastings  wrote:

>
> On 1/12/21 5:28 PM, Brett Cannon wrote:
>
> The other thing to keep in mind is we are talking about every module,
> class, and function getting 64 bytes ... which I bet isn't that much.
>
> Actually it's only every module and class.  Functions don't have this
> problem because they've always stored __annotations__ internally--meaning,
> peeking in their __dict__ doesn't work, and they don't support inheritance
> anyway.  So the number is even smaller than that.
>
> If we can just make __annotations__ default to an empty dict on classes
> and modules, and not worry about the memory consumption, that goes a long
> way to cleaning up the semantics.
>

Great!


>
> And I know you were somewhat joking when you mentioned using
> sys.version_info, but since this would be behind a __future__ import
>
> Would it?
>

I thought you had proposed that initially, but it appears I mixed this with
your PEP email.  Sorry about that!


> My original proposal would make breaking changes to how you examine
> __annotations__.  Let's say we put those behind a from __future__ import.
> Now we're gonna write library code that examines annotations.  A user
> passes in a class and asks us to examine its annotations.  The old
> semantics might be active on it, or the new ones.  How do we know which set
> of semantics we need to use?
>
> It occurs to me that you could take kls.__module__, pull out the module
> from sys.modules, then look inside to see if it contains the correct
> "future" object imported from the __future__ module.  Is that an approach
> we would suggest to our users?
>
> Also, very little code ever examines annotations; most code with
> annotations merely defines them.  So I suspect most annotations users
> wouldn't care either way--which also means a "from __future__ import" that
> changes the semantics of examining or modifying annotations isn't going to
> see a lot of uptake, because it doesn't really affect them.  The change in
> semantics only affects people whose code examines annotations, which I
> suspect is very few.
>
> So I wasn't really joking when I proposed making these changes without a
> from __future__ import, and suggested users use a version check.  The
> library code would know based on the Python version number which semantics
> were active, no peeking in modules to find future object.  They could
> literally write what I suggested:
>
> if you know you're running python 3.10 or higher:
> examine using the new semantics
> else:
> examine using the old semantics
>
> I realize that's a pretty aggressive approach, which is why I prefaced it
> with "if I could wave my magic wand".  But if we're going to make breaking
> changes, then whatever we do, it's going to break some people's code until
> it gets updated to cope with the new semantics.  In that light this
> approach seemed reasonable.
>
> But really this is why I started this thread in the first place.  My idea
> of what's reasonable is probably all out of whack.  So I wanted to start
> the conversation, to get feedback on how much breakage is allowable and how
> best to mitigate it.  If it wasn't a controversial change, then we wouldn't
> need to talk about it!
>
>
> And finally: if we really do set a default of an empty dict on classes and
> modules, then my other in-theory breaking changes:
>
>- you can't delete __annotations__
>- you can only set __annotations__ to a dict or None (this is already
>true of functions, but not of classes or modules)
>
> will, I expect, in practice breaking exactly zero code.  Who deletes
> __annotations__?  Who ever sets __annotations__ to something besides a
> dict?  So if the practical breakage is zero, why bother gating it with
> "from __future__ import" at all?
>
>
> I think it really means people need to rely on typing.get_type_hints()
> more than they may be doing right now.
>
> What I find frustrating about that answer--and part of what motivated me
> to work on this in the first place--is that typing.get_type_hints()
> requires your annotations to be type hints.  All type hints are
> annotations, but not all annotations are type hints, and it's entirely
> plausible for users to have reasonable uses for non-type-hint annotations
> that typing.get_type_hints() wouldn't like.
>

You and I have talked about this extensively, so I'm aware. 


> The two things typing.get_type_hints() does, that I know of, that can
> impede such non-type-hint annotations are:
>
>- It turns a None annotation into type(None).  Which means now you
>can't tell the difference between "None" and "type(None)&qu

[Python-Dev] Re: 3.10 change (?) for __bool__

2021-01-12 Thread Brett Cannon
On Tue, Jan 12, 2021 at 9:51 AM Chris Angelico  wrote:

> On Wed, Jan 13, 2021 at 4:24 AM Richard Damon 
> wrote:
> >
> > On 1/12/21 10:53 AM, Mark Shannon wrote:
> > > Hi everyone,
> > >
> > > Should the optimizer eliminate tests that it can prove have no effect
> > > on the control flow of the program, even if that may eliminate some
> > > side effects in __bool__()?
> > >
> > > For several years we have converted
> > >
> > > if a and b:
> > > ...
> > >
> > > to
> > >
> > > if a:
> > > if b:
> > > ...
> > >
> > > which are equivalent, unless bool(a) has side effects the second time
> > > it is called.
> > >
> > > In master we convert `if x: pass` to `pass` which is equivalent,
> > > unless bool(x) has side effects the first time it is called. This is a
> > > recent change.
> > >
> > > This is one of those "easy to fix, if we can decide on the semantics"
> > > bugs.
> > >
> > >
> > > Submit your thoughts to https://bugs.python.org/issue42899, please.
> > >
> > > Cheers,
> > > Mark.
> >
> > One key point about 'and' and 'or' is that those operators are defined
> > to be 'short circuiting', i.e. that  with a and b, that if a is false,
> > then b is not evaluated at all. This can be important if a is a
> > condition that test if the expression b is 'safe' to evaluate. In fact,
> > isn't it true that 'a and b' is defined to be the equivalent to:  'a if
> > not a else b' so b doesn't need to be evaluated unless a is truthy.
>

https://snarky.ca/unravelling-boolean-operations/ if you want the gory
details.


>
> Yes, the shortcircuiting behaviour isn't in question. But consider:
>
> class A:
> def __bool__(self):
> print("A().__bool__")
> return False
>
> def f():
> print("if A() and A()")
> if A() and A(): x = 1
> print("cond = A() and A()")
> cond = A() and A()
> if cond: x = 1
>
> f()
>
> And once you've run the code, disassemble the function for extra insight.
>
> There's a very definite difference here, and it's the same difference as:
>
> for x in thing:
>
> and
>
> for x in iter(thing):
>
> I'd be fine with documenting that __bool__ is (guaranteed to be)
> called only if the interpreter needs to know the result, leaving open
> the option for things like this to be optimized out. That'd leave open
> the option for "foo() if x else foo()" to be optimized down to just
> "foo()", although I don't think that particular one is needed.
>

I think that's the key question here: it is a language change, but is it
one we want (specifically in this case and in general)? It will require a
language reference change at least, and as it has been shown, some people
don't expect Python to take shortcuts in execution knowing full well that
CPython dutifully executes things. So saying we only call __bool__() *if
necessary* is definitely a change. But then this begs the question of
whether we want to do this more widely in the language in the name of
optimization, or not in the name of consistency that a user can easily
reason about.


>
> > I know that I would be very surpised if a statement like
> >
> >
> > if foo():
> >
> > pass
> >
> > ended up optimizing itself and not calling foo(), which is only one step
> > away from the quoted case of
> >
> > if b:
> >
> > pass
> >
> > which is the equivalent to
> >
> > if b.__bool__():
> >
> > pass
>
> Yes, they do look similar. The difference is that calling __bool__ is
> under the interpreter's control, and it's easier to document that it
> be assumed to be side-effect-free.
>
> > Yes, perhaps there is more of an expectation that __bool__() is
> > innocuous, but is that a an assumption that should be baked into the
> > language.
> >
>
> I think so. Consider that sometimes other dunders won't be called, if
> the interpreter believes it's not necessary:
>
> class A(float):
> def __index__(self):
> print("A().__index__")
> return 10
>
> class B(int):
> def __index__(self):
> print("B().__index__")
> return 10
>
> print(range(20)[A():B()])
>
> If it's a subclass of float, slicing will call __index__, but if it's
> a subclass of int, Python knows already that it can use the internal
> integer value.
>

https://snarky.ca/unravelling-not-in-python/  But basically,
https://docs.python.org/3.8/reference/datamodel.html#object.__index__ says
"called *if *conversion to an int is necessary" which isn't the case when
something is already an int.


>
> ChrisA
> ___
> 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/GHKDF6YE3D43JPWS7GVG34FVPJNYE5SO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To 

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

2021-01-12 Thread Brett Cannon
On Mon, Jan 11, 2021 at 5:57 PM Larry Hastings  wrote:

>
> On 1/11/21 5:05 PM, Greg Ewing wrote:
>
> On 12/01/21 6:22 am, Larry Hastings wrote:
>
>  * The language will set __annotations__ to a dict if the object has
>
>annotations, or None if it has no annotations.
>
>
> That sounds inconvenient -- it means that any code referencing
> __annotations__ has to guard against the possibility of it being
> None.
>
> It was a balancing act.  Using an 64-byte empty dict per object with no
> defined annotations seems so wasteful.  And anything short of an empty
> dict, you'd have to guard against.  Current code already has to guard
> against "__annotations__ aren't set" anyway, so I figured the cost of
> migrating to checking a different condition would be small.  And None is so
> cheap, and the guard is so easy:
>
> if o.__annotations__:
>
>
But if things could fall through in the default case such that use in a
`for` loop, it is nice as Guido pointed out.

The other thing to keep in mind is we are talking about every module,
class, and function getting 64 bytes ... which I bet isn't that much. I bet
you save more memory running with -OO than what this will cost users in
memory.

And I know you were somewhat joking when you mentioned using
sys.version_info, but since this would be behind a __future__ import it
means the version check just means you then need to *potentially* worry
about the semantic shift (until the change becomes permanent). It seems the
changes are all still easy enough to have fallthrough and semantic checks
that it won't be much of a problem. I think it really means people need to
rely on typing.get_type_hints() more than they may be doing right now.


>
> If we're changing things, I'm wondering if the best thing would be
> to introduce an annotations() function as the new best practice for
> getting an object's annotations. It would know how to handle all
> the type-specific pecularities, and could take care of things such
> as manufacturing an empty dict if the object doesn't have any
> annotations.
>
> I guess I'm marginally against this, just because it seems like a needless
> change.  We don't need the flexibility of a function with optional
> parameters and such, and with a data descriptor we can already put code
> behind __annotations__ (as I have already done).  Plus, the function should
> probably cache its result--you wouldn't want code that called it ten times
> to generate ten fresh dicts, would you?--and already we're most of the way
> to what I proposed in PEP 649.
>

I also don't think introspection on annotations is common enough to warrant
a built-in function; this stuff is meant for tools, not for the average
developer to be dynamically playing with. As Guido pointed out,
typing.get_type_hints() already covers this.
___
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/WGDIGZSMGFDXBI5ZTVPDMYBPRAKBNIG4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

2021-01-11 Thread Brett Cannon
On Mon, Jan 11, 2021 at 9:23 AM Larry Hastings  wrote:

> [SNIP - background info]
>
>
> If I could wave my magic wand and do whatever I wanted, I'd change the
> semantics for __annotations__ to the following:
>
> * Functions, classes, and modules always have an __annotations__ member
> set.
> * "del o.__annotations__" always throws a TypeError.
> * The language will set __annotations__ to a dict if the object has
>   annotations, or None if it has no annotations.
> * You may set __annotations__, but you can only set it to either None or a
>   dict (passes PyDict_Check).
> * You may only access __annotations__ as an attribute, and because it's
>   always set, best practice is to use "o.__annotations__" (though getattr
>   will always work too).
> * How __annotations__ is stored is implementation-specific behavior;
>   looking in the relevant __dict__ is unsupported.
>
> This would grant sanity and consistency to __annotations__ in a way it's
> never so far enjoyed.  The problem is, it's a breaking change.  But the
> existing semantics are kind of terrible, so at this point my goal is to
> break them. I think the best practice needs to stop requiring examining
> cls.__dict__; in fact I'd prefer people stop doing it altogether.
>

So the biggest potential breakages are code that:

   1. Directly get the attribute from __dict__
   2. The fact that it would no longer be inherited

Am I missing anything else?

For issue #1, it seems that inspect.get_type_hints(), as you point out
below, resolves that. As well, code could be updated appropriately without
much effort to check different places if the attribute was not found in
__dict__.

For issue #2, if the default was `None`, then couldn't that be used as an
implicit feature marker that you can't (incorrectly) rely on inheritance to
percolate up the annotations of the superclass if the subclass happens to
not define any annotations?

This all seems reasonable to me. Since it's a change to the object model it
will probably need a PEP, but I would suspect it would mostly revolve
around guiding people to how to update their code to work across Python
versions.

-Brett

>
> If we change the behavior as part of a new release of Python,
> code that examines annotations on classes can do a version check:
>
> if (sys.version_info.major >=3
> and sys.version_info.minor >= 10):
>
> def get_annotations(o):
> return o.__annotations__ or {}
> else:
> def get_annotations(o):
> # eight or ten lines of complex code goes here
> ...
>
> Or code can just use inspect.get_type_hints(), which is tied to the Python
> version
> anyway and should always do the right thing.
>
>
> */arry*
> ___
> 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/AWKVI3NRCHKPIDPCJYGVLW4HBYTEOQYL/
> 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/IY55VJHCYD2P3ZJUJI4RXX6UZS3I2LB5/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: unittest of sequence equality

2020-12-22 Thread Brett Cannon
On Tue, Dec 22, 2020 at 10:54 AM Alan G. Isaac  wrote:

> The following test fails because because `seq1 == seq2` returns a
> (boolean) NumPy array
> whenever either seq is a NumPy array.
>
>  import unittest
>  import numpy as np
>  unittest.TestCase().assertSequenceEqual([1.,2.,3.],
> np.array([1.,2.,3.]))
>
> I expected `unittest` to rely only on features of a
> `collections.abc.Sequence`,
> which based on https://docs.python.org/3/glossary.html#term-sequence,
> I believe are satisfied by a NumPy array. Specifically, I see no
> requirement
> that a sequence implement __eq__ at all much less in any particular way.
>
> In short: a test named `assertSequenceEqual` should, I would think,
> work for any sequence and therefore (based on the available documentation)
> should not depend on the class-specific implementation of __eq__.
>
> Is that wrong?
>

Yes and no. :) I don't agree that `seq1 == seq2` should not be tried if the
sequences support it, but the function does work on sequences that lack a
definition of `__eq__` as you would expect (e.g. user-defined sequences
where you just didn't want to bother). The fact that numpy chooses to
implement __eq__ in such a way that its result would be surprising if used
in an `if` guard I think is more a design choice/issue of numpy than a
suggestion that you can't trust `==` in testing because it _can_ be
something other than True/False.
___
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/LZUQ54HKGRP5TUUETQXGG2ZJ5RWAARXK/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Python package funding through command-line

2020-12-17 Thread Brett Cannon
This mailing list is for the development of Python. Pip development is
primarily discussed at https://discuss.python.org/c/packaging/14. But I
would also check their issue tracker as I believe they already have an
issue open about this (I think it's called `pip thanks`).

On Thu, Dec 17, 2020 at 8:44 AM  wrote:

> Many open-source developers are committing to several projects, developing
> package (for Python). A fraction of developers might need funds for the
> continuing development of several projects and to pursue contributing.
> Sadly, there is no direct short way for donors to fund python package
> developers. There is no particular function in the python package
> installer(pip) and the site.
>
> A command-line argument(pip3 fund) for listing the funding pages of
> package developer for packages installed by them (global or pyenv), will
> help donors to reach such developers easily. The funding page can be the
> GitHub sponsor page, or PayPal redirect (control of the developer)
>
> Similar implementations include the "npm fund" command. This command
> retrieves information on how to fund the dependencies of a given project,
> released 4-5 months ago which has gained momentum.
> ___
> 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/6Q5VJEYFJCMTYRZZFKCF5WN4SSHPPZ6N/
> 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/KUC2UCFQK5VPTE4I55SJFLABS2GIIQUY/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: NEWS, changelog, and blurb -- a teaching moment

2020-12-10 Thread Brett Cannon
On Wed, Dec 9, 2020 at 7:38 PM Larry Hastings  wrote:

> On 12/9/20 5:21 PM, Ethan Furman wrote:
>
> On 12/9/20 5:01 PM, Larry Hastings wrote:
>
> > "Misc/NEWS" is no longer checked in, it's generated on demand using
> "blurb merge".
>
> So if I understand correctly, blurb makes NEWS, but `whatsnew` is still
> done by hand.
>
>
> Correct.  You'll notice that each "whatsnew" lists its "editor"; for
> example, Lukasz edited the whatsnew document for 3.9.  If you want to
> ensure there is "whatsnew" coverage for your change you should contact the
> relevant editor for that version.
>

I will also say that I have floated the idea of trying to be more
diligent/thoughtful of managing What's New entries (at least for the
initial population of that doc) as I know various editors in the past have
said it's a huge time sink (so it's more editorial and less gathering). But
they have also said they didn't care about a tool to help compile the
initial entries, so 路‍♂️.


>
> */arry*
> ___
> 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/DYLP6YAW23JSQNCQ5WZL4B5KKIWN6MXW/
> 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/PMROEXCWZKA6I2ANHDWBUTBK6IMVXK3Z/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: macOS issues with 3.8.7rc1

2020-12-09 Thread Brett Cannon
On Wed, Dec 9, 2020 at 10:16 AM Gregory P. Smith  wrote:

>
>
> As a meta question: Is there a good reason to support binaries running on
> macOS earlier than ~ $latest_version-1?
>
> Aren't systems running those old releases rather than upgrading
> unsupported by Apple, never to be patched, and thus not wise to even have
> on a network?
>

I don't know if Apple has a written policy on support for older versions of
macOS.

Looking at https://support.apple.com/en-us/HT201222 it suggests that macOS
10.13 High Sierra got an update last month, but 10.12 has not been updated
since September 2019.


>
> Yes, that means some very old hardware becomes useless as Apple drops
> support. But that is what people signed up for when they bought it. Why
> should that be our problem?
>
> (It sounds like y'all will make it work, that's great! I'm really just
> wondering where the motivation comes from)
>

I would be supportive of saying our support policy for macOS is up to one
year after the last security update which would mean we would support 10.13
and newer which was released September 2017. (Honestly, I would be fine
with 6 months since Apple seems to make security releases frequently enough
to use that as an indicator that they have dropped support, but one year
seems more "reasonable" as a way to not accidentally cut support off
prematurely.)

-Brett


>
> -gps
>
> On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc 
> wrote:
>
>> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren 
>> wrote:
>>
>>>
>>>
>>> On 8 Dec 2020, at 19:59, Gregory Szorc  wrote:
>>>
>>> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding
>>> macOS.
>>>
>>> Without the changes from https://github.com/python/cpython/pull/22855
>>> backported, attempting to build a portable binary on macOS 11 (e.g. by
>>> setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning:
>>> 'XXX' is only available on macOS 10.13 or newer
>>> [-Wunguarded-availability-new]` warnings during the build. This warning
>>> could be innocuous if there is run-time probing in place (the symbols in
>>> question are weakly linked, which is good). But if I'm reading the code
>>> correctly, run-time probing was introduced by commits like eee543722 and
>>> isn't present in 3.8.7rc1.
>>>
>>> I don't have a machine with older macOS sitting around to test, but I'm
>>> fairly certain the lack of these patches means binaries built on macOS 11
>>> will blow up at run-time when run on older macOS versions.
>>>
>>> These same patches also taught CPython to build and run properly on
>>> Apple ARM hardware. I suspect some people will care about these being
>>> backported to 3.8.
>>>
>>> We know. Backporting the relevant changes to 3.8 is taking more time
>>> than I had hoped. It doesn’t help that I’ve been busy at work and don’t
>>> have as much energy during the weekend as I’d like.
>>>
>>> The backport to 3.9 was fairly easy because there were few changes
>>> between master and the 3.9 branch at the time. Sadly there have been
>>> conflicting changes since 3.8 was forked (in particular in posixmodule.c).
>>>
>>> The current best practice for building binaries that work on macOS 10.9
>>> is to build on that release (or rather, with that SDK).  That doesn’t help
>>> if you want to build Universal 2 binaries though.
>>>
>>
>> Thank you for your hard work devising the patches and working to backport
>> them.
>>
>> I personally care a lot about these patches and I have the technical
>> competency to perform the backport. If you need help, I could potentially
>> find time to hack on it. Just email me privately (or ping @indygreg on
>> GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely
>> cherry pick the patches for
>> https://github.com/indygreg/python-build-standalone. And I'm sure other
>> downstream packagers will want them as well. So having them in an
>> unreleased 3.8 branch is better than not having them at all.
>> ___
>> 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/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/
>> 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/Q45VNQYOYXTRRTA26Q4M2WNXPFKL4S2O/
> 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/

[Python-Dev] SC 2020 recommendation for PEP 634

2020-12-07 Thread Brett Cannon
After much deliberation, the 2020 SC will be making a recommendation to the
2021 SC to accept PEP 634 (although this was not a unanimous decision).
This is in no way a binding recommendation to the 2021 SC (even if a
majority of current council members get re-elected), but we felt we should
pass on our thoughts to the next council as we have been discussing pattern
matching for a few months at this point and we promised we would make some
decision to the PEP authors.
___
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/XPAQO6FNS4AL7UMO6ADZOAEZEXVVHU7V/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

2020-11-30 Thread Brett Cannon
On Sun, Nov 29, 2020 at 8:54 AM Miro Hrončok  wrote:

> On 11/28/20 9:30 PM, Paul Ganssle wrote:
> > Considering the people involved and the nature of the list, I suspect
> that
> > adding a new @python.org mailing list would be better than discourse.
> In my
> > experience, it's very difficult to just follow a single topic on the
> discourse,
> > and most people complain that the e-mail integration is not great. For
> something
> > like, "Here's a head's up about something affecting distributors", I
> don't think
> > Discourse offers much in the way of advantages.
> >
> > My guess is that distributors would be happiest with a relatively
> low-volume
> > e-mail list that would point to discussions happening elsewhere (or that
> > announces changes relevant to distributors).
>
> I totally agree with that. Following a mailing list is simple. Following a
> category on discuss.python.org not so much.
>

Then someone else will need to set that up as I don't manage new mailing
lists anymore. 

-Brett


>
> I understand the argument that mailing lists are weird for new
> contributors
> etc., but I guess that distributors need to know how to handle mailing
> lists
> already anyway.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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/U7RC7PZQXA44B34K7IHSGCLM3LMVZZY3/
> 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/HZ5EAY242PE2SWBBROGEFMOE2LZ6W4IQ/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

2020-11-28 Thread Brett Cannon
So that's two people. If five people involved in the distribution of Python
speak up I will go ahead and create a category on discuss.python.org
(people can ask sooner, but my personal threshold here to do the work
myself is 5 ).

On Wed., Nov. 25, 2020, 00:18 Petr Viktorin,  wrote:

> On 11/24/20 7:50 PM, Brett Cannon wrote:
> > If enough people were interested we could create a "Distributors"
> > category on discuss.python.org <http://discuss.python.org>.
>
> I'd join :)
>
> >
> > On Tue, Nov 24, 2020 at 9:08 AM Tianon Gravi  > <mailto:admwig...@gmail.com>> wrote:
> >
> >  > I'd love to have an easy way to keep them in the loop.
> >
> > I'm one of the maintainers on
> > https://github.com/docker-library/python
> > <https://github.com/docker-library/python>
> > (which is what results in https://hub.docker.com/_/python
> > <https://hub.docker.com/_/python>), and I'd
> > love to have an easy way to keep myself in the loop too! O:)
> >
> > Is there a lower-frequency mailing list where things like this are
> > normally posted that I could follow?
> > (I don't want to be a burden, although we'd certainly really love to
> > have more upstream collaboration on that repo -- we do our best to
> > represent upstream as correctly/accurately as possible, but we're not
> > experts!)
> >
> >  > would it make sense to add a packaging section to our
> > documentation or
> >  > to write an informational PEP?
> >
> > FWIW, I love the idea of an explicit "packaging" section in the docs
> > (or a PEP), but I've maintained that for other projects before and
> > know it's not always easy or obvious. :)
> >
> > ♥,
> > - Tianon
> >4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
> >
> > PS. thanks doko for giving me a link to this thread! :D
> ___
> 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/66HPNHT576JKSFOQXJTCACX5JRNERMWV/
> 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/STBTZ6V525QBCCNRTIOVYXPXBB7Z3CE4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Thanks for the Dev Guide

2020-11-26 Thread Brett Cannon
The first versions of the devguide and the CLA bot are me, but tons of
people have helped out over the years with both of these things and our dev
process overall who share in the thanks. 

And glad the process went well for you, Richard!

On Thu, Nov 26, 2020 at 11:54 AM Larry Hastings  wrote:

>
> The dev guide is a community project, like all of Python.  But IIRC the
> person who drove it and did I think most of the heavy lifting on it was
> Brett Cannon.
>
> And yes, it *is* excellent, isn't it :D
>
>
> */arry*
>
> On 11/26/20 11:28 AM, Richard Levasseur wrote:
>
> Hi everyone,
>
> I just wanted to express some appreciation for the excellent Dev Guide.
>
> I don't use git or github much, but the dev guide got me from not knowing
> where to start, to having a PR out for review in a couple hours. It walked
> me through...pretty much perfectly.
>
> Getting a CLA signed was also simple and nice. When the bot brought that
> up, I thought it'd be a headache big enough to keep the PR from
> ever getting back to the top of my todo list. But the help text and links
> from the bot, the integration of BPO with Google sign in, linking BPO to a
> github name, digitally signing the CLA, the little heroku thing -- all just
> self serve, and easy, and obvious, and really just didn't get in the way.
>
> I don't know which person(s) are the best to thank for all that, but
> thanks for making it easy for a newbie to get started and contribute.
>
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to 
> python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/RHMLET7NUCSWRDMZYDTUD637G6HAME3J/
> 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/RGJQHNKXRCMVQI6FBE7LDWRCJOM5YUGO/
> 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/UCXT46VB2FTUI2G5CFJOTZ24MTQOIOAL/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

2020-11-24 Thread Brett Cannon
If enough people were interested we could create a "Distributors" category
on discuss.python.org.

On Tue, Nov 24, 2020 at 9:08 AM Tianon Gravi  wrote:

> > I'd love to have an easy way to keep them in the loop.
>
> I'm one of the maintainers on https://github.com/docker-library/python
> (which is what results in https://hub.docker.com/_/python), and I'd
> love to have an easy way to keep myself in the loop too! O:)
>
> Is there a lower-frequency mailing list where things like this are
> normally posted that I could follow?
> (I don't want to be a burden, although we'd certainly really love to
> have more upstream collaboration on that repo -- we do our best to
> represent upstream as correctly/accurately as possible, but we're not
> experts!)
>
> > would it make sense to add a packaging section to our documentation or
> > to write an informational PEP?
>
> FWIW, I love the idea of an explicit "packaging" section in the docs
> (or a PEP), but I've maintained that for other projects before and
> know it's not always easy or obvious. :)
>
> ♥,
> - Tianon
>   4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
>
> PS. thanks doko for giving me a link to this thread! :D
> ___
> 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/MVGTU4WY6VHPBQCWVQTQ3VJ44RWDINYC/
> 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/BT2E5SN3NMWGB26SM36FGHPBHIK5GKTD/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: The semantics of pattern matching for Python

2020-11-19 Thread Brett Cannon
On Thu, Nov 19, 2020 at 5:16 AM Steve Holden  wrote:

> On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset 
> wrote:
>
>> [sorry for the duplicate, meant to reply-all]
>>
>> Thank you for this approach, I find it really helpful to put the
>> conversation in these terms (semantics and guiding principles).
>>
>> It does help to rationalise discussion ;-)
>
>> [...]
>> 4. "Objects should be able determine which patterns they match."
>> This is something that you and I, and most of the authors of 622 agree
>> on. What we found out when discussing this is that we didn't have clear
>> what and how to open that customization. Some customization options added a
>> lot of complexity at the cost of performance, some others were very simple
>> but it wasn't clear that they would be actually useful, or extensible in
>> the future. This has a lot to do with this being a somewhat new paradigm in
>> Python, and our lack of knowledge on what the user community may do with it
>> beyond what we imagined. So the decision was "pattern matching as it is
>> presented without extensibility is useful, let's get this in, and once we
>> see how it is used in the wild we'll understand better what kind of
>> extensibility is valuable". For a crude analogy, imagine trying to get the
>> descriptor protocol right when the basic python object model was being
>> implemented. These things happened as different times as the use of the
>> language evolved, and my opinion is that customization of the match
>> protocol must follow a similar path.
>>
>>
> I haven't so far understood whether the change proposed is intended to
> start out in __future__. Given the preliminary nature of this development,
> it would seem wise to retain the option to withdraw it or modify it
> radically before production code depends on it.
>

The current proposal is not for it to be put behind a __future__ statement
as it doesn't conflict with or break any pre-existing source code.
___
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/BN4HQBX72L5GMVNEBGQDOSF6F3L4VRTS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: How Cpython repository has a pre-commit hook ? (as in PEP8)

2020-11-19 Thread Brett Cannon
On Thu, Nov 19, 2020 at 10:47 AM Nilo César Teixeira <
nilo.teixe...@gmail.com> wrote:

> Hello,
>
> I'm not a Python contributor but I have a question which (I believe) can
> be answered here, so I've subscribed.
>
> The question is at stackoverflow:
> https://stackoverflow.com/questions/64912716/are-pre-commit-hooks-clonable
>
> After some research the only thing similtar to a git pre-commit hook I
> could find on the cpython repo was the patchcheck.py script on
> github.com/python/cpython/tree/master/Tools/scripts (patchcheck.py),
> which runs in Travis.
>
> Is this the pre-commit hook PEP8 talks about ?
>

Yep, that's it.

-Brett


>
> Thanks for your help and attention.
>
> --
> *Nilo César Teixeira*
> nilo.teixe...@gmail.com
> (55) (11) 98571-5314
> ___
> 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/DKLD2VLHZ3F54WTKZ7JHKWBMOZ4N5TK7/
> 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/26IPP7DNNXT7V765QI2SVQTZU5B7ESKG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

2020-11-18 Thread Brett Cannon
On Wed, Nov 18, 2020 at 1:25 AM Robin Becker  wrote:

> Is there a bestiary of examples for the current pattern matching
> proposal(s)?
>
> It seems I don't have a good handle on how one matches simple tests like
> callability,


Doable using protocols.


> function signatures,


I don't think that's directly doable, but there might be some way to bend
it to protocols.


> possession of
> specific attribute(s).etc.
>

Protocols.


>
> Also will matching ever extend into the Typing universe?
>

In what way do you have in mind? With protocol support baked into PEP 634
that already ties into type hints.

-Brett


>   --
> Robin Becker
> ___
> 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/OKBOTKDQ6WBEDPCBTDRYRI5HRDHRDVER/
> 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/YMLP5QDXRCO2QJG2GXJFIG3F4F56VLPL/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

2020-11-18 Thread Brett Cannon
On Tue, Nov 17, 2020 at 10:16 PM Greg Ewing 
wrote:

> On 18/11/20 4:36 pm, Larry Hastings wrote:
> >
> > But,
> > the thinking went, you'd never want to examine the last value from a
> > list generator, so it was more convenient if it behaved as if it had its
> > own scope.
>
> List comprehensions used to leak, but apparently that was considered
> surprising by enough people that it was changed.
>
> Generator expressions are a bit different -- the only sane way to
> implement them was to make the body implicitly a separate function,
> and non-leaking behaviour naturally fell out of that. Making them
> leak would have taken extra work just to get something that nobody
> really had a good use case for.
>
> The desire to make list comprehensions and generator expressions
> behave consistently may have contributed to the decision to change
> list comprehensions to be non-leaking.
>

It did if I remember correctly.

For me, generator expressions are small functions like you say (see, people
did get the equivalent of multi-line lambdas, just in a very specific
format ), and all the comprehensions are just passing a generator
expression to the appropriate constructor, e.g. list(), set(), and dict().
In that regard the scoping is consistent to me.

-Brett


>
> So yes, it's all a bit messy, for reasons that are partly historical
> and partly pragmatic, but things seem to work out okay in practice
> most of the time.
>
> If there's anything I would change, it would be to have the for
> statement create a new binding on each iteration, so that capturing
> it with a def or lambda inside the loop works as expected. I even
> came up with a way to do that while still allowing the last-bound
> value to be seen afterwards, but the idea didn't gain any traction.
>
> --
> Greg
> ___
> 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/FC7WYLN7C54ZK2FRQSLH5GFA4P2OHBBC/
> 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/OI2DAQYQT3PWL2K3WSG2TA2U3TN2FYGB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Questions about about the DLS 2020

2020-11-18 Thread Brett Cannon
ing pattern matching later was more to comment on the
fact that the languages that use "_" for a wildcard pattern did it from
early on, not later on; it had nothing to do with the proposal proposing
pattern matching late in Python's history.


>
> Kind regards,
> Tobias
>
> P.S. Sorry, I guess this turned out to be not so much a reply to your
> comment alone, as much more a reply to many a message and discussion that
> has been posted here over time.
>
> [1]  https://docs.microsoft.com/en-us/dotnet/csharp/discards
>
>
>
> Quoting Brett Cannon :
>
>
>
> On Mon, Nov 16, 2020 at 9:03 AM Tobias Kohn  wrote:
>
>>
>>
>>
>>
>>
>> *Hi Mark, Thank you for your interest and the questions. 1.  This really
>> comes down to how you look at it, or how you define pattern matching.  The
>> issue here is that the concept of pattern matching has grown into a large
>> and somewhat diverse flock of interpretations and implementations (as a
>> side note: interestingly enough, some of the only universally agreed-upon
>> standards are to use `_` as a wildcard and not to mark names that
>> capture/bind values---which are quite exactly the points most fiercely
>> debatted here).*
>>
> *How many of those languages added pattern matching later and not at the
> earliest stages of the language (if not from the beginning)? And for those
> that added it later, how many of those didn't already have a convention
> surrounding "_"? My suspicion is "not many" and "not many". *
>
> *-Brett*
>
>
>
> ___
> 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/KP2TVEAPDT553VXL4QEUOTYBHHMDUXSK/
> 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/JAEG626UEUEC7BP3OMQFWMED6OHQOTPG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Questions about about the DLS 2020

2020-11-17 Thread Brett Cannon
On Mon, Nov 16, 2020 at 9:03 AM Tobias Kohn  wrote:

> Hi Mark,
>
> Thank you for your interest and the questions.
>
>
> 1.  This really comes down to how you look at it, or how you define
> pattern matching.  The issue here is that the concept of pattern matching
> has grown into a large and somewhat diverse flock of interpretations and
> implementations (as a side note: interestingly enough, some of the only
> universally agreed-upon standards are to use `_` as a wildcard and not to
> mark names that capture/bind values---which are quite exactly the points
> most fiercely debatted here).
>
How many of those languages added pattern matching *later* and not at the
earliest stages of the language (if not from the beginning)? And for those
that added it later, how many of those didn't already have a convention
surrounding "_"? My suspicion is "not many" and "not many". 

-Brett
___
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/VZHF7GJ637YULIU53MCCH26T4LWJ2YP6/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: [python-committers] Re: Steering Council Election Timeline for 2021 term

2020-11-16 Thread Brett Cannon
Ernest closed the nominations and we ended up with 10 nominees! Thanks to
everyone who stepped forward to serve on the SC.

I would like to encourage people to take the time to read everyone's
nomination posts as stances on a wide variety of topics ranging from
pattern matching to the Code of Conduct are covered by them. And with
Victor not running again, there's going to be, at minimum, one new person
on the SC in 2021.

https://discuss.python.org/c/core-dev/steering-council-nominations/21

On Sun, Nov 15, 2020 at 9:18 AM Victor Stinner  wrote:

> Reminder: the deadline for nomination is tonight, hurry up ;-)
>
> Current candidates can be found at:
> https://discuss.python.org/c/core-dev/steering-council-nominations/21
>
> Victor
>
> Le mer. 28 oct. 2020 à 20:55, Ewa Jodlowska  a écrit :
> >
> > Hi!
> >
> > The timeline for this year's election will be the same as last year.
> >
> > * The nomination period will begin Nov 1, 2020 (do not post nominations
> until then)
> > * Nomination period will end Nov 15, 2020
> > * Voting will begin Dec 1, 2020
> > * Voting will end Dec 15, 2020
> >
> > Nominations will be collected via https://discuss.python.org/ (more
> details to follow on Nov 1).
> >
> > New for this year: Ernest W. Durbin III will be running the vote along
> with the assistance of Joe Carey, a PSF employee. They will be co-admins
> going forward. I have cc'ed them in on this thread as well in case there
> are any questions.
> >
> > Thanks,
> >
> > Ewa
> >
> > ___
> > python-committers mailing list -- python-committ...@python.org
> > To unsubscribe send an email to python-committers-le...@python.org
> > https://mail.python.org/mailman3/lists/python-committers.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-committ...@python.org/message/JHYSU6FEYM3A5AZXSICO5OE3VAWDPGEJ/
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> python-committers mailing list -- python-committ...@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committ...@python.org/message/LTAY635DKLMR2655CQN2S5Z7YBILDF24/
> Code of Conduct: https://www.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/CECK4QMWBDUAS4EXYQAZBVWBC6R3S6KS/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

2020-11-13 Thread Brett Cannon
On Thu, Nov 12, 2020 at 11:41 PM Paul Sokolovsky  wrote:

> Hello,
>
> On Thu, 12 Nov 2020 12:51:19 -0800
> Guido van Rossum  wrote:
>
> > I have a meta-observation. Clearly there are too many cooks here. The
> > same suggestions keep getting brought up. We will never converge on a
> > design this way.
>
> Right, it's not a Python decision unless it's forced thru like PEP572,
> aka the ":=" (https://lwn.net/Articles/757713/ , etc.). Can also
> remember the whole Python3 migration business
> (
> https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/
> ,
> etc).
>

Please keep the conversation civil.

-Brett
___
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/343C7JHTIEOFCZT2BO2GRZEKVICF4D37/
Code of Conduct: http://python.org/psf/codeofconduct/


  1   2   3   4   5   6   7   8   9   10   >