[Python-Dev] Re: PEP 632: Deprecate distutils module

[Steve Dower]

On 07Sep2020 1602, Stefan Krah wrote:

I'm under the impression that distutils has effectively been frozen for
the last decade, except for the substantial improvements you made for the
MSVC part.

For Unix, no one has addressed e.g. C++ support. The underlying reason
has always been that we cannot change anything lest it breaks someone's
package.


So I have some trouble understanding why we have exercised that kind
of restraint (I might have committed a very small C++ patch otherwise)
if we can now break everything at once.


Others have contributed a range of little fixes over time. Maybe they 
blur into the background noise of regular maintenance, but it does add up.


The main reason we end up needing to fix things is because platforms 
change things. Since we don't control _when_ platforms will change 
things, we either do a single controlled break at a planned Python 
version, or we allow it to break for different users at different times 
that are not detectable from version number alone. It won't take long 
for an autoconf-style approach to be necessary for figuring out how to 
use distutils (though hopefully anyone who sees that as the solution 
will also find https://packaging.python.org/ and find better solutions ;) )



Unless you're offering to take over distutils maintenance? In which case,
I'll happily withdraw the PEP :)


No, thanks. :)


Okay, maybe it is a little bit more than background noise ;)


I've looked at the log, most maintenance patches are from a variety of
active core devs (this includes, of course, the MSVC patches from you).

Will they submit patches to setuptools from now on?


If you look at the setuptools history, a variety of contributors have 
submitted much the same (and often better) fixes there. I expect I 
likely will as well, inasmuch as they are needed to help Windows users 
be successful, though I also have my own backend that will likely be 
where big features that interest me end up ;)


It's easier and more satisfying to submit the patches to setuptools, as 
the release comes out much sooner (and can be installed on earlier 
versions), and it will only get easier when _all_ the code can be fixed 
there. Right now, one of the biggest pains there is having to do loads 
of careful monkeypatching to fix one poor choice in the standard library.


Cheers,
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/7MESZKL5KFX6YBPOZNYTE5PS4PE5OJZM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Taking over xxlimited for PEP 630

[Petr Viktorin]

Hello,
The "xxlimited" module (Modules/xxlimited.c) was added as part of PEP 
384 (Defining a Stable ABI), and is undocumented. As far as I can tell, 
it was added partly to test the stable ABI, and partly as an example of 
how to write a module (like "xx" from xxmodule.c).
In the last few years the module has not seen much maintenance, and I 
believe it's no longer a good example to follow: it works, but there are 
now better ways to do things.


I would like to take over maintenance of the module and make it into an 
example of how to write a low-level C extension with isolated module 
state, as described in PEP 630 (Isolating Extension Modules) -- an 
informational PEP that I plan to convert to a HOWTO doc when everything 
is ready.


Please let me know if you think this isn't a good idea, or if there's 
something I'm missing.

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

[Python-Dev] Re: PEP 622: Arrow for capture patterns

[Luciano Ramalho]

On Sat, Sep 5, 2020 at 8:31 AM Ram Rachum  wrote:
> case x:
> match Point(-> a, -> b):
> ...
> match -> whatever:
> do_something(whatever)
>
> I like the arrow because it's easy to imagine the value "entering" the 
> variable. What do you think?

I like this syntax.

-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
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/5XALUPRONGMA2TDRGGY62GXJFVEN43D4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Arrow for capture patterns

[Eric Nieuwland]

On 5 Sep 2020 Ram Rachum  wrote:
> 
> Hi everyone,
> 
> Sorry if this was proposed already. I looked here
> https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern,
> search for "idea to make lookup semantics the default". I saw that a few
> symbols like $ and ? were proposed, and I thought that maybe the annotation
> syntax -> could indicate a capture expression, like so:
> 
>case x:
>match Point(-> a, -> b):
>...
>match -> whatever:
>do_something(whatever)
> 
> I like the arrow because it's easy to imagine the value "entering" the
> variable. What do you think?
> 
> 
> Thanks,
> Ram.


Nice! :)

Combined with keywords that could become:
Point(x -> a, y -> b)

or, mixed with providing values:
Point(x -> a, y=42)

And we wouldn’t need
match -> whatever:
because we already have x, and if x is an expression I’d prefer
case x as whatever:
___
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/AFTPEB5R2JMGVLIOOYDCGMMX2QNSTAWJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Brett Cannon]

On Tue, Sep 8, 2020 at 2:27 AM Steve Dower  wrote:

> On 07Sep2020 1602, Stefan Krah wrote:
> > I'm under the impression that distutils has effectively been frozen for
> > the last decade, except for the substantial improvements you made for the
> > MSVC part.
> >
> > For Unix, no one has addressed e.g. C++ support. The underlying reason
> > has always been that we cannot change anything lest it breaks someone's
> > package.
> >
> >
> > So I have some trouble understanding why we have exercised that kind
> > of restraint (I might have committed a very small C++ patch otherwise)
> > if we can now break everything at once.
>
> Others have contributed a range of little fixes over time. Maybe they
> blur into the background noise of regular maintenance, but it does add up.
>
> The main reason we end up needing to fix things is because platforms
> change things. Since we don't control _when_ platforms will change
> things, we either do a single controlled break at a planned Python
> version, or we allow it to break for different users at different times
> that are not detectable from version number alone. It won't take long
> for an autoconf-style approach to be necessary for figuring out how to
> use distutils (though hopefully anyone who sees that as the solution
> will also find https://packaging.python.org/ and find better solutions ;)
> )
>
> >> Unless you're offering to take over distutils maintenance? In which
> case,
> >> I'll happily withdraw the PEP :)
> >
> > No, thanks. :)
>
> Okay, maybe it is a little bit more than background noise ;)
>

And I think this is the key point. This open source project of ours has
some truths about it, including:

1. Someone is using every piece of code somewhere in the world
2. The maintenance of any of it is not free

What this PEP is arguing is that the cost/benefit ratio of "people directly
using distutils" and "us keeping it afloat" does not work out in our favour
enough to warrant us being the primary maintainers.

Now I would also say this doesn't mean the setuptools maintainers should be
expected to maintain it either; they want the code so they are forking it
and are planning to keep it working for their needs. But if anyone else
also wants to fork it and keep it running under a different
backwards-compatibility policy than setuptools then obviously anyone can.
___
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/WADTZB5BNCK4I2JVC3UCKWL2PKWJGFXW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.8.6rc1 is now ready for testing

[Łukasz Langa]

Python 3.8.6rc1 is the release candidate of the sixth maintenance release of 
Python 3.8. Go get it here:

https://www.python.org/downloads/release/python-386rc1/ 


Assuming no critical problems are found prior to 2020-09-21, the scheduled 
release date for 3.8.6, no code changes are planned between this release 
candidate and the final release.

That being said, please keep in mind that this is a pre-release and as such its 
main purpose is testing.

Maintenance releases for the 3.8 series will continue at regular bi-monthly 
intervals, with 3.8.7 planned for mid-November 2020.

What’s new?

The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. See the “What’s New in Python 
3.8 ” document for more 
information about features included in the 3.8 series.

Python 3.8 is becoming more stable. Our bugfix releases are becoming smaller as 
we progress. This one contains 80 changes, not even a half of what we got in 
3.8.4 (the following release was a hotfix). Detailed information about all 
changes made in version 3.8.6 specifically can be found in its change log 
.

We hope you enjoy Python 3.8!

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Łukasz Langa @ambv ___
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/WCMNX3JKHZVOUA2NET2NRWCU6K6OJXNY/
Code of Conduct: http://python.org/psf/codeofconduct/