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

2020-02-04 Thread Petr Viktorin 




On 2020-02-03 16:44, Antoine Pitrou wrote:

On Mon, 3 Feb 2020 13:18:46 +0100
Petr Viktorin  wrote:


I agree with the sentiment that gradual deprecations are more easily
managed, this statement about Python 3.0 is not true. The unicode
transition was never thought to be small, and that's *why* 3.0 was such
a big change.


Alright, "very small" is an overstatement. But it did seem much smaller
than it turned out to be.
https://docs.python.org/3.0/whatsnew/3.0.html lists it as the last of
the big breaking changes, while most of the porting efforts were spent
on it.


I don't think the order in this page has any relationship to the
difficulty of each change.  I'm not sure there was any particular
reason to order them in this way, but it seems to me that the easier
to understand changes were put first.

AFAIR, we were all acutely aware that the text model overhaul was going
to be the hardest change for many users (especially those who have
never encountered non-ASCII input). Most other changes in Python 3 have
a predetermined context-free repair, while migrating to the new text
model requires *thinking* about the context in which each Python 2
bytestring is used.  It forces people to think about the problem
they're solving in ways many of them didn't think of it before.


I stand corrected. Thank you!
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/U327ZCIYDQ2QVSP2E7V3O4WGIA275GSS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-02-04 Thread Rhodri James 

On 03/02/2020 22:06, Mike Miller wrote:


On 2020-02-03 01:50, Petr Viktorin wrote:
When the changes are rolled out gradually across minor releases, those 
that cause unforeseen trouble in real-world code can be identified in 
the alphas/betas, and rethought/reverted if necessary.



To be clear, my suggestion was to maintain gradual deprecations and 
warnings, but have a single removal event at the start of a new version 
major number.  So there will be many years of betas and releases to 
haggle over.


I think that just enables laziness.  "We don't need to worry about the 
deprecations, nothing is going to happen for years yet," is more or less 
what happened with the Python2 to Python3 shift.  People naturally enjoy 
adding shiny new features to their projects over maintenance.



As a refinement to the idea above, perhaps a sub rule could be added:

   - No deprecations should appear in a X.9 release to give folks time
     to prepare.


That feels like a very bad idea indeed.  If you don't tell people things 
are going away, they definitely won't prepare for that.


--
Rhodri James *-* Kynesim Ltd
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/43S4KEWSIYTZ7HBZ6KBYEMFZG6KUQOBD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Cassandra-driver acquiring tstate_lock in python3.6/threading.py while doing cluster.connect and got stuck forever

2020-02-04 Thread pankajkumar--- via Python-Dev 
Hi,
We are running cassandra using mock cassandra and interacting with python 
cassandra-driver. We are running python3.6 and we are using latest 
cassandra-driver i.e cassandra-driver 3.21.0.
What we are seeing is when calling cluster.connect it is trying to acquire a 
tstate_lock from here 
*https://github.com/python/cpython/blob/3.6/Lib/threading.py#L1072* but we are 
running another process which has acquired this lock already, here 
*https://github.com/python/cpython/blob/3.6/Lib/threading.py#L899* but here the 
lock that is acquired is not getting released, it will be released after the 
process who has acquired the lock gets killed. So my program got stuck at 
cluster.connect call forever.

My question is why the lock which has been acquired here 
*https://github.com/python/cpython/blob/3.6/Lib/threading.py#L899* not getting 
released there itself. It will be released when process gets killed. Due to 
this my program is getting stuck forever.

Traceback (most recent call first):
  
  File "/usr/lib64/python3.6/threading.py", line 1072, in _wait_for_tstate_lock
elif lock.acquire(block, timeout):
  File "/usr/lib64/python3.6/threading.py", line 1056, in join
self._wait_for_tstate_lock()
  
  File "/root/mockcassandra.py", line 179, in verify_cassandra
session = cluster.connect()


In the traceback, cluster.connect are trying to acquire the tstate_lock which 
is already acquired by another process and not releasing it until that process 
gets killed. In my case both process has to run in parallel.
Can anyone suggest how can we proceed further?
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/6EILC2GPPMX3QQQZT3L47PKRH4DR36T5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Issue with PR to ipaddress, core review needed by bpo-34788

2020-02-04 Thread Sasha Pavlyuk 
Hello

I write the same letter third time with a note of despair. 2019-06-03 I
have created PR https://github.com/python/cpython/pull/13772 , which adds
IPv6 scoped addresses support to ipaddress module.
It is critical to everyone, who is dealing with IPv6  networking. For
example, in salt project they use patched module.
So, it would be very nice to have my changes merged and avoid such a
workarounds.

Pull request stucked at core review stage. Great thanks to @asvetlov, who
began core review, but requested changes remain without review from Dec 9,
2019. Seems, that currently there is no maintainer of ipaddress module.

Here is link to the bug - https://bugs.python.org/issue34788.
PR

Core developers, please, pay attention to this issue.

KR
Oleksandr Pavliuk
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/GTNMBTORUOD2ACQWW4GJAPRNWGKUJ5GE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re-requesting review of bpo-36226

2020-02-04 Thread Christian Schmidbauer 
Hi,

we had issued a PR for bpo-36226 almost a year ago, but the PR [1]
review has been stalling for 4+ months.
Would it be possible to get a new review on this PR?

Thanks!


[1] https://github.com/python/cpython/pull/12214

-- 
This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be 
proprietary, privileged or copyrighted under applicable law. If you are not 
the intended recipient, do not read, copy, or forward this email message or 
any attachments. Delete this email message and any attachments immediately.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/S2PTZHRNECKIB2LMTLZASHXD6BH5ZNKE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-02-04 Thread Mike Miller 


On 2020-02-04 04:16, Rhodri James wrote:
I think that just enables laziness.  "We don't need to worry about the 
deprecations, nothing is going to happen for years yet," is more or less what 
happened with the Python2 to Python3 shift.  People naturally enjoy adding shiny 
new features to their projects over maintenance.


That's an uncharitable interpretation.  Not everyone has the luxury of fixing 
broken code every year.  (New release schedule)  It's not how most of the 
industry works either.



As a refinement to the idea above, perhaps a sub rule could be added:

   - No deprecations should appear in a X.9 release to give folks time
 to prepare.


That feels like a very bad idea indeed.  If you don't tell people things are 
going away, they definitely won't prepare for that.


This point is not suggesting to break things and "not tell anyone."  Rather to 
avoid any compatibility breaks on the ultimate release of a series to give folks 
a minimum of two years to react.


-Mike
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2WSJKFRERIBZPYIADKEJFZTEKLL5D2HS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Issue with PR to ipaddress, core review needed by bpo-34788

2020-02-04 Thread Terry Reedy 

On 2/4/2020 5:02 AM, Sasha Pavlyuk wrote:

I write the same letter third time with a note of despair. 2019-06-03 I 
have created PR https://github.com/python/cpython/pull/13772 , which 
adds IPv6 scoped addresses support to ipaddress module.
It is critical to everyone, who is dealing with IPv6  networking. For 
example, in salt project they use patched module.


Can you get any of the people who need this to review the patch? 
Especially the substance?



Here is link to the bug - https://bugs.python.org/issue34788.


--
Terry Jan Reedy

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JHN2M2TMSRZXQVEBIJT5ZY2VIFABQBE3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-02-04 Thread Mike Miller 


On 2020-02-03 17:00, Brett Cannon wrote:

Until you're being asked to maintain all of that for a decade. We paid a major 
price keeping Python 2 alive for over a decade. Now I'm not saying it wasn't 
the right thing to do considering what we changed, but for the stuff we are 
talking about removing it doesn't require a massive rewrite on the behalf of 
users. And we know from experience anything that is left in will get used no 
matter how loudly we try to broadcast that fact (and we know people still do 
not have a habit of running their code with warnings turned on).


Potentially up to a decade, often not.

We seem to agree that these are most likely minor things like duplicate import 
paths and such.  The maintenance burden is low on these items.  Also, due to 
skittishness, removals have drug out to five plus releases anyway.  So, why the 
aversion to formalizing the process, instead of "winging it" every release?  Why 
force devs/end-users to maintain state about what release is compatible or waste 
time on investigation?


Really, this was solved decades ago.  Everyone knows what to do when a major 
version number changes.  Other language platforms are not afraid to change them, 
likely because the breaks were typically minor and not break-the-world events. 
Just like we're talking about here.


More broadly, an agile cadence is great for innovative apps, not so great for 
mature platforms.  Platforms are supposed to provide stability and 
predictability, and the popular ones do.


-Mike
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/S7JXBK7OA75GVIVHDWOPMLALMCJJKGZN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-02-04 Thread Brett Cannon 
Mike Miller wrote:
> On 2020-02-03 17:00, Brett Cannon wrote:
> > Until you're being asked to maintain all of that for
> > a decade. We paid a major price keeping Python 2 alive for over a decade. 
> > Now I'm not
> > saying it wasn't the right thing to do considering what we changed, but for 
> > the stuff we
> > are talking about removing it doesn't require a massive rewrite on the 
> > behalf of users.
> > And we know from experience anything that is left in will get used no 
> > matter how loudly we
> > try to broadcast that fact (and we know people still do not have a habit of 
> > running their
> > code with warnings turned on).
> > Potentially up to a decade, often not.
> We seem to agree that these are most likely minor things like duplicate 
> import 
> paths and such.  The maintenance burden is low on these items.

Please be careful making that claim. Over my 16 years of helping manage this 
project I can tell you that claim is not universally true no matter how small 
and simple you think something is.

>  Also, due to 
> skittishness, removals have drug out to five plus releases anyway.

That has been due to Python 2 compatibility which is about to no longer be a 
concern. Prior to Python 2 this was not the case.

>  So, why the 
> aversion to formalizing the process, instead of "winging it" every release?

There is work to formalize it in PEP 387. We are just dealing with an odd case 
of Python 2 compatibility which is a one-off situation.

>  Why 
> force devs/end-users to maintain state about what release is compatible or 
> waste 
> time on investigation?
> Really, this was solved decades ago.  Everyone knows what to do when a major 
> version number changes.  Other language platforms are not afraid to change 
> them, 
> likely because the breaks were typically minor and not break-the-world 
> events. 

Python predates semver. Assume every feature/minor release potentially has a 
breaking change and we have (hopefully) been raising warnings to the user for 
the past two years about the breaking change coming.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/SUMQIDIEYI7CTWOLF3EY5CR432NJH7NN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Re-requesting review of bpo-36226

2020-02-04 Thread Terry Reedy 

On 2/4/2020 11:07 AM, Christian Schmidbauer wrote:


we had issued a PR for bpo-36226 almost a year ago, but the PR [1]
review has been stalling for 4+ months.
Would it be possible to get a new review on this PR?

[1] https://github.com/python/cpython/pull/12214


By someone other than the current email maintainer (Abhilash Raj 
maxking) who reviewed it once and has been pinged?  Sorry, but I am 
doubtful.


--
Terry Jan Reedy
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/6W2CTFSRS4LT4KFUFSTRQL6KD4G43WKT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Cassandra-driver acquiring tstate_lock in python3.6/threading.py while doing cluster.connect and got stuck forever

2020-02-04 Thread Terry Reedy 

On 2/4/2020 7:44 AM, pankajkumar--- via Python-Dev wrote:


We are running cassandra using mock cassandra and interacting with python 
cassandra-driver.

[We are having a problem with thread locks.]

Can anyone suggest how can we proceed further?


Python-dev is for development of future versions of Python and future 
CPython releases.


Questions about using current Python/CPython are usually better directed 
elsewhere, such as python-list.


--
Terry Jan Reedy
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/PC4HZTA2BEWWO5OYYFAGRTZ3UBBATTKV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-02-04 Thread Mike Miller 



On 2020-02-04 12:10, Brett Cannon wrote:

Please be careful making that claim. Over my 16 years of helping manage this 
project I can tell you that claim is not universally true no matter how small 
and simple you think something is.


The answer to that concern is to not break compatibility in the first place, 
and/or revert it when the mistake is discovered.  It happens.


As mentioned, significant breaks are now discouraged.  The code is already 
written, so I'd argue keeping it deprecated potentially a few years extra in a 
regular process is not an undue burden.



Python predates semver. Assume every feature/minor release potentially has a 
breaking change and we have (hopefully) been raising warnings to the user for 
the past two years about the breaking change coming.


Hmm, was thinking about MS-DOS when I wrote that.  Still, I don't think this a 
good system having breaking changes in the minor version number.  It's not 
traditional and it's not newfangled either, it's relatively unique.


On that note, just noticed that Wikipedia has its own section for Python under 
the "Software Versioning" article:


The PSF has published PEP 440 -- Version Identification and Dependency
Specification,[16] outlining their own flexible (complicated) scheme, that
defines an epoch segment, a release segment, pre-release and post-release
segments and a development release segment.

https://en.wikipedia.org/wiki/Software_versioning#Python


The main argument here seems to be it this uncommon versioning scheme saves core 
developer time, (unsaid) at the expense of dev or end-user time.  As there are 
probably a million end-users per Python contributor, I argue this is not a good 
tradeoff to make.


-Mike
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/626TBIIMXHVQR4RQK76T4VX622WW5SOE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-02-04 Thread Paul Moore 
On Tue, 4 Feb 2020 at 22:10, Mike Miller  wrote:
>
> On 2020-02-04 12:10, Brett Cannon wrote:
> > Please be careful making that claim. Over my 16 years of helping manage 
> > this project I can tell you that claim is not universally true no matter 
> > how small and simple you think something is.
>
> The answer to that concern is to not break compatibility in the first place,
> and/or revert it when the mistake is discovered.  It happens.

That sounds to me like an argument for stagnation. We already take
backwards compatibility very seriously. If you're suggesting that we
don't even have the option of deprecating things, then I'm not sure
how you expect the language to evolve.

> As mentioned, significant breaks are now discouraged.  The code is already
> written, so I'd argue keeping it deprecated potentially a few years extra in a
> regular process is not an undue burden.

The point has already been made that "keeping code around but
deprecated" isn't the problem, it's bug triage, telling people who
report problems with deprecated code that "this is not going to be
fixed", educating people who copy/paste old and deprecated code and
wonder why they are now getting warnings with it, etc. I think it's
probably up to the core devs (who do the work) to judge what is an
"undue burden", but if you do want to try to judge it, please take all
of those extra tasks into account when reckoning up.

> > Python predates semver. Assume every feature/minor release potentially has 
> > a breaking change and we have (hopefully) been raising warnings to the user 
> > for the past two years about the breaking change coming.
>
> Hmm, was thinking about MS-DOS when I wrote that.  Still, I don't think this a
> good system having breaking changes in the minor version number.  It's not
> traditional and it's not newfangled either, it's relatively unique.

I have seen many systems that have breaking changes in the minor
version, as you describe it. (Java 1.1 to Java 1.4 are a good example
- so good that they "rebranded" the minor version as the major version
with 1.5!). Restricting compatibility breaks to the major version
isn't that important in my experience. IMO, the version number isn't
anywhere near as important as the *process* of handling backward
compatibility and giving users a good transition path. Knowing what
the rules being followed are is the most important thing - and people
trying to claim that semver concepts apply to a system that doesn't
use it, just because the version number syntax looks like semver, is
one of the worst ways to confuse the message IMO.

> On that note, just noticed that Wikipedia has its own section for Python under
> the "Software Versioning" article:
>
>  The PSF has published PEP 440 -- Version Identification and Dependency
>  Specification,[16] outlining their own flexible (complicated) scheme, 
> that
>  defines an epoch segment, a release segment, pre-release and post-release
>  segments and a development release segment.
>
>  https://en.wikipedia.org/wiki/Software_versioning#Python

PEP 440 is not about Python's own version scheme, it's a standard for
versioning Python *packages* that are published on PyPI and managed by
tools like pip. It's complicated because it has to allow for many
different legacy versioning schemes which were in use by existing
projects when the PEP was defined. Ideally we would have chosen a
simpler scheme, but that would have required breaking many existing
projects' version schemes, so we chose not to do that. So it's
actually a great demonstration of how not being able to deprecate old
usages *adds* complexity and maintenance burden.

But it's an irrelevant side issue when talking about the Python
language version itself, as PEP 440 doesn't apply to that.

> The main argument here seems to be it this uncommon versioning scheme saves 
> core
> developer time, (unsaid) at the expense of dev or end-user time.  As there are
> probably a million end-users per Python contributor, I argue this is not a 
> good
> tradeoff to make.

No, it's that conserving the *extremely* limited resource that is
freely donated, volunteer core developer time is essential if we want
to have a viable core development team at all. If in doing so, we need
to have a controlled deprecation process that places some of the
burden of keeping up to date on end users who benefit for no cost from
the huge amount of donated software and support that makes up what
people think of as "Python", then that should be an entirely
acceptable trade-off.

Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/37K2HWAY5LXLF6W2HKUL5T46JBB4DVWQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-02-04 Thread Mike Miller 


On 2020-02-04 14:40, Paul Moore wrote:
>> The answer to that concern is to not break compatibility in the first place,
>> and/or revert it when the mistake is discovered.  It happens.
>
> That sounds to me like an argument for stagnation. We already take
> backwards compatibility very seriously. If you're suggesting that we
> don't even have the option of deprecating things, then I'm not sure
> how you expect the language to evolve.

No, I chose the wrong phrasing there.  Have been arguing for deprecations to 
occur on schedule but removals to occur later.  By "not break compatibility…" I 
meant not to break it in a large, destructive manner.  Small ones, sure.



> The point has already been made that "keeping code around but
> deprecated" isn't the problem, it's bug triage, telling people who
> report problems with deprecated code that "this is not going to be
> fixed", educating people who copy/paste old and deprecated code and
> wonder why they are now getting warnings with it, etc. I think it's
> probably up to the core devs (who do the work) to judge what is an
> "undue burden", but if you do want to try to judge it, please take all
> of those extra tasks into account when reckoning up.

This happens already and won't go away.  I'm arguing that a *very* predictable 
release process helps and doesn't hurt in this department, resulting in fewer 
questions.  Instead of every release is a unique snowflake to be considered. 
Still have questions?  Go to FAQ #42.



> Restricting compatibility breaks to the major version
> isn't that important in my experience. IMO, the version number isn't
> anywhere near as important as the *process* of handling backward

It matters, when say Ubuntu drops X.4 when X.6 comes out and X.6 isn't backwards 
compatible.  You get forced to update or find one of the various workarounds.  I 
argue this should happen less frequently at predictable times.



> No, it's that conserving the *extremely* limited resource that is
> freely donated, volunteer core developer time is essential if we want
> to have a viable core development team at all.


Sorry, didn't mean that part as an attack, rather an illustration of the 
tradeoff being made.  Now if PSF needs help to build a more predictable release 
process, well then, by all means ask.  But that can't happen until the decision 
is made to do it.


-Mike
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/KJPMNIXB3GX6GEOHTXA324DFJBSJFKHO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-02-04 Thread Brandt Bucher 
Steven D'Aprano and I have pushed a third draft of PEP 584:

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

The accompanying reference implementation is on GitHub:

https://github.com/brandtbucher/cpython/tree/addiction

For those who have been following the discussions over the past year on 
python-ideas, this new draft does not contain much additional content; the most 
notable difference is that the choice of operator has been changed from + to |. 
The rest of the revisions are mostly reformatting and reorganizing the 
information to bring the document in line with PEP standards.

Please let us know what you think – we'd love to hear any *new* feedback that 
hasn't yet been addressed in the PEP or the related discussions it links to!

Thanks!

Brandt
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TTIKCDIPC2CDHX23Y57CPHDSVYOWCCER/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-02-04 Thread Guido van Rossum 
Thanks Brandt (and Steven of course)! If there are no objections by next
week I'll recommend this to the Steering Council for acceptance.

In the meantime, I am wondering about the reference implementation -- is it
suitable to submit as a PR? Or is it a toy written in pure Python? (I found
it a little tricky to follow your branch.)

On Tue, Feb 4, 2020 at 4:57 PM Brandt Bucher  wrote:

> Steven D'Aprano and I have pushed a third draft of PEP 584:
>
> https://www.python.org/dev/peps/pep-0584/
>
> The accompanying reference implementation is on GitHub:
>
> https://github.com/brandtbucher/cpython/tree/addiction
>
> For those who have been following the discussions over the past year on
> python-ideas, this new draft does not contain much additional content; the
> most notable difference is that the choice of operator has been changed
> from + to |. The rest of the revisions are mostly reformatting and
> reorganizing the information to bring the document in line with PEP
> standards.
>
> Please let us know what you think – we'd love to hear any *new* feedback
> that hasn't yet been addressed in the PEP or the related discussions it
> links to!
>
> Thanks!
>
> Brandt
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/TTIKCDIPC2CDHX23Y57CPHDSVYOWCCER/
> 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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/NFVVGNXBSABWIPCDH6C3AQA65R37DFPJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

2020-02-04 Thread Brandt Bucher 
It already has a PR open against master, with all tests passing:

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

Sorry about the messy history - this proposal has changed significantly several 
times over the past year (at least as far as the implementation is concerned). 
At one point, both operators were implemented for comparison with each other!
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/6DVUQ45EFTX3G5GF6SOZCYZK62GYFQ7V/
Code of Conduct: http://python.org/psf/codeofconduct/