[Python-Dev] PEP 614: Relaxing Grammar Restrictions On Decorators

[Brandt Bucher]

PEP 614 has recently completed a round of review on Python-Ideas:

https://www.python.org/dev/peps/pep-0614/

It proposes that the current decorator syntax restrictions be relaxed to allow 
any valid expression. Nobody has raised any objections, but I wanted to gather 
more feedback here prior to bringing it before the Steering Council.

Please let me know what you think... thanks! :)
___
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/SLKFAR56RA6A533O5ZOZ7XTJ764EMB7I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python Language Summit at PyCon 2020

[Mariatta]

Just to remind everyone that signup to the language summit is still open
for another 11 days.

So far folks have proposed topic like: f-strings, CPython’s documentation,
PEG parser, property-based testing, and more!

We’ve received a number inquiries about the language summit, so here are
some Q:

1. Do I need to sign up if I’m a Python core developer?

Yes please! Attendance is limited to 50 people. Please register to reserve
your seat in the room.

2. Can I sign up if I’m not a Python core developer?

Yes you can. Last year we had 15 participants (out of 50) who were not
Python core devs. Among them were maintainers and representatives from
BeeWare, CircuitPython, PSF board member, PyCharm, etc.

Full details at: https://us.pycon.org/2020/events/languagesummit/


On Tue, Jan 28, 2020 at 1:07 PM Mariatta  wrote:

> (cross posting to python-committers and python-dev)
>
> I'm happy to announce that the signups for Python Language Summit at PyCon
> 2020 is now open.
>
> Full details at: https://us.pycon.org/2020/events/languagesummit/
>
> *TL;DR*
>
> When: Wednesday, April 15, 2020, 9am–4pm (Note, we’re starting 1 hour
> earlier than usual!)
> Where: David L. Lawrence Convention Center, Pittsburgh, PA, room TBD
>
> Sign up to attend: https://forms.gle/Fg7ayhYTaY75J1r7A (closes Feb 29th,
> 2020 AoE)
> Sign up to discuss a topic: https://forms.gle/g4BXezH1Vcn7tLds5 (closes
> Feb 29th, 2020 AoE)
>
> *Who can attend*
>
> We welcome Python core developers, active core contributors to Python and
> alternative Python implementations, and anyone else who has a topic to
> discuss with core developers.
>
> *Who can propose a discussion topic*
>
> If you have discussion items; seeking consensus; awaiting decision on a
> PEP; needing help with your core dev work; or have specific questions that
> need answers from core developers, please submit a proposal. According to
> last year’s feedback, our audience prefer more discussions and shorter
> talks.
>
> To get an idea of past language summits, you can read past years' coverage:
> 2019:
> http://pyfound.blogspot.com/2019/05/the-2019-python-language-summit.html
> 2018: https://lwn.net/Articles/754152/
> 2017: https://lwn.net/Articles/723251/
>
> This year's event will be covered by A. Jesse Jiryu Davis again, and will
> be posted on PSF's blog.
> 
>
> Some changes to note this year:
> 1) We plan to start 1 hour earlier (9AM)
> 2) The room will have U-shaped table layout
>
> Thanks!
>
>
> Mariatta & Łukasz
>
___
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/ND67QOVC23PYIPIHWMBYP2NOTEFOOUQ2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

[Brandt Bucher]

> In particular, you may want to update the implementations of defaultdict and 
> ordereddict. (are there others?)

I have a checklist for PEP 584 follow-up PRs I'm planning to make after (and 
if) it is accepted. typeshed stubs, docs, and `defaultdict` were on it. I'll 
add `OrderedDict` as well (for some reason I didn't think it was a `dict` 
subclass). `Counter` already defines this operator for other purposes, so no 
need to do anything there.

I'm not aware of other public subclasses, but I may just try importing the 
whole stdlib and recursing through `dict.__subclasses__()` just to be sure.
___
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/3SJTNSTTZ4G5CXQQWNWRBY7WZHEWBYEY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

[Guido van Rossum]

On Tue, Feb 18, 2020 at 9:40 AM Brandt Bucher 
wrote:

>
> Now, addressing Serhiy's points :)...
>
> > ...it was decided that `d1 | d2` also should ignore the types of the
> operands and always return a dict. And it accepts only dicts, not general
> mappings, in difference to `{**d1, **d2}`. So the only disadvantage of
> `{**d1, **d2}` is that it is not well known and "looks ugly".
>
> Not quite. While this point *has* been weakened a bit with the recent
> semantic change, you don't mention that `dict` subclasses can (and likely
> would) override the `__or__` trio with wrapped `super()` calls. So while
> `{**d1, **d2}` will *never* be anything but a `dict`, I can trust that
> well-written `dict` subclasses my code encounters will still be able to
> preserve themselves with `d1 | d2`, if desired.
>

In particular, you may want to update the implementations of defaultdict
and ordereddict. (are there others?)

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

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

[Brandt Bucher]

> I am accepting this PEP. Congratulations Steven and Brandt!

Thank you for your guidance, especially the suggestions late last year. And 
thanks Steven for taking me on as a co-author and shaping the bulk of the 
proposal.

> Hm, the PEP should probably also link to that PR rather than to Brandt's 
> private branch.

Agreed. This can probably be changed when the status is updated.

Now, addressing Serhiy's points :)...

> ...it was decided that `d1 | d2` also should ignore the types of the operands 
> and always return a dict. And it accepts only dicts, not general mappings, in 
> difference to `{**d1, **d2}`. So the only disadvantage of `{**d1, **d2}` is 
> that it is not well known and "looks ugly".

Not quite. While this point *has* been weakened a bit with the recent semantic 
change, you don't mention that `dict` subclasses can (and likely would) 
override the `__or__` trio with wrapped `super()` calls. So while `{**d1, 
**d2}` will *never* be anything but a `dict`, I can trust that well-written 
`dict` subclasses my code encounters will still be able to preserve themselves 
with `d1 | d2`, if desired.

> The pure-Python implementation of the non-inplace operator can be simpler if 
> use dict unpacking.

The purpose of the pure-Python implementation in the PEP is to be a clear, 
understandable example that serves as a codification of the semantics, not to 
be the shortest one-liner. The suggested changes make the code less readable, 
making it harder to see exactly what will happen if I do `self | other`. I'm 
against changing it, for that reason.

> I suggest to include to objections that non-inplace merging of two dicts is 
> much less common operation than concatenating of two strings or other 
> sequences, and that the existing syntax {**d1, **d2} completely satisfies the 
> need.

This is really two objections.

Regarding the commonality of this operation, we've provided eighteen detailed 
examples of third-party library code that are candidates for these new 
operators. To the best of my knowledge, a large survey like this is 
unprecedented in a PEP. Whether or not it is more common than a different 
operation on other types isn't relevant here. We have gone above and beyond in 
demonstrating the use cases in detail.

A rewording of your second objection has already been addressed:

https://www.python.org/dev/peps/pep-0584/#more-than-one-way-to-do-it

I feel that I've adequately responded to the other points you've raised here in 
this email (please let me know if I missed anything, and perhaps Steven may 
want to chime in as well). I don't know what the policy for changing the PEP is 
once it's gotten to this stage, but it's already grown to a huge size in its 
attempts to address every possible concern that has arisen over the past year 
(even some that, in my opinion, weren't serious proposals that needed to be 
acknowledged). I'd prefer not to bloat it even more this late in the game, if 
at all possible.
___
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/TEC4G6LVTHFL566ELDC4J6S527LI5C37/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Dong-hee Na]

> And proposed a first pull request to add again collections.Mapping:

https://github.com/python/cpython/pull/18245

FYI, this patch is adding a fixer to handling abstract base classes.
It will be helpful for the migration to new changes.
I hope someone reviews this.


2020년 2월 18일 (화) 오후 8:44, Victor Stinner 님이 작성:
>
> Hi,
>
> I created an issue:
>
> "Keep deprecated features in Python 3.9 to ease migration from Python
> 2.7, but remove in Python 3.10"
> https://bugs.python.org/issue39674
>
> And proposed a first pull request to add again collections.Mapping:
>
> https://github.com/python/cpython/pull/18545
>
> Victor
>
> Le jeu. 23 janv. 2020 à 16:20, Victor Stinner  a écrit :
> >
> > Hi,
> >
> > Python 3.9 introduces many small incompatible changes which broke tons
> > of Python projects, including popular projects, some of them being
> > unmaintained but still widely used (like nose, last release in 2015).
> >
> > Miro and me consider that Python 3.9 is pushing too much pressure on
> > projects maintainers to either abandon Python 2.7 right now (need to
> > update the CI, the documentation, warn users, etc.), or to introduce a
> > *new* compatibility layer to support Python 3.9: layer which would be
> > dropped as soon as Python 2.7 support will be dropped (soon-ish).
> >
> > Python 3.9 is too early to accumulate so many incompatible changes on
> > purpose, some incompatible changes like the removal of collections
> > aliases to ABC should be reverted, and reapplied on Python 3.10.
> > Python 3.9 would be the last release which still contain compatibility
> > layers for Python 2.7.
> >
> > Said differently, we request to maintain the small compatibility layer
> > in Python for one more cycle, instead of requesting every single
> > project maintainer to maintain it on their side. We consider that the
> > general maintenance burden is lower if it's kept in Python for now.
> >
> >
> > == Fedora COPR notify packages broken by Python 3.9 ==
> >
> > In Python 3.9, Victor introduced tons of incompatible changes at the
> > beginning of the devcycle. His plan was to push as many as possible,
> > and later decide what to do... This time has come :-) He wrote PEP 606
> > "Python Compatibility Version" and we wrote PEP 608 "Coordinated
> > Python release", but both have been rejected. At least, it seems like
> > most people agreed that having a CI to get notified of broken projects
> > should help.
> >
> > We are updating the future Fedora 33 to replace Python 3.8 with Python
> > 3.9. We are using a tool called "COPR" which is like a sandbox and can
> > be seen as the CI discussed previously. It rebuilds Fedora using
> > Python 3.9 as /usr/bin/python3 (and /usr/bin/python !). We now have a
> > good overview of broken packages and which incompatible changes broke
> > most packages.
> >
> > https://fedoraproject.org/wiki/Changes/Python3.9
> > - Describes the Fedora change.
> >
> > https://copr.fedorainfracloud.org/coprs/g/python/python3.9/monitor/
> > - Has package failures. Some packages fail because of broken dependencies.
> >
> > https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTHON39
> > - Has open Python 3.9 bug reports for Fedora packages. Some problems
> > have been fixed upstream already before reaching Fedora, most are only
> > fixed when the Fedora maintainers report the problems back to upstream
> > maintainers.
> >
> > Right now, there are 150+ packages broken by Python 3.9 incompatible 
> > changes.
> >
> >
> > == Maintenance burden ==
> >
> > Many Python projects have not yet removed Python 2 support and Python
> > 2 CI. It's not that they would be in the "we will not drop Python 2
> > support ever" camp, it's just that they have not done it yet. Removing
> > Python 2 compatibility code from the codebase and removing it from the
> > documentation and metadata and CI is a boring task, doesn't bring
> > anything to users, and it might take a new major release of the
> > library. At this point, we are very early in 2020 to expect most
> > projects to have already done this.
> >
> > At the same time, we would like them to support Python 3.9 as soon in
> > the release cycle as possible. By removing Python 2 compatibility
> > layers from the 3.9 standard library, we are forcing the projects
> > maintainers to re-invent their own compatibility layers and copy-paste
> > stuff like this around. Example:
> >
> > try:
> > from collections.abc import Sequence
> > except ImprotError:
> > # Python 2.7 doesn't have collections.abc
> > from collections import Sequence
> >
> > While if we remove collections.Sequence in 3.10, they will face this
> > decision early in 2021 and they will simply fix their code by adding
> > ".abc" at the proper places, not needing any more compatibility
> > layers. Of course, there will be projects that will still have
> > declared Python 2 support in 2021, but it will arguably not be that
> > many.
> >
> > While it's certainly tempting to have "more pure" code in the 

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Victor Stinner]

Hi,

I created an issue:

"Keep deprecated features in Python 3.9 to ease migration from Python
2.7, but remove in Python 3.10"
https://bugs.python.org/issue39674

And proposed a first pull request to add again collections.Mapping:

https://github.com/python/cpython/pull/18545

Victor

Le jeu. 23 janv. 2020 à 16:20, Victor Stinner  a écrit :
>
> Hi,
>
> Python 3.9 introduces many small incompatible changes which broke tons
> of Python projects, including popular projects, some of them being
> unmaintained but still widely used (like nose, last release in 2015).
>
> Miro and me consider that Python 3.9 is pushing too much pressure on
> projects maintainers to either abandon Python 2.7 right now (need to
> update the CI, the documentation, warn users, etc.), or to introduce a
> *new* compatibility layer to support Python 3.9: layer which would be
> dropped as soon as Python 2.7 support will be dropped (soon-ish).
>
> Python 3.9 is too early to accumulate so many incompatible changes on
> purpose, some incompatible changes like the removal of collections
> aliases to ABC should be reverted, and reapplied on Python 3.10.
> Python 3.9 would be the last release which still contain compatibility
> layers for Python 2.7.
>
> Said differently, we request to maintain the small compatibility layer
> in Python for one more cycle, instead of requesting every single
> project maintainer to maintain it on their side. We consider that the
> general maintenance burden is lower if it's kept in Python for now.
>
>
> == Fedora COPR notify packages broken by Python 3.9 ==
>
> In Python 3.9, Victor introduced tons of incompatible changes at the
> beginning of the devcycle. His plan was to push as many as possible,
> and later decide what to do... This time has come :-) He wrote PEP 606
> "Python Compatibility Version" and we wrote PEP 608 "Coordinated
> Python release", but both have been rejected. At least, it seems like
> most people agreed that having a CI to get notified of broken projects
> should help.
>
> We are updating the future Fedora 33 to replace Python 3.8 with Python
> 3.9. We are using a tool called "COPR" which is like a sandbox and can
> be seen as the CI discussed previously. It rebuilds Fedora using
> Python 3.9 as /usr/bin/python3 (and /usr/bin/python !). We now have a
> good overview of broken packages and which incompatible changes broke
> most packages.
>
> https://fedoraproject.org/wiki/Changes/Python3.9
> - Describes the Fedora change.
>
> https://copr.fedorainfracloud.org/coprs/g/python/python3.9/monitor/
> - Has package failures. Some packages fail because of broken dependencies.
>
> https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTHON39
> - Has open Python 3.9 bug reports for Fedora packages. Some problems
> have been fixed upstream already before reaching Fedora, most are only
> fixed when the Fedora maintainers report the problems back to upstream
> maintainers.
>
> Right now, there are 150+ packages broken by Python 3.9 incompatible changes.
>
>
> == Maintenance burden ==
>
> Many Python projects have not yet removed Python 2 support and Python
> 2 CI. It's not that they would be in the "we will not drop Python 2
> support ever" camp, it's just that they have not done it yet. Removing
> Python 2 compatibility code from the codebase and removing it from the
> documentation and metadata and CI is a boring task, doesn't bring
> anything to users, and it might take a new major release of the
> library. At this point, we are very early in 2020 to expect most
> projects to have already done this.
>
> At the same time, we would like them to support Python 3.9 as soon in
> the release cycle as possible. By removing Python 2 compatibility
> layers from the 3.9 standard library, we are forcing the projects
> maintainers to re-invent their own compatibility layers and copy-paste
> stuff like this around. Example:
>
> try:
> from collections.abc import Sequence
> except ImprotError:
> # Python 2.7 doesn't have collections.abc
> from collections import Sequence
>
> While if we remove collections.Sequence in 3.10, they will face this
> decision early in 2021 and they will simply fix their code by adding
> ".abc" at the proper places, not needing any more compatibility
> layers. Of course, there will be projects that will still have
> declared Python 2 support in 2021, but it will arguably not be that
> many.
>
> While it's certainly tempting to have "more pure" code in the standard
> library, maintaining the compatibility shims for one more release
> isn't really that big of a maintenance burden, especially when
> comparing with dozens (hundreds?) of third party libraries essentially
> maintaining their own.
>
> An good example of a broken package is the nose project which is no
> longer maintained (according to their website): the last release was
> in 2015. It remains a very popular test runner. According to
> libraries.io, it has with 3 million downloads per month, 41.7K
> dependent 

[Python-Dev] [RELEASE] Python 3.8.2rc2 is now available for testing

[Łukasz Langa]

Python 3.8.2rc2 is the second release candidate of the second maintenance 
release of Python 3.8. Go get it here:

https://www.python.org/downloads/release/python-382rc2/ 


Why a second release candidate?

The major reason for RC2 is that GH-16839 
 has been reverted.

The original change was supposed to fix for some edge cases in urlparse 
(numeric paths, recognizing netlocs without //; details in BPO-27657 
). Unfortunately it broke third parties 
relying on the pre-existing undefined behavior.

Sadly, the reverted fix has already been released as part of 3.8.1 (and 3.7.6 
where it’s also reverted now). As such, even though the revert is itself a bug 
fix, it is incompatible with the behavior of 3.8.1.

Please test.


Timeline

Assuming no critical problems are found prior to 2020-02-24, the currently 
scheduled release date for 3.8.2 (as well as 3.9.0 alpha 4!), 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 of 3.8.2 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.3 planned for April 2020 (during sprints at PyCon US).


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.

Detailed information about all changes made in version 3.8.2 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.

https://www.python.org/psf/ 


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