date:20200124

Le ven. 24 janv. 2020 à 08:37, Miro Hrončok  a écrit :
> No, the motivation to pospone the changes to 3.10 are projects that alrady
> support both 2 and 3 at the same time, with or without compatibility libraries
> like six. Before they had anough time to make the necessary actions to abandon
> Python 2.7, we ask them to support 3.9 from the same code base.

Let me give you an example. The python-ipmi project works on Python
2.7-3.8, but it is not longer compatible with Python 3.9 because
tostring/fromstring methods have been removed from array.array. IMO
this change is a good example to illustrate the issue:
https://github.com/kontron/python-ipmi/pull/73/files

I chose to add py3_array_tobytes() and py3_array_frombytes() functions
rather than adding "if _PY3: ... else: ...". Example:

- self.minor = int(data[1:2].tostring().decode('bcd+'))
+ self.minor = int(py3_array_tobytes(data[1:2]).decode('bcd+'))

This change reminds me when I added "Python 3" support to dozens of
Python projects. You can see in this PR that Python 3.9 currently
requires to modify 9 files in a small project. It is likely to be
worse in a larger project.

With Python 3.9, we cannot simply group all Python 3.x versions under
"Python 3" anymore. Currently, a code compatible with "Python 3" means
more likely compatible with "Python 3.5-3.8" ("Python 3.3-3.8" for the
most conservative projects?).

We kept a compatibility layer with Python 2 on purpose, PEP 4 says:

"In order to facilitate writing code that works in both Python 2 & 3
simultaneously, any module that exists in both Python 3.5 and Python
2.7 will not be removed from the standard library until Python 2.7 is
no longer supported as specified by PEP 373."

The rule was used since Python 3.0 until Python 3.8, but it changed in
Python 3.9 which includes many incompatible changes for the first time
in the Python 3 major version.

Victor



>
>
> from collections import Sequence
>
> With either:
>
> try:
>  from collections.abc import Sequence
> except ImprotError:
>  # Python 2.7 doesn't have collections.abc
>  from collections import Sequence
>
> Or:
>
> from compatlib.moves.collections_abc import Sequence
>
> In both cases, we move the burden of having a compatibility layer of some sort
> from one central location (Python 3.9 stdlib) to dozens (hundreds?) locations.
>
> > For those who have been on 3 for a while,
> > updating to use the newer APIs for 3.9 vs 3.10 shouldn't make a difference.
>
>
> For Python 3 only projects? No, no difference.
>
> > Like-wise for those with 2/3 straddling code bases (we'll just need to add 
> > a few
> > more things to our shims).
>
> And our point is that because it's too early in 2020 to drop Python 2 code, it
> is better to encourage projects to update the code as Python 3 only in a year
> than to let them add more shims now just to hopefully remove them in couple 
> months.
>
> > Anyone who hasn't supported/used Python 3 until now
> > shouldn't have a problem with sticking with 3.8 until they are ready to make
> > more adjustments, and those who have had to keep Python 2 around to run 
> > those
> > applications/frameworks/whatevers will, I should think, be thrilled to use 
> > any
> > Python 3 instead.  :-)
>
> This does not affect projects who don't support Python 3 yet.
>
> --
> 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/TFCAMIAJPCCPGCKC7KIWPCWZIMEWYKI6/
> 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/UAG4EXDRJAJFVQPHVEU5A5WULFSIYRSF/
Code of Conduct: http://python.org/psf/codeofconduct/

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


23.01.20 17:20, Victor Stinner пише:

Incompatible changes which require "if : (...) else: (...)"
or "try:  except (...): ":

* Removed tostring/fromstring methods in array.array and base64 modules
* Removed collections aliases to ABC classes
* Removed fractions.gcd() function (which is similar to math.gcd())
* Remove "U" mode of open(): having to use io.open() just for Python 2
makes the code uglier
* Removed old plistlib API: 2.7 doesn't have the new API


You had years to fix deprecation warnings in your code. And many 
projects did this long ago. If revert these removals in 3.9 because they 
break existing code we will have the same problem with removing them in 
3.10, 13.11, etc.


I consider breaking unmaintained code is an additional benefit of 
removing deprecated features. For example pycrypto was unmaintained and 
insecure for 6 years, but has 4 million downloads per month. It will not 
work in 3.9 because of removing time.clock. Other example is nose, 
unmaintained for 5 years, and superseded by nose2.

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

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

On Fri, Jan 24, 2020 at 7:05 PM Victor Stinner  wrote:
> We kept a compatibility layer with Python 2 on purpose, PEP 4 says:
>
> "In order to facilitate writing code that works in both Python 2 & 3
> simultaneously, any module that exists in both Python 3.5 and Python
> 2.7 will not be removed from the standard library until Python 2.7 is
> no longer supported as specified by PEP 373."
>
> The rule was used since Python 3.0 until Python 3.8, but it changed in
> Python 3.9 which includes many incompatible changes for the first time
> in the Python 3 major version.

I'm sorry, I don't understand what 'changed'. Isn't that rule exactly
WHY 3.9 is the removal point? Python 2.7 is no longer supported, and
its final post-support release is scheduled earlier than 3.9's first
beta and feature freeze. Doesn't that mean that PEP 4 is being
followed precisely? What have I misunderstood?

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

You're right that it's not only about list.count().

IMO it's a good optimization to skip __eq__() when id(x) == id(y). But
it can be surprising, so I just would like to document it somewhere.
For example, in __eq__() method documentation:
https://docs.python.org/dev/reference/datamodel.html#object.__eq

list.count(), list.index(), tuple.count() and tuple.index() all
consider that two elements are equal if id(x) == id(y):

>>> nan=float("nan")
>>> l=[nan]*5
>>> l.count(nan)
5
>>> l.count(nan)
5
>>> l.index(nan)
0
>>> t=(nan,)*5
>>> t.count(nan)
5
>>> t.index(nan)
0

A second NaN object is equal if you consider they bytes content in
memory, but float.__eq__() returns False, and list.count() and
list.index() see them as different (which is the expected behavior):

>>> import struct
>>> nan2=float("nan")
>>> struct.pack(">> nan2 == nan  # float.__eq__(nan2, nan)
False
>>> nan2 is nan
False
>>> l.count(nan2)
0
>>> l.index(nan2)
ValueError: nan is not in list

Python dict also skips __eq__() if id(x) == id(y):

Python 3.9.0a2+ (heads/requires_setenv-dirty:f5cfdf2431, Jan 23 2020, 04:15:01)
>>> nan=float("nan")
>>> d={nan: "not a number"}
>>> d[nan]
'not a number'

Another dict example:

>>> class NotEq:
...   def __eq__(self, other): return False
...   def __hash__(self): return 3
...
>>> key=NotEq()
>>> d2={key: 'not equal'}
>>> d2[key]
'not equal'

Python set also skips __eq_():

>>> s={key}
>>> key in s
True

Victor

Le ven. 24 janv. 2020 à 02:37, Tim Peters  a écrit :
>
> PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut:  if x
> and y are the same object, then equality comparison returns True and
> inequality False.  No attempt is made to execute __eq__ or __ne__
> methods in those cases.
>
> This has visible consequences all over the place, but they don't
> appear to be documented.  For example,
>
> >>> import math
> >>> ([math.nan] * 5).count(math.nan)
> 5
>
> despite that `math.nan == math.nan` is False.
>
> It's usually clear which methods will be called, and when, but not
> really here.  Any _context_ that calls PyObject_RichCompareBool()
> under the covers, for an equality or inequality test, may or may not
> invoke __eq__ or __ne__, depending on whether the comparands are the
> same object.  Also any context that inlines these special cases to
> avoid the overhead of calling PyObject_RichCompareBool() at all.
>
> If it's intended that Python-the-language requires this, that needs to
> be documented.
>
> Or if it's implementation-defined, then _that_ needs to be documented.
>
> Which isn't straightforward in either case, in part because
> PyObject_RichCompareBool isn't a language-level concept.
>
> This came up recently when someone _noticed_ the list.count(NaN)
> behavior, and Victor made a PR to document it:
>
> https://github.com/python/cpython/pull/18130
>
> I'm pushing back, because documenting it _only_ for .count() makes
> .count() seem unique in a way it isn't, and doesn't resolve the
> fundamental issue:  is this language behavior, or implementation
> behavior?
>
> Which I don't want to argue about.  But you certainly should ;-)
> ___
> 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/3ZAMS473HGHSI64XB3UV4XBICTG2DKVF/
> 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/N45H65U7OJQH2ESX3CI4AXZI6PBI5TNB/
Code of Conduct: http://python.org/psf/codeofconduct/

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


24.01.20 01:36, Barry Warsaw пише:

Given that we’ve changed the release cadence to one major release per year, it 
doesn’t seem that much of a burden to revert and carry these changes forward 
into Python 3.10.  And if it helps with the migration off of Python 2.7, then 
+1 from me.


There are enough breaking changes planned in 3.10. Even changing the 
minor version number to two-digit is a large breaking change.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?


24.01.20 03:29, Tim Peters пише:

If it's intended that Python-the-language requires this, that needs to
be documented.


I think it is already documented somewhere. Even Python implementations 
like collections.abc.Sequence and collections.abc.Mapping were changed 
to use `x is y or x == y` instead of just `x == y` few versions ago. So 
this is not just CPython implementation detail.

___
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/26J226MOIJF7ULAWC2WGSSMX5KWR2J37/
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-01-24 Thread Ivan Pozdeev via Python-Dev



On 24.01.2020 11:08, Serhiy Storchaka wrote:

23.01.20 17:20, Victor Stinner пише:

Incompatible changes which require "if : (...) else: (...)"
or "try:  except (...): ":

* Removed tostring/fromstring methods in array.array and base64 modules
* Removed collections aliases to ABC classes
* Removed fractions.gcd() function (which is similar to math.gcd())
* Remove "U" mode of open(): having to use io.open() just for Python 2
makes the code uglier
* Removed old plistlib API: 2.7 doesn't have the new API


You had years to fix deprecation warnings in your code. And many projects did this long ago. If revert these removals in 3.9 because they 
break existing code we will have the same problem with removing them in 3.10, 13.11, etc.


I consider breaking unmaintained code is an additional benefit of removing deprecated features. For example pycrypto was unmaintained and 
insecure for 6 years, but has 4 million downloads per month. It will not work in 3.9 because of removing time.clock. Other example is 
nose, unmaintained for 5 years, and superseded by nose2.


AFAICS the justification for this proposition is the fact that the necessary fixes to existing code are much simpler if that code needs to 
support just 3.x-3.10 vs 2.7+3.x-3.10 .


In this light, with the breaking changes, we essentially tell the users: "abandon 
2.7 or do extra work".
Victor alleges that after a year, the option to abandon 2.7 and not do that 
extra work will be easier to choose.
So the dilemma is essentially how hard we push users to abandon 2.7 -- how much 
tax we incur on them for keeping its support.


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


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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

Le ven. 24 janv. 2020 à 03:37, Guido van Rossum  a écrit :
> I think this started with a valuable optimization for `x in `. I don't 
> know if that was ever carefully documented, but I remember that it was 
> discussed a few times (and IIRC Raymond was adamant that this should be so 
> optimized -- which is reasonable).
>
> I'm tempted to declare this implementation-defined behavior -- *implicit* 
> calls to __eq__ and __ne__ *may* be skipped if both sides are the same object 
> depending on the whim of the implementation.

CPython current behavior rely on the fact that it's possible to get
the memory address of an object. I don't think that it should be part
of Python language specification, but seen as a CPython implementation
detail.

--

In PyPy, you may or may not have an "object". It depends how PyPy
decides to store values. For example, if a list only contains small
integers: PyPy uses a list specialized for integers and store
integers, not objects which stores integers. The JIT compiler can also
emit machine codes which uses directly CPU registers to store
integers: again, objects don't exist in memory.

The interesting part is that PyPy managed somehow to mimick CPython
small integer singletons :-)

 x=1
 y=2-1
 y is x
True
 id(x), id(y)
(17L, 17L)

--

Another example: there is new implementation of Python called "Snek"
which is based on 32-bit snek_poly_t type. It is designed for devices
with 2K of memory:

https://keithp.com/snek/
https://lwn.net/Articles/810201/

The implementation uses the following structure for objects:

typedef union {
 uint32_t u;
float f;
} snek_poly_t;

It's just 32-bit. At the C level, objects are not passed by references
(pointers), but by "value": copy 32-bit value to pass them as function
arguments, to copy the function result, etc.

So it's not possible to get an object address, since there is no
"object" just its value :-)

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

2020-01-24 Thread Inada Naoki

On Fri, Jan 24, 2020 at 5:24 PM Victor Stinner  wrote:
>
> You're right that it's not only about list.count().
>
> list.count(), list.index(), tuple.count() and tuple.index() all
> consider that two elements are equal if id(x) == id(y):
>

FWIW, (list|tuple).__eq__ and (list|tuple).__contains__ uses it too.
It is very important to compare recursive sequences.

>>> x = []
>>> x.append(x)
>>> y = [x]
>>> z = [x]
>>> y == z
True

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

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

The change is that Python 2.7 is no longer supported (since 2020-01-01).

Victor

Le ven. 24 janv. 2020 à 09:19, Chris Angelico  a écrit :
>
> On Fri, Jan 24, 2020 at 7:05 PM Victor Stinner  wrote:
> > We kept a compatibility layer with Python 2 on purpose, PEP 4 says:
> >
> > "In order to facilitate writing code that works in both Python 2 & 3
> > simultaneously, any module that exists in both Python 3.5 and Python
> > 2.7 will not be removed from the standard library until Python 2.7 is
> > no longer supported as specified by PEP 373."
> >
> > The rule was used since Python 3.0 until Python 3.8, but it changed in
> > Python 3.9 which includes many incompatible changes for the first time
> > in the Python 3 major version.
>
> I'm sorry, I don't understand what 'changed'. Isn't that rule exactly
> WHY 3.9 is the removal point? Python 2.7 is no longer supported, and
> its final post-support release is scheduled earlier than 3.9's first
> beta and feature freeze. Doesn't that mean that PEP 4 is being
> followed precisely? What have I misunderstood?
>
> 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/GCCLU2O2QJTGECQKUYEHD2KVD3IKJTLE/
> 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/6YLZXTOJJ7XGISGRITJV7OAEOEKFYZS7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

On Fri, Jan 24, 2020 at 7:40 PM Victor Stinner  wrote:
>
> The change is that Python 2.7 is no longer supported (since 2020-01-01).
>

Which means that it's now okay to remove things, correct? Starting
with 3.9, it's no longer necessary to maintain compatibility with 2.7?

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?


24.01.20 10:29, Serhiy Storchaka пише:
Even Python implementations 
like collections.abc.Sequence and collections.abc.Mapping were changed 
to use `x is y or x == y` instead of just `x == y` few versions ago.


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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, 24 Jan 2020 at 02:36, Guido van Rossum  wrote:

> I'm tempted to declare this implementation-defined behavior -- *implicit* 
> calls to __eq__ and __ne__ *may* be skipped if both sides are the same object 
> depending on the whim of the implementation.

This sounds reasonable to me. It could be added to
https://docs.python.org/3/reference/expressions.html#value-comparisons

"""
The default behavior for equality comparison (== and !=) is based on
the identity of the objects. Hence, equality comparison of instances
with the same identity results in equality, and equality comparison of
instances with different identities results in inequality. A
motivation for this default behavior is the desire that all objects
should be reflexive (i.e. x is y implies x == y).
"""

We could add an extra clause here: """As an optimisation, when the
implementation *implicitly* compares two values for equality (for
example, in list comparison or `list.count`) it is allowed (but not
required) to omit the equality check if the objects being compared are
the same. This can result in different behaviour for objects with
user-defined equality that is not reflexive - that is acceptable."""

> We should probably also strongly recommend that __eq__ and __ne__ not do what 
> math.nan does.

>From https://docs.python.org/3/reference/expressions.html#comparisons

"""
User-defined classes that customize their comparison behavior should
follow some consistency rules, if possible:

Equality comparison should be reflexive. In other words, identical
objects should compare equal:

x is y implies x == y
"""

and also

"""
Python does not enforce these consistency rules. In fact, the
not-a-number values are an example for not following these rules.
"""

So that's covered already :-)

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

2020-01-24 Thread Ivan Pozdeev via Python-Dev

On 24.01.2020 5:36, Guido van Rossum wrote:

Good question!

I think this started with a valuable optimization for `x in `. I don't know if that was ever carefully documented, but I remember 
that it was discussed a few times (and IIRC Raymond was adamant that this should be so optimized -- which is reasonable).

I'm tempted to declare this implementation-defined behavior -- *implicit* calls to __eq__ and __ne__ *may* be skipped if both sides are 
the same object depending on the whim of the implementation.

This cannot be an implementation detail because it changes the outcome of 
operations.
Without it, things like `math.nan in seq` would always return False.
So it's not even an "optimization" but rather "behavior".

IMO a user should not rely on __eq__ to be called at any time so we shouldn't 
document that it could be skipped or whatever.

Instead, we should document that `in` (and whatever other public API uses PyObject_RichCompareBool) compares by identity first (and this is 
intended because `math.nan in seq` returning True if there are NaNs is more practical in the general case).

We should probably also strongly recommend that __eq__ and __ne__ not do what 
math.nan does.

However we cannot stop rich compare __eq__ implementations that return arrays of pairwise comparisons, since numpy does this. (And yes, it 
seems that this means that `x in y` is computed incorrectly if x is an array with such an __eq__ implementation and y is a tuple of such 
objects. I'm sure there's a big warning somewhere in the numpy docs about this, and I presume if y is a numpy array they make sure to do 
something better.)

On Thu, Jan 23, 2020 at 5:33 PM Tim Peters mailto:tim.pet...@gmail.com>> wrote:

PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut:  if x
and y are the same object, then equality comparison returns True and
inequality False.  No attempt is made to execute __eq__ or __ne__
methods in those cases.

This has visible consequences all over the place, but they don't
appear to be documented.  For example,

>>> import math
>>> ([math.nan] * 5).count(math.nan)
5

despite that `math.nan == math.nan` is False.

It's usually clear which methods will be called, and when, but not
really here.  Any _context_ that calls PyObject_RichCompareBool()
under the covers, for an equality or inequality test, may or may not
invoke __eq__ or __ne__, depending on whether the comparands are the
same object.  Also any context that inlines these special cases to
avoid the overhead of calling PyObject_RichCompareBool() at all.

If it's intended that Python-the-language requires this, that needs to
be documented.

Or if it's implementation-defined, then _that_ needs to be documented.

Which isn't straightforward in either case, in part because
PyObject_RichCompareBool isn't a language-level concept.

This came up recently when someone _noticed_ the list.count(NaN)
behavior, and Victor made a PR to document it:

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

I'm pushing back, because documenting it _only_ for .count() makes
.count() seem unique in a way it isn't, and doesn't resolve the
fundamental issue:  is this language behavior, or implementation
behavior?

Which I don't want to argue about.  But you certainly should ;-)
___
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/3ZAMS473HGHSI64XB3UV4XBICTG2DKVF/
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/X4ZIICG2EBMYPFUASI5TW4E6PIT2KR6M/
Code of Conduct: http://python.org/psf/codeofconduct/

--
Regards,
Ivan

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

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

On Fri, 24 Jan 2020 at 08:54, Victor Stinner  wrote:
>
> The change is that Python 2.7 is no longer supported (since 2020-01-01).

However the assertion here seems to be that some people are unprepared
for this (which seems to me like it's their problem, not ours).
Features getting deprecated in newer Python versions is routine.
Anyone maintaining Python 2.7 compatibility should already be
painfully aware that we're deprecating things in 3.x and they have to
maintain compatibity code for that. We've been minimising the impact
for such people as much as we can for years. When *should* we stop
doing so, if not at the point where we finally declared 2.7
unsupported?

Having said that, the 5 specific changes noted seem relatively minor
and deferring them an extra release doesn't seem like a massive deal.
My objection is only if we try to extrapolate a general principle from
those specific examples.

Paul

P.S.

> I'm not sure of the meaning of "buried" here. What do you mean? We propose to 
> revert 5 changes:
[...]
> It's not only about specific changes, but more a discussion about a general 
> policy to decide if a deprecated feature should stay until 3.10, or if it's 
> ok to remove it in 3.9.

I agree with Brett, it was hard to understand your message. And I
think the problem was that you tried to discuss both the *specific*
proposal to delay 5 deprecations, and the *general* principle of when
we stop preserving 2.7 compatibility layers. These two are very
different questions and (as I say above) don't necessarily have the
same answer.

I think you should have posted *two* messages. The first very focused
on the 5 deprecations, and the second, following on, saying something
along the lines of "the previous message raises a broader question of
how long we should carry 2.7 compatibility code before removing it -
what do people think?". That would separate the general from the
specific, while not flooding the list with separate threads for each
deprecation (which I assume wasn't a serious suggestion on your part).
___
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/BLDYTQAHHIA6DLZZBQSW3E7WJVKLRP5W/
Code of Conduct: http://python.org/psf/codeofconduct/

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

Adding Python 3.9 and dropping Python 2.7 support are two different
things, but Python 3.9 somehow "enforces" to do both at the same time.

The proposal is to give one year to project maintainers to drop Python
2.7 support, since Python 2.7 end of support just happened a few weeks
ago (2020-01-01).

Big projects have more resources to schedule dropping Python 2
support, coordinated with other projects:
https://python3statement.org/

But for smaller projects with less resources, it's more complicated.
Many very popular Python modules are maintained by a single person
with limited resources. Even if we propose pull requests, it still
takes time to review it, prepare a new release, etc.

Victor

Le ven. 24 janv. 2020 à 09:42, Chris Angelico  a écrit :
> On Fri, Jan 24, 2020 at 7:40 PM Victor Stinner  wrote:
> >
> > The change is that Python 2.7 is no longer supported (since 2020-01-01).
> >
>
> Which means that it's now okay to remove things, correct? Starting
> with 3.9, it's no longer necessary to maintain compatibility with 2.7?
>
> ChrisA

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 3:12 AM, Victor Stinner wrote:

IMO it's a good optimization to skip __eq__() when id(x) == id(y).

From a higher level viewpoint, what is being skipped is literally doing
'x == y'.

But
it can be surprising, so I just would like to document it somewhere.

It is, in the section on how to understand and use value comparison
*operators* ('==', etc.).

https://docs.python.org/3/reference/expressions.html#value-comparisons

First "The default behavior for equality comparison (== and !=) is based
on the identity of the objects."

Then in particular, "The built-in containers typically assume identical
objects are equal to themselves. That lets them bypass equality tests
for identical objects to improve performance and to maintain their
internal invariants."

For example, in __eq__() method documentation:
https://docs.python.org/dev/reference/datamodel.html#object.__eq

The text that follows discusses rich comparison *special methods* and
how to write them. It should refer people to the value-comparisons
section for information on specific classes, as in the second quote
above. It would not hurt if the operator section referred people back
to special method discussion. I think you should go ahead and add one
or both links.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Thu, Jan 23, 2020 at 07:29:58PM -0600, Tim Peters wrote:
> PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut:  if x
> and y are the same object, then equality comparison returns True and
> inequality False.  No attempt is made to execute __eq__ or __ne__
> methods in those cases.
> 
> This has visible consequences all over the place, but they don't
> appear to be documented.

This has definitely been discussed before. Here's one such thread:

https://mail.python.org/pipermail/python-dev/2011-April/110945.html

My recollection is that we reached a consensus that collections in 
general don't have to obey the invariant that `x != x` when x is a NAN. 
But I don't recall seeing it documented outside of the mailing lists. By 
my recollections, this has come up, oh, at least four times now, so 
perhaps there should be a FAQ answering why NAN != NAN except inside 
collections.

-- 
Steven
___
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/2RGSEKNYWZXI52YZ6RNIEYAXNIWSRHWU/
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-01-24 Thread Ivan Levkivskyi

On Fri, 24 Jan 2020 at 10:05, Victor Stinner  wrote:

>
> The proposal is to give one year to project maintainers to drop Python
> 2.7 support, since Python 2.7 end of support just happened a few weeks
> ago (2020-01-01).
>

IMO creating this kind of "gray areas" in support and deprecation issues is
bad.
What this will create is just more sources for arguing/debates. Once
deprecation or EoL schedule is set,
it is best to align to it. Discussions about the schedules should happen
when setting them, not when
the deadline is coming.

Also I am not sure it is really worth it. For example, importing ABCs
directly from collections was deprecated 8 years ago,
what would 1 extra year change?

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 3:36 AM, Victor Stinner wrote:

Le ven. 24 janv. 2020 à 03:37, Guido van Rossum a écrit :

I think this started with a valuable optimization for `x in `. I don't
know if that was ever carefully documented, but I remember that it was discussed a
few times (and IIRC Raymond was adamant that this should be so optimized -- which is
reasonable).

I'm tempted to declare this implementation-defined behavior -- *implicit* calls
to __eq__ and __ne__ *may* be skipped if both sides are the same object
depending on the whim of the implementation.

I think you are looking at too low a level. The container behavior
being discussed, of assuming that "identical objects are equal to
themselves"*, can be described in Python as testing equality of x and y
with "(x is y) or (x == y)"

* https://docs.python.org/3/reference/expressions.html#comparisons

CPython current behavior rely on the fact that it's possible to get
the memory address of an object.

No, this behavior relies on the language specification that all objects
have temporally unique integer ids that can be compared with 'is'.

I don't think that it should be part of Python language specification,
but seen as a CPython implementation detail.

Ids are a language feature; ids being addresses is a CPython detail, but
this detail is not relevant to equality comparison of items within
containers.

In PyPy, you may or may not have an "object". It depends how PyPy
decides to store values. For example, if a list only contains small
integers: PyPy uses a list specialized for integers and store
integers, not objects which stores integers.

Such lists are like strings, which also store small int values. Any
such container can pretend, in the current context, that id(n) is n so
that 'm is n' and 'm == n' are the same and only need to be computed once.

--
Terry Jan Reedy

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

[Python-Dev] Re: SWIFT Confirmation and request for Updated Statement for DEC invoice

2020-01-24 Thread ron



Sir,

Please note that and we are Transferring payment again to your 
Designated bank As advised earlier.


Kindly see attached covering letter with Bank Swift for follow up with 
your bank.


Also see below specification Of payment breakdown.

USD 3,146.05
USD 28,550.00


Please kindly confirm the attached swifts and Send Updated Statement of 
Account for our records Purpose.



Regards

Brian Alex
Head Of Finance
Treasury Department.
Address: ul. 327 Abdrakhmanova (Bayalinov lane)
+996 312 37 67 70

BANK SWIFT COPY.arj
Description: Zip archive
___
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/QTY2ALCZ3QX72BOLV3IWELDEXGLT4YUI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?


On 1/24/2020 4:23 AM, Paul Moore wrote:

On Fri, 24 Jan 2020 at 02:36, Guido van Rossum  wrote:


I'm tempted to declare this implementation-defined behavior -- *implicit* calls 
to __eq__ and __ne__ *may* be skipped if both sides are the same object 
depending on the whim of the implementation.


This sounds reasonable to me. It could be added to
https://docs.python.org/3/reference/expressions.html#value-comparisons

"""
The default behavior for equality comparison (== and !=) is based on
the identity of the objects. Hence, equality comparison of instances
with the same identity results in equality, and equality comparison of
instances with different identities results in inequality. A
motivation for this default behavior is the desire that all objects
should be reflexive (i.e. x is y implies x == y).
"""

We could add an extra clause here: """As an optimisation, when the
implementation *implicitly* compares two values for equality (for
example, in list comparison or `list.count`) it is allowed (but not
required) to omit the equality check if the objects being compared are
the same. This can result in different behaviour for objects with
user-defined equality that is not reflexive - that is acceptable."""


This is an expanded version of what already exists further down, under 
sequences.


" The built-in containers typically assume identical objects are equal 
to themselves. That lets them bypass equality tests for identical 
objects to improve performance and to maintain their internal invariants."


This was added last August, after careful consideration, by myself and 
Raymond, as a beginner friendly replacement of 17 lines, that says what 
users actually need to know.


https://bugs.python.org/issue32118
https://github.com/python/cpython/pull/15450
--
Terry Jan Reedy
___
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/2DT33KDNHPPQP2IMJLY26VMISNOIPM3M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 12:36:13PM +0300, Ivan Pozdeev via Python-Dev wrote:

> >I'm tempted to declare this implementation-defined behavior -- *implicit* 
> >calls to __eq__ and __ne__ *may* be skipped if both sides are the same 
> >object depending on the whim of the implementation.
> 
> This cannot be an implementation detail because it changes the outcome of 
> operations.

Guido didn't call it an implementation *detail* but implementation- 
defined behaviour. And of course that implies that the outcome could be 
different when using different implementations.

I'm pretty sure Guido understood the implication when he made that 
comment.

The only thing I'm unsure of here is whether direct use of the `==` and 
`!=` operators are included as "implicit calls" to the dunders. I 
*think* I understand Guido's intention, but I'm not sure:

* x == y MUST call `__eq__`

* likewise x != y MUST call `__ne__`

* but compound objects such as lists and other collections MAY skip 
  calling `__eq__` (or `__eq__`) on their component parts.

> Without it, things like `math.nan in seq` would always return False.

There are other float NANs apart from math.nan.

If my arithmetic is correct, there are 9007199254740990 distinct float 
NANs, or 0.05% of the 64-bit space. 4503599627370496 of those are quiet 
NANs, and 4503599627370494 are signalling NANs.

In order words, even if you have

assert any(math.isnan(x) for x in values)

that does not mean that

math.nan in values

*should*, let alone *will*, return True.

> So it's not even an "optimization" but rather "behavior".

It is both. It is an optimization which also have an observable change 
in behaviour.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano  wrote:
>
> The only thing I'm unsure of here is whether direct use of the `==` and
> `!=` operators are included as "implicit calls" to the dunders. I
> *think* I understand Guido's intention, but I'm not sure:
>
> * x == y MUST call `__eq__`
>
> * likewise x != y MUST call `__ne__`
>
> * but compound objects such as lists and other collections MAY skip
>   calling `__eq__` (or `__eq__`) on their component parts.
>

Are there any non-container uses where this comes up? Can the rule be
codified simply as that container membership, in all core/stdlib
types, is defined by "x is y or x == y"?

(And possibly some additional words regarding recursive equality, if
that isn't considered to be an extension of "membership".)

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote:
> On 1/24/2020 3:36 AM, Victor Stinner wrote:

> >CPython current behavior rely on the fact that it's possible to get
> >the memory address of an object.
> 
> No, this behavior relies on the language specification that all objects 
> have temporally unique integer ids that can be compared with 'is'.
> 
> >I don't think that it should be part of Python language specification,
> >but seen as a CPython implementation detail.
> 
> Ids are a language feature; ids being addresses is a CPython detail, but 
> this detail is not relevant to equality comparison of items within 
> containers.

Thanks Terry for raising this. Of course CPython can optimize identity 
tests by checking for the same memory address, and *memory address* is 
an implementation-detail of object identity.

Any Python implementation ought to have a sense of object identity, 
however it is implemented or emulated. For instance, both Java and .Net 
have compacting memory models, which means objects can move around in 
memory and there's no well-defined "memory address", but both have to be 
able to implement the `is` operator:

* Java has the `==` operator;
* .Net, or at least C#, has Object.ReferenceEquals

If there happens to be a Python interpreter where testing object 
identity is expensive, then they should be free to *not* bypass the 
equality test.

Victor:
> >In PyPy, you may or may not have an "object". It depends how PyPy
> >decides to store values. For example, if a list only contains small
> >integers: PyPy uses a list specialized for integers and store
> >integers, not objects which stores integers.

I believe that PyPy nevertheless offers the illusion that such lists 
contain objects, complete with IDs. They even manage to keep the ID 
consistent across copies. For example:

 L = [99]
 id(L[0])
1585
 id(L[:][0])
1585

so even if the list is implemented as an array of native integers rather 
than int objects, as far as Python code is concerned there is no 
behavioural difference.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?


24.01.20 13:57, Chris Angelico пише:

Are there any non-container uses where this comes up? Can the rule be
codified simply as that container membership, in all core/stdlib
types, is defined by "x is y or x == y"?


Also a membership test for iterators (which is already explicitly 
documented).


   >>> math.nan in (math.nan for i in [1])
   True
___
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/VNFHDFCNNIV2DHWLWVKLJNXGF55NNC3G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 10:57:11PM +1100, Chris Angelico wrote:
> On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano  wrote:
> >
> > The only thing I'm unsure of here is whether direct use of the `==` and
> > `!=` operators are included as "implicit calls" to the dunders. I
> > *think* I understand Guido's intention, but I'm not sure:
> >
> > * x == y MUST call `__eq__`
> >
> > * likewise x != y MUST call `__ne__`

Oh, that's too strong. The interpreter ought to be allowed to bypass the 
method call if it is knows that reflexivity certainly holds.

Obviously it can't know that in the general case of two arbitrary 
objects, but if the interpreter knows that both objects are a built-in 
type (not a subclass) apart from float, then it *might* choose to test 
for identity.

In other words, atomic objects MUST NOT *assume* reflexivity[1] of 
arbitrary types, but MAY take advantage of reflexivity of specific known 
types.

(E.g. ints don't have NANs, so there's no harm in allowing the 
interpreter to skip the method call if it knows both operands are actual 
built-in ints.)

> > * but compound objects such as lists and other collections MAY skip
> >   calling `__eq__` (or `__eq__`) on their component parts.

Whereas compound objects MAY assume reflexivity of their component 
parts.

> Are there any non-container uses where this comes up?

"Container" is an ABC, whereas I'm being more general and talking about 
any compound object that might wish to short-cut long, possibly 
recursive equality tests.

For instance, SimpleNamespace supports equality:

x = SimpleNamespace(a=1, b=2)
y = SimpleNamespace(a=1, b=2)
x == y  # returns True

Testing for equality of the values can be as expensive as you want. But 
`SimpleNamespace.__eq__` should be entitled to assume that:

- if both operands are the same SimpleNamespace object, they are equal;

- for any name binding in the Simplenamespace (like a=1 or b=2),
  if the values in the two operands are the same object, the values
  are also equal (i.e. equality is reflexive).

> Can the rule be
> codified simply as that container membership, in all core/stdlib
> types, is defined by "x is y or x == y"?

I can't personally think of any other optimization that is likely to 
work. But if somebody did think of one, shouldn't they be entitled to 
use it?

[1] Reflexivity of an operator (e.g. equality) means that x == x for any 
value of x.

-- 
Steven
___
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/7NMEKJQDNGRWI3CR24Q5GK63JBXJRSGM/
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-01-24 Thread Eric V. Smith


On 1/24/2020 5:50 AM, Ivan Levkivskyi wrote:
On Fri, 24 Jan 2020 at 10:05, Victor Stinner > wrote:



The proposal is to give one year to project maintainers to drop Python
2.7 support, since Python 2.7 end of support just happened a few weeks
ago (2020-01-01).


IMO creating this kind of "gray areas" in support and deprecation 
issues is bad.
What this will create is just more sources for arguing/debates. Once 
deprecation or EoL schedule is set,
it is best to align to it. Discussions about the schedules should 
happen when setting them, not when

the deadline is coming.

Also I am not sure it is really worth it. For example, importing ABCs 
directly from collections was deprecated 8 years ago,

what would 1 extra year change?

I think the concern is that with removing so many deprecated features, 
we're effectively telling libraries that if they want to support 3.9, 
they'll have stop supporting 2.7. And many library authors aren't 
willing to do that yet. Will they be willing to in another year? I can't 
say.


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/DKZBXOYUPJCL3PUXWDJOJUEPG4WDYNF7/
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-01-24 Thread Miro Hrončok

On 24. 01. 20 14:02, Eric V. Smith wrote:

On 1/24/2020 5:50 AM, Ivan Levkivskyi wrote:
On Fri, 24 Jan 2020 at 10:05, Victor Stinner > wrote:

The proposal is to give one year to project maintainers to drop Python
2.7 support, since Python 2.7 end of support just happened a few weeks
ago (2020-01-01).

IMO creating this kind of "gray areas" in support and deprecation issues is bad.
What this will create is just more sources for arguing/debates. Once
deprecation or EoL schedule is set,
it is best to align to it. Discussions about the schedules should happen when
setting them, not when

the deadline is coming.

Also I am not sure it is really worth it. For example, importing ABCs directly
from collections was deprecated 8 years ago,

what would 1 extra year change?

I think the concern is that with removing so many deprecated features, we're
effectively telling libraries that if they want to support 3.9, they'll have
stop supporting 2.7. And many library authors aren't willing to do that yet.
Will they be willing to in another year? I can't say.

The concern is not that they don't want to drop 2.7 support, but that is is a
nontrivail task to actaually do and we cannot expect them to do it within the
first couple weeks of 2020. While at the same time, we want them to support 3.9
since the early development versisons in order to eb able to detect regressions
early in the dev cycle.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, 24 Jan 2020 at 11:15, Terry Reedy  wrote:
>
> On 1/24/2020 4:23 AM, Paul Moore wrote:
> > We could add an extra clause here: """As an optimisation, when the
> > implementation *implicitly* compares two values for equality (for
> > example, in list comparison or `list.count`) it is allowed (but not
> > required) to omit the equality check if the objects being compared are
> > the same. This can result in different behaviour for objects with
> > user-defined equality that is not reflexive - that is acceptable."""
>
> This is an expanded version of what already exists further down, under
> sequences.
>
> " The built-in containers typically assume identical objects are equal
> to themselves. That lets them bypass equality tests for identical
> objects to improve performance and to maintain their internal invariants."
>
> This was added last August, after careful consideration, by myself and
> Raymond, as a beginner friendly replacement of 17 lines, that says what
> users actually need to know.

Yes that's a lot better than my wording (no surprise, you put a lot of
thought into it whereas I dashed off a suggestion in a few minutes
:-))

I do wonder what to make of the fact that in spite of reading that
section specifically because this question was raised, I still missed
it. The whole section is information that's rarely needed in normal
use, but explains the corner cases and specifics in detail (and does
so well - the whole section is nice to read, not just the bit you
quoted). There's just a lot to say, and it's easy to miss bits as you
skim.

Maybe all we need to take from this is that it's already documented,
but there's always going to be an issue of how to ensure people can
find the details they need.

Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RM4MH6NWUB3W2STDQM3ZHCUNM3O572I5/
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-01-24 Thread Eric V. Smith

On 1/24/2020 9:14 AM, Miro Hrončok wrote:

On 24. 01. 20 14:02, Eric V. Smith wrote:
I think the concern is that with removing so many deprecated
features, we're effectively telling libraries that if they want to
support 3.9, they'll have stop supporting 2.7. And many library
authors aren't willing to do that yet. Will they be willing to in
another year? I can't say.

The concern is not that they don't want to drop 2.7 support, but that
is is a nontrivail task to actaually do and we cannot expect them to
do it within the first couple weeks of 2020. While at the same time,
we want them to support 3.9 since the early development versisons in
order to eb able to detect regressions early in the dev cycle.

Ah. So in 3.8, they kept code that had deprecation warnings so that they
could be compatible with 2.7. They'd like to now drop that code and be
3.9-only compatible, but they don't have enough time to do that because
they couldn't start that work as long as they were supporting 2.7. Do I
have that right?

If so, I'd be okay with postponing the removal of the deprecated code
until 3.10. But I don't think we should postpone it if the driver is so
that libraries can remain 2.7 compatible. That could go on forever. This
postponement would be a one-time thing.

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

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

On Fri, 24 Jan 2020 at 14:14, Miro Hrončok  wrote:
>
> On 24. 01. 20 14:02, Eric V. Smith wrote:
> > I think the concern is that with removing so many deprecated features, we're
> > effectively telling libraries that if they want to support 3.9, they'll have
> > stop supporting 2.7. And many library authors aren't willing to do that yet.
> > Will they be willing to in another year? I can't say.
>
> The concern is not that they don't want to drop 2.7 support, but that is is a
> nontrivail task to actaually do and we cannot expect them to do it within the
> first couple weeks of 2020. While at the same time, we want them to support 
> 3.9
> since the early development versisons in order to eb able to detect 
> regressions
> early in the dev cycle.

But couldn't they have done that by adding the compatibility shims
Victor described. Sure, they are messy, and sure, it would be more
convenient not to have to. But the various dates have been known for
some time now. Unless you're saying that the change to a yearly
schedule for 3.9 has suddenly compressed timescales to an extent that
projects can't cope with.

So maybe there is a reason why people might legitimately have an issue
here. Having said that, I think that far more people will see this as
yet another delay before 2.7 dies, and treat it as one more reason to
do nothing. So I still have reservations.

I have already said that the 5 deprecations Victor described seem
minor enough that one release's delay is not a big deal. If that's
enough for the people hit by the shorter 3.9 cycle, then great. But it
should *not* set a precedent that we're willing to repeatedly have
this sort of discussion. It should be a one-off, and definitely not
set the scene for a series of "and can this one be added as well"
requests.

I assume it's obvious that 3.10 would be a hard deadline, as well.
There's no justification for deferring deprecations past then.

Paul

PS As a pip developer, I fully expect to be supporting Python 2.7 for
a while yet. So I'm not talking from a perspective of someone who has
happily dropped Python 2 support and doesn't understand the issues.
But I don't expect *Python* to maintain my compatibility for me, and I
don't see why others should, either. And yes, that does include these
5.
___
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/V5P5FSNA5QMP3P4VIFG3774JXE2PJ2P4/
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-01-24 Thread Ethan Furman


On 01/24/2020 05:02 AM, Eric V. Smith wrote:

On 1/24/2020 5:50 AM, Ivan Levkivskyi wrote:

On Fri, 24 Jan 2020 at 10:05, Victor Stinner wrote:



The proposal is to give one year to project maintainers to drop Python
2.7 support, since Python 2.7 end of support just happened a few weeks
ago (2020-01-01).


Also I am not sure it is really worth it. For example, importing ABCs directly 
from collections was deprecated 8 years ago,
what would 1 extra year change?


I think the concern is that with removing so many deprecated features, we're 
effectively telling libraries that if they want to support 3.9, they'll have 
stop supporting 2.7. And many library authors aren't willing to do that yet. 
Will they be willing to in another year? I can't say.


I'm not dropping support for 2.7 for the foreseeable future for my libraries, 
so an extra year won't help me at all (other than give me another 12 months to 
procrastinate).

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 12:36 AM Victor Stinner  wrote:

> Le ven. 24 janv. 2020 à 03:37, Guido van Rossum  a
> écrit :
> > I think this started with a valuable optimization for `x in `. I
> don't know if that was ever carefully documented, but I remember that it
> was discussed a few times (and IIRC Raymond was adamant that this should be
> so optimized -- which is reasonable).
> >
> > I'm tempted to declare this implementation-defined behavior --
> *implicit* calls to __eq__ and __ne__ *may* be skipped if both sides are
> the same object depending on the whim of the implementation.
>
> CPython current behavior rely on the fact that it's possible to get
> the memory address of an object. I don't think that it should be part
> of Python language specification, but seen as a CPython implementation
> detail.
>

However, the presence of the `is` operator is not an implementation detail
-- it must be present in all implementations. And that's all that's needed.


> --
>
> In PyPy, you may or may not have an "object". It depends how PyPy
> decides to store values. For example, if a list only contains small
> integers: PyPy uses a list specialized for integers and store
> integers, not objects which stores integers. The JIT compiler can also
> emit machine codes which uses directly CPU registers to store
> integers: again, objects don't exist in memory.
>
> The interesting part is that PyPy managed somehow to mimick CPython
> small integer singletons :-)
>
>  x=1
>  y=2-1
>  y is x
> True
>  id(x), id(y)
> (17L, 17L)
>

Yeah, that's because there's code that depends on this CPython
implementation quirk, and PyPy wants to support such code. In any case, the
outcome of `x is y` where x and y are numbers with the same type and value
is already implementation-defined. Comparisons that want to shortcut ==
should do whatever `is` does.


> --
>
> Another example: there is new implementation of Python called "Snek"
> which is based on 32-bit snek_poly_t type. It is designed for devices
> with 2K of memory:
>
> https://keithp.com/snek/
> https://lwn.net/Articles/810201/
>

I've heard of it. It does not claim to be a full Python implementation
though (unlike micropython, which claims compatibility with Python 3.5 or
so).

The implementation uses the following structure for objects:
>
> typedef union {
>  uint32_t u;
> float f;
> } snek_poly_t;
>
> It's just 32-bit. At the C level, objects are not passed by references
> (pointers), but by "value": copy 32-bit value to pass them as function
> arguments, to copy the function result, etc.
>
> So it's not possible to get an object address, since there is no
> "object" just its value :-)
>

That's interesting. Then it should follow whatever that implementation does
for `x is y` when x and y are numbers with the same value (presumably True
as long as they've got the same type).

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 3:45 AM Steven D'Aprano  wrote:

> On Fri, Jan 24, 2020 at 12:36:13PM +0300, Ivan Pozdeev via Python-Dev
> wrote:
>
> > >I'm tempted to declare this implementation-defined behavior --
> *implicit*
> > >calls to __eq__ and __ne__ *may* be skipped if both sides are the same
> > >object depending on the whim of the implementation.
> >
> > This cannot be an implementation detail because it changes the outcome
> of
> > operations.
>
> Guido didn't call it an implementation *detail* but implementation-
> defined behaviour. And of course that implies that the outcome could be
> different when using different implementations.
>
> I'm pretty sure Guido understood the implication when he made that
> comment.
>

Yes I did.

The only thing I'm unsure of here is whether direct use of the `==` and
> `!=` operators are included as "implicit calls" to the dunders. I
> *think* I understand Guido's intention, but I'm not sure:
>
> * x == y MUST call `__eq__`
>
> * likewise x != y MUST call `__ne__`
>
> * but compound objects such as lists and other collections MAY skip
>   calling `__eq__` (or `__eq__`) on their component parts.
>

Right.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Fri, Jan 24, 2020 at 4:47 AM Steven D'Aprano  wrote:

> On Fri, Jan 24, 2020 at 10:57:11PM +1100, Chris Angelico wrote:
> > On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano 
> wrote:
> > >
> > > The only thing I'm unsure of here is whether direct use of the `==` and
> > > `!=` operators are included as "implicit calls" to the dunders. I
> > > *think* I understand Guido's intention, but I'm not sure:
> > >
> > > * x == y MUST call `__eq__`
> > >
> > > * likewise x != y MUST call `__ne__`
>
> Oh, that's too strong. The interpreter ought to be allowed to bypass the
> method call if it is knows that reflexivity certainly holds.
>

In this context the intention was just to clarify that the shortcut using
(x is y) is not allowed. If the types are known to the compiler or JIT it
can of course optimize what it wants, but if there is for example a side
effect in the implementation of __eq__ or __ne__ this must be visible.


> Obviously it can't know that in the general case of two arbitrary
> objects, but if the interpreter knows that both objects are a built-in
> type (not a subclass) apart from float, then it *might* choose to test
> for identity.
>
> In other words, atomic objects MUST NOT *assume* reflexivity[1] of
> arbitrary types, but MAY take advantage of reflexivity of specific known
> types.
>
> (E.g. ints don't have NANs, so there's no harm in allowing the
> interpreter to skip the method call if it knows both operands are actual
> built-in ints.)
>

All this is always understood -- the interpreter can optimize things away
if there's no way for the user to tell (apart from measuring timings or
inspecting generated code).

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

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

On Fri, Jan 24, 2020 at 12:12 AM Serhiy Storchaka 
wrote:

> I consider breaking unmaintained code is an additional benefit of
> removing deprecated features.
>

I'd like to warn against this attitude (even though in the past I've
occasionally said such things). I now  think core Python should not be so
judgmental. We've broken enough code for a lifetime with the Python 2
transition. Let's be *much* more conservative when we remove things from
Python 3. Deprecation is fine, and we should look for other ways to handle
the problem of unmaintained code. But we should not rush language or stdlib
changes for this purpose.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

2020-01-24 Thread Brett Cannon

Terry Reedy wrote:
> On 1/24/2020 4:23 AM, Paul Moore wrote:
> > On Fri, 24 Jan 2020 at 02:36, Guido van Rossum gu...@python.org wrote:
> > I'm tempted to declare this
> > implementation-defined behavior -- implicit calls to __eq__ and __ne__
> > may be skipped if both sides are the same object depending on the whim of 
> > the
> > implementation.
> > This sounds reasonable to me. It could be added to
> > https://docs.python.org/3/reference/expressions.html#value-comparisons
> > """
> > The default behavior for equality comparison (== and !=) is based on
> > the identity of the objects. Hence, equality comparison of instances
> > with the same identity results in equality, and equality comparison of
> > instances with different identities results in inequality. A
> > motivation for this default behavior is the desire that all objects
> > should be reflexive (i.e. x is y implies x == y).
> > """
> > We could add an extra clause here: """As an optimisation, when the
> > implementation implicitly compares two values for equality (for
> > example, in list comparison or list.count) it is allowed (but not
> > required) to omit the equality check if the objects being compared are
> > the same. This can result in different behaviour for objects with
> > user-defined equality that is not reflexive - that is acceptable."""
> > This is an expanded version of what already exists further down, under 
> sequences.
> " The built-in containers typically assume identical objects are equal 
> to themselves. That lets them bypass equality tests for identical 
> objects to improve performance and to maintain their internal invariants."
> This was added last August, after careful consideration, by myself and 
> Raymond, as a beginner friendly replacement of 17 lines, that says what 
> users actually need to know.

For me this seems like an implementation-defined behaviour and the docs cover 
it already.
___
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/V4OZJSXWAYIRKK2RHLSAL2K7QU7T3DBJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

2020-01-24 Thread Python tracker


ACTIVITY SUMMARY (2020-01-17 - 2020-01-24)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7285 (+17)
  closed 43910 (+55)
  total  51195 (+72)

Open issues with patches: 2852 


Issues opened (45)
==

#29258: __init__.py required for pkgutil.walk_packages in python3
https://bugs.python.org/issue29258  reopened by inada.naoki

#39353: Deprecate the binhex module, binhex4 and hexbin4 standards
https://bugs.python.org/issue39353  reopened by vstinner

#39372: The header files in Include/ have many declarations with no de
https://bugs.python.org/issue39372  reopened by pablogsal

#39374: Key in sort -> Callable Object instead of function
https://bugs.python.org/issue39374  opened by Carlos Segura GonzÃ¡lez

#39375: Document os.environ[x] = y and os.putenv() as thread unsafe
https://bugs.python.org/issue39375  opened by gregory.p.smith

#39376: Avoid modifying the process global environment (not thread saf
https://bugs.python.org/issue39376  opened by gregory.p.smith

#39378: partial of PickleState struct should be traversed.
https://bugs.python.org/issue39378  opened by shihai1991

#39379: sys.path[0] is already absolute path
https://bugs.python.org/issue39379  opened by ksato9700

#39380: ftplib uses latin-1 as default encoding
https://bugs.python.org/issue39380  opened by SebastianGPedersen

#39382: abstract_issubclass() doesn't take bases tuple item ref
https://bugs.python.org/issue39382  opened by Yonatan Goldschmidt

#39384: Email parser creates a message object that can't be flattened 
https://bugs.python.org/issue39384  opened by msapiro

#39385: Add an assertNoLogs context manager to unittest TestCase
https://bugs.python.org/issue39385  opened by Kit Yan Choi

#39388: IDLE: Changes to keybindings aren't reverted on cancel
https://bugs.python.org/issue39388  opened by cheryl.sabella

#39390: shutil.copytree - 3.8 changed argument types of the ignore cal
https://bugs.python.org/issue39390  opened by mbarkhau

#39392: Python Turtle is not filling alternate overlapping areas of a 
https://bugs.python.org/issue39392  opened by lijose

#39393: Misleading error message upon dependent DLL resolution failure
https://bugs.python.org/issue39393  opened by plimkilde

#39394: re: DeprecationWarning for `flag not at the start of expressio
https://bugs.python.org/issue39394  opened by jugmac00

#39400: pydoc: Use of MANPAGER variable is incorrect
https://bugs.python.org/issue39400  opened by Brocellous

#39401: Unsafe dll loading in getpathp.c on Win7
https://bugs.python.org/issue39401  opened by anthonywee

#39405: Using relative path as a --prefix during configure.
https://bugs.python.org/issue39405  opened by Sankark

#39407: Bitfield Union does not work for bit widths greater than 8 bit
https://bugs.python.org/issue39407  opened by jschulte

#39408: Add support for SQLCipher
https://bugs.python.org/issue39408  opened by Sebastian.Noack

#39409: AIX: FAIL: test_specific_values (test.test_cmath.CMathTests)
https://bugs.python.org/issue39409  opened by Michael.Felt

#39410: CentOS 6.10 SQLite 3.30.1 - _sqlite3 builds successfully but i
https://bugs.python.org/issue39410  opened by cehovski

#39411: pyclbr rewrite using AST
https://bugs.python.org/issue39411  opened by Batuhan Taskaya

#39413: Implement os.unsetenv() on Windows
https://bugs.python.org/issue39413  opened by vstinner

#39414: Multiprocessing resolving object as None
https://bugs.python.org/issue39414  opened by rdil

#39416: Document default numeric string formats
https://bugs.python.org/issue39416  opened by kop

#39417: Link to "Python Packaging User Guide: Creating and using virtu
https://bugs.python.org/issue39417  opened by angelcervera

#39418: str.strip() should have a means of adding to the default behav
https://bugs.python.org/issue39418  opened by senji

#39419: Core dump when trying to use workaround for custom warning cat
https://bugs.python.org/issue39419  opened by Gerrit.Holl

#39423: Process finished with exit code -1073741819 (0xC005) when 
https://bugs.python.org/issue39423  opened by mapf

#39424: [easy] test_signal: test_pidfd_send_signal() uses deprecated a
https://bugs.python.org/issue39424  opened by vstinner

#39427: python -X options are not documented in the CLI --help
https://bugs.python.org/issue39427  opened by pablogsal

#39428: allow creation of "symtable entry" objects from Python
https://bugs.python.org/issue39428  opened by carljm

#39430: tarfile.open(mode="r") race condition when importing lzma
https://bugs.python.org/issue39430  opened by Maciej Gol

#39432: Distutils generates the wrong export symbol for unicode module
https://bugs.python.org/issue39432  opened by da-woods

#39433: curses.setupterm can raise _curses.error
https://bugs.python.org/issue39433  opened by mdk

#39434: Remove unnecessary logic of float __floordiv__
https://bugs.python.org/issue39

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

2020-01-24 Thread Brett Cannon

Victor Stinner wrote:
> Le jeu. 23 janv. 2020 à 20:45, Brett Cannon br...@python.org a écrit :
> > Two pieces of feedback on this. One, nose is a bad
> > example because that project has been telling people for years to switch to 
> > nose2 so the
> > fact that people have still not switched something that should mostly be a 
> > direct swap
> > after years of being asked to does not motivate in wanting to postpone one 
> > more year for
> > that project's benefit. ;) (And where did you get the download stats on 
> > libraries.io? https://libraries.io/pypi/nose doesn't show any
> > download counts.)
> > Oh right, download stats can be found at: 
> > https://pypistats.org/packages/nose
> Downloads last day: 150,272
> Downloads last week: 824,557
> Downloads last month: 3,077,860
> 150k downloads yesterday.

Ah, thanks! To put this in perspective, pytest had 631,008 downloads yesterday.

> > Two, you buried the list of things you would like to
> > revert and postpone to Python 3.10. :)
> > I'm not sure of the meaning of "buried" here. What do you mean?

Sorry, North American phrase. It means you put the important part way down 
towards the bottom. Another North American phrase that might apply is "burying 
the lead".

Basically you put the interesting, important stuff so far down it was easy to 
overlook. :) My suggestion would have been to structure the email as "Fedora is 
seeing some transition problems for projects ATM. Reverting these 5 changes and 
postponing them to 3.10 would help a lot, and here is a bunch of detail about 
why we are making this proposal." IOW putting the list towards the top makes it 
easier to set expectations of what you're asking for while you try to justify 
the request, otherwise I could be reading most of that email as if you're 
suggesting we bring back the print statement or something. ;)

> We
> propose to revert 5 changes:
> 
> Removed tostring/fromstring methods in array.array and base64 modules
> Removed collections aliases to ABC classes
> Removed fractions.gcd() function (which is similar to math.gcd())
> Remove "U" mode of open(): having to use io.open() just for Python 2
> makes the code uglier
> Removed old plistlib API: 2.7 doesn't have the new API
> 
> > Was this copied-and-pasted from somewhere, hence why
> > you explain to us how to use -X dev?
> > Well, use whatever you want to see DeprecationWarning, as soon as you
> fix all of them in your project :-) PYTHONWARNINGS=default should be
> fine as well.
> IMO it's simpler to remind "-X dev" than using PYTHONWARNINGS=default.
> By the way, -X dev and PYTHONWARNINGS=default shows more warnings than
> just DeprecationWarning: they also show ImportWarning,
> PendingDeprecationWarning and ResourceWarning. -X dev helps to make
> your project ready for the next Python version.
> > Basically it isn't easy to discuss the things you
> > want to revert here, especially since you grouped them all together. Are 
> > you planning to
> > start separate conversations on the (I think) 5 things you want to change?
> > I'm not sure of what you mean. Would you prefer one mail thread per revert?
> It's not only about specific changes, but more a discussion about a
> general policy to decide if a deprecated feature should stay until
> 3.10, or if it's ok to remove it in 3.9.
> For example, another feature has been removed since we drafted this
> email: "The encoding parameter of json.loads() has been removed." If
> we follow the proposed policy, it should also be reverted.
> It seems like the incompatible change causing most issues is the
> collections change. We can try to produce statistics per change if you
> prefer.
> I understand that you disagree to revert changes, but you would prefer
> to decide on a case by case basis.
> 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/JGDXB6DAXT5TAFH2TJGV5VU456BZXPKP/
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-01-24 Thread Brett Cannon

Eric V. Smith wrote:
> On 1/24/2020 9:14 AM, Miro Hrončok wrote:
> > On 24. 01. 20 14:02, Eric V. Smith wrote:
> > I think the concern is that with removing so
> > many deprecated 
> > features, we're effectively telling libraries that if they want to 
> > support 3.9, they'll have stop supporting 2.7. And many library 
> > authors aren't willing to do that yet. Will they be willing to in 
> > another year? I can't say.
> > The concern is not that they don't want to drop 2.7 support, but that 
> > is is a nontrivai task to actually do and we cannot expect them to 
> > do it within the first couple weeks of 2020. While at the same time, 
> > we want them to support 3.9 since the early development versisons in 
> > order to eb able to detect regressions early in the dev cycle.
> > Ah. So in 3.8, they kept code that had deprecation warnings so that they 
> could be compatible with 2.7. They'd like to now drop that code and be 
> 3.9-only compatible, but they don't have enough time to do that because 
> they couldn't start that work as long as they were supporting 2.7. Do I 
> have that right?
> If so, I'd be okay with postponing the removal of the deprecated code 
> until 3.10. But I don't think we should postpone it if the driver is so 
> that libraries can remain 2.7 compatible. That could go on forever. This 
> postponement would be a one-time thing.

I'm also okay with a one-time delay in removals that are problematic for code 
trying to get off of Python 2.7 this year and might not quite cut it before 
2021 hits. I'm sure some people will be caught off-guard once 3.9b1 comes out 
and they realize that they now have to start caring about deprecation warnings 
again. So I'm okay letting 3.9 be the release where we loudly declare, 
"deprecation warnings matter again! Keep your code warnings-free going forward 
as things will start being removed 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/ZLYXUBPHMRTAZFO3W6TPEUSOB7XNVW7H/
Code of Conduct: http://python.org/psf/codeofconduct/

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

Le ven. 24 janv. 2020 à 19:28, Brett Cannon  a écrit :
> (...) otherwise I could be reading most of that email as if you're suggesting 
> we bring back the print statement or something. ;)

By the way, about adding back print statement... nah, I'm just kidding :-D

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

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

Le ven. 24 janv. 2020 à 19:35, Brett Cannon  a écrit :
> I'm also okay with a one-time delay in removals that are problematic for code 
> trying to get off of Python 2.7 this year and might not quite cut it before 
> 2021 hits. I'm sure some people will be caught off-guard once 3.9b1 comes out 
> and they realize that they now have to start caring about deprecation 
> warnings again. So I'm okay letting 3.9 be the release where we loudly 
> declare, "deprecation warnings matter again! Keep your code warnings-free 
> going forward as things will start being removed in 3.10".

Maybe we can put a strong statement at the What's New In Python 3.9 document?

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 7:09 AM, Steven D'Aprano wrote:

On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote:

On 1/24/2020 3:36 AM, Victor Stinner wrote:

CPython current behavior rely on the fact that it's possible to get
the memory address of an object.

No, this behavior relies on the language specification that all objects
have temporally unique integer ids that can be compared with 'is'.

I don't think that it should be part of Python language specification,
but seen as a CPython implementation detail.

Ids are a language feature; ids being addresses is a CPython detail, but
this detail is not relevant to equality comparison of items within
containers.

Thanks Terry for raising this. Of course CPython can optimize identity
tests by checking for the same memory address, and *memory address* is
an implementation-detail of object identity.

Any Python implementation ought to have a sense of object identity,
however it is implemented or emulated. For instance, both Java and .Net
have compacting memory models, which means objects can move around in
memory and there's no well-defined "memory address", but both have to be
able to implement the `is` operator:

* Java has the `==` operator;
* .Net, or at least C#, has Object.ReferenceEquals

If there happens to be a Python interpreter where testing object
identity is expensive, then they should be free to *not* bypass the
equality test.

Victor:

I believe that PyPy nevertheless offers the illusion that such lists
contain objects, complete with IDs. They even manage to keep the ID
consistent across copies. For example:

L = [99]
id(L[0])
1585
id(L[:][0])
1585

so even if the list is implemented as an array of native integers rather
than int objects, as far as Python code is concerned there is no
behavioural difference.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 7:09 AM, Steven D'Aprano wrote:

On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote:

On 1/24/2020 3:36 AM, Victor Stinner wrote:

CPython current behavior rely on the fact that it's possible to get
the memory address of an object.

No, this behavior relies on the language specification that all objects
have temporally unique integer ids that can be compared with 'is'.

I don't think that it should be part of Python language specification,
but seen as a CPython implementation detail.

Ids are a language feature; ids being addresses is a CPython detail, but
this detail is not relevant to equality comparison of items within
containers.

Thanks Terry for raising this. Of course CPython can optimize identity
tests by checking for the same memory address, and *memory address* is
an implementation-detail of object identity.

* Java has the `==` operator;
* .Net, or at least C#, has Object.ReferenceEquals

In particular, Jython and IronPython have to implement Python's 'id' and
'is'. I believe 'id' is a bit of a nuisance. One way is a permanent
index into a list of mutable addresses. Once 'id' is done, 'is' should
be easy.

Human interpreters of Python code normally skip 'id', but if
knowledgable, somehow workout 'is' when it matters, for mutables,
without 'id'. I am not quite sure yet how I do that. For builtin
numbers and strings, we can identify 'is' and '==' unless trying to
simulate the possibly version-specific CPython implementation.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

[Inada Naoki ]
> FWIW, (list|tuple).__eq__ and (list|tuple).__contains__ uses it too.
> It is very important to compare recursive sequences.
>
> >>> x = []
> >>> x.append(x)
> >>> y = [x]
> >>> z = [x]
> >>> y == z
> True

That's a visible consequence, but I'm afraid this too must be
considered an implementation-defined quirk.  If doing a fine job of
comparing recursive containers was the actual goal, we would have
needed to do a much fancier thing, akin to testing graph isomorphism:

>>> a = []
>>> b = []
>>> for x in a, b:
... x.append(x)
>>> a
[[...]]
>>> b
[[...]]
>>> a == a
True
>>> b == b
True
>>> a == b
Traceback (most recent call last):
...
RecursionError: maximum recursion depth exceeded in comparison

Instead the happy behavior in your example (and in my first two
examples) just follows as a no-effort consequence of the
special-casing for identity equality in PyObject_RichCompareBool().

(Note that the _top_ level comparisons in my "a == a" and "b == b"
examples do _not_ exploit that the comparands are the same object -
it's list_richcompare() calling PyObject_RichCompareBool() where the
latter tells the former that a[0] and a[0] are equal.)
___
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/L4RPMHX7USTWLACBC5URKB3WXNBH2DKA/
Code of Conduct: http://python.org/psf/codeofconduct/

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


23.01.20 17:20, Victor Stinner пише:

> * Removed collections aliases to ABC classes

Adding loud warning was one of largest compatibility breaking changes in 
3.8, because many active projects treat warnings in tests as errors. I 
had doubts about removing them. On one side, they were deprecated for a 
very long time. On other side, most time it was silent deprecation, and 
the removal will affect too much projects. I agree with deferring this 
removal.


> * Remove "U" mode of open(): having to use io.open() just for Python 2
> makes the code uglier

io.open() (don't confuse with codecs.open(), which was recommended in 
the past) has other advantages. Builtin open() has problems with threads 
in Python 2.



* Removed tostring/fromstring methods in array.array and base64 modules
* Removed fractions.gcd() function (which is similar to math.gcd())
* Removed old plistlib API: 2.7 doesn't have the new API


As for other changes, they look minor, and I think they affect not much 
code. In particular, plistlib is specific for macOS.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

[Terry Reedy ]
> ...
> It is, in the section on how to understand and use value comparison
> *operators* ('==', etc.).
> https://docs.python.org/3/reference/expressions.html#value-comparisons
>
> First "The default behavior for equality comparison (== and !=) is based
> on the identity of the objects."
>
> Then in particular, "The built-in containers typically assume identical
> objects are equal to themselves. That lets them bypass equality tests
> for identical objects to improve performance and to maintain their
> internal invariants."

Cool!  I didn't find that, and I assume Victor didn't either.  It's good!

I think it needs more words, though, to flesh out what about this is
allowed by the language (as opposed to what CPython happens to do),
and to get closer to what Guido is trying to get at with his
"*implicit* calls".  For example, it's at work here, but there's not a
built-in container in sight:

>>> import math
>>> def f():
... while True:
... yield math.nan
>>> math.nan in f()
True


>> For example, in __eq__() method documentation:
>> https://docs.python.org/dev/reference/datamodel.html#object.__eq

> The text that follows discusses rich comparison *special methods* and
> how to write them.  It should refer people to the value-comparisons
> section for information on specific classes, as in the second quote
> above.  It would not hurt if the operator section referred people back
> to special method discussion.  I think you should go ahead and add one
> or both links.

Agreed.  If I want to know why my __eq__ (or __ne__) isn't being
called, it's __eq__/__ne__ docs I'm going to look at first.  And
probably last, unless I'm nudged in the right direction.
___
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/T4BAR4DVTMTR3GOJ2Y2AL2ZBCL6VSPUK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On Sat, Jan 25, 2020 at 9:40 AM Tim Peters  wrote:
> I think it needs more words, though, to flesh out what about this is
> allowed by the language (as opposed to what CPython happens to do),
> and to get closer to what Guido is trying to get at with his
> "*implicit* calls".  For example, it's at work here, but there's not a
> built-in container in sight:
>
> >>> import math
> >>> def f():
> ... while True:
> ... yield math.nan
> >>> math.nan in f()
> True
>

The iterator/generator is behaving the way a lazy container would, so
it's fairly unsurprising. Perhaps "container-like objects"?

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?


25.01.20 00:29, Tim Peters пише:

I think it needs more words, though, to flesh out what about this is
allowed by the language (as opposed to what CPython happens to do),
and to get closer to what Guido is trying to get at with his
"*implicit* calls".  For example, it's at work here, but there's not a
built-in container in sight:


import math
def f():

... while True:
... yield math.nan

math.nan in f()

True


It is documented in:
https://docs.python.org/3/reference/expressions.html#membership-test-operations

"""
For user-defined classes which do not define :meth:`__contains__` but do 
define

:meth:`__iter__`, ``x in y`` is ``True`` if some value ``z``, for which the
expression ``x is z or x == z`` is true, is produced while iterating 
over ``y``.
If an exception is raised during the iteration, it is as if 
:keyword:`in` raised

that exception.

Lastly, the old-style iteration protocol is tried: if a class defines
:meth:`__getitem__`, ``x in y`` is ``True`` if and only if there is a 
non-negative
integer index *i* such that ``x is y[i] or x == y[i]``, and no lower 
integer index
raises the :exc:`IndexError` exception.  (If any other exception is 
raised, it is as

if :keyword:`in` raised that exception).
"""
___
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/44IJUXAKFTF7VS3D4G4IFWJA2LPK23KL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

[Tim]
>> I think it needs more words, though, to flesh out what about this is
>> allowed by the language (as opposed to what CPython happens to do),
>> and to get closer to what Guido is trying to get at with his
>> "*implicit* calls".  For example, it's at work here, but there's not a
>> built-in container in sight:
>>
>> >>> import math
>> >>> def f():
>> ... while True:
>> ... yield math.nan
>> >>> math.nan in f()
>> True

[Serhiy Storchaka ]
> It is documented in:
> https://docs.python.org/3/reference/expressions.html#membership-test-operations
>
> """
> For user-defined classes which do not define :meth:`__contains__` but do
> define
> :meth:`__iter__`, ``x in y`` is ``True`` if some value ``z``, for which the
> expression ``x is z or x == z`` is true, is produced while iterating
> over ``y``.
> ...

But _should_ it be?  There are two parts to that:

1. Consensus seems to be that whether - and where - implicit equality
comparisons exploit object identity should be implementation-defined.
If so, the quoted docs are over-specified, elevating a CPython
implementation choice to a language requirement.

2. As I said in the first message, consequences of this choice are
"all over the place".  Repeating equivalents of "x is z or x == z" all
over the docs is ugly and error-prone, and especially if it also needs
to spell out that the "x is z" part is something CPython does but that
other implementations may not do.
___
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/QLBATZTQQU5H4BGJAFRO3DNXN23NB7UU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

On 1/24/2020 5:29 PM, Tim Peters wrote:

[Terry Reedy ]

...
It is, in the section on how to understand and use value comparison
*operators* ('==', etc.).
https://docs.python.org/3/reference/expressions.html#value-comparisons

First "The default behavior for equality comparison (== and !=) is based
on the identity of the objects."

This intentionally dropped 'reflexive' (a technical term not familiar to
many python beginners) and 'nan' (something beginners may not know about
and almost never actually use) to focus on who does what and why.

Cool! I didn't find that, and I assume Victor didn't either. It's good!

But clearly insufficiently discoverable. And the use of 'is' is not
limited to sequences, nor even to built-in containers (as shown below).
We might try moving these sentences up under the general paragraph on
equality comparison.

I think it needs more words, though, to flesh out what about this is
allowed by the language (as opposed to what CPython happens to do),
and to get closer to what Guido is trying to get at with his
"*implicit* calls".

I am thinking about how to do this with minimal words.

For example, it's at work here, but there's not a
built-in container in sight:

'in' is a built-in operation whose second argument can be anything that
can be seen as a 'container': iterables plus objects with __contains__.

import math
def f():

... while True:
... yield math.nan

math.nan in f()

True

> f().__iter__

Covered by "For user-defined classes which do not define __contains__()
but do define __iter__(), x in y is True if some value z, for which the
expression x is z or x == z is true, is produced while iterating over y.
" in

https://docs.python.org/3/reference/expressions.html#membership-test-operations

For example, in __eq__() method documentation:
https://docs.python.org/dev/reference/datamodel.html#object.__eq

Agreed. If I want to know why my __eq__ (or __ne__) isn't being
called, it's __eq__/__ne__ docs I'm going to look at first. And
probably last, unless I'm nudged in the right direction.

I will try to work on a draft PR.

--
Terry Jan Reedy

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

[Terry Reedy ]

]& skipping all the parts I agree with]

> ...
> Covered by "For user-defined classes which do not define __contains__()
> but do define __iter__(), x in y is True if some value z, for which the
> expression x is z or x == z is true, is produced while iterating over y.
> " in
>
> https://docs.python.org/3/reference/expressions.html#membership-test-operations

Just went through that with Serhiy.  Very briefly, two problems:

1. Those docs are over-specified if we intend that the "x is z"  is an
implementation choice rather than a language requirement.

2. Repeating all that stuff all over the docs is a PITA, error-prone,
and ugly, since contexts that call PyObject_RichCompareBool() under
the covers are all over the place too.

Document it carefully in _one_ place (the Reference Manual already has
your good start), and just plant links to that in high-value locations
elsewhere in the docs.
___
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/4EVEQZZPEPAGSJ25SSG2EQWQ3MUP2ZHW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?