Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 15.02.2014 07:03, Stephen J. Turnbull wrote: M.-A. Lemburg writes: IMO, it was a mistake to have None return a TypeError in comparisons, since it makes many typical data operations fail, e.g. I don't understand this statement. The theory is that they *should* fail. The example of sort is a good one. Sometimes you want missing values to be collected at the beginning of a list, sometimes at the end. Sometimes you want them treated as top elements, sometimes as bottom. And sometimes it is a real error for missing values to be present. Not to mention that sometimes the programmer simply hasn't thought about the appropriate policy. I don't think Python should silently impose a policy in that case, especially given that the programmer may have experience with any of the above treatments in other contexts. None is special in Python and has always (and intentionally) sorted before any other object. In data processing and elsewhere in Python programming, it's used to signal: no value available. Python 3 breaks this notion by always raising an exception when using None in an ordered comparison, making it pretty much useless for the above purpose. Yes, there are ways around this, but none of them are intuitive. Here's a particularly nasty case: l = [(1, None), (2, None)] l.sort() l [(1, None), (2, None)] l = [(1, None), (2, None), (3, 4)] l.sort() l [(1, None), (2, None), (3, 4)] l = [(1, None), (2, None), (3, 4), (2, 3)] l.sort() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() NoneType() -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 17 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17 February 2014 11:14, M.-A. Lemburg m...@egenix.com wrote: On 15.02.2014 07:03, Stephen J. Turnbull wrote: M.-A. Lemburg writes: IMO, it was a mistake to have None return a TypeError in comparisons, since it makes many typical data operations fail, e.g. I don't understand this statement. The theory is that they *should* fail. The example of sort is a good one. Sometimes you want missing values to be collected at the beginning of a list, sometimes at the end. Sometimes you want them treated as top elements, sometimes as bottom. And sometimes it is a real error for missing values to be present. Not to mention that sometimes the programmer simply hasn't thought about the appropriate policy. I don't think Python should silently impose a policy in that case, especially given that the programmer may have experience with any of the above treatments in other contexts. None is special in Python and has always (and intentionally) sorted before any other object. In data processing and elsewhere in Python programming, it's used to signal: no value available. Python 3 breaks this notion by always raising an exception when using None in an ordered comparison, making it pretty much useless for the above purpose. Yes, there are ways around this, but none of them are intuitive. Here's a particularly nasty case: l = [(1, None), (2, None)] l.sort() l [(1, None), (2, None)] l = [(1, None), (2, None), (3, 4)] l.sort() l [(1, None), (2, None), (3, 4)] l = [(1, None), (2, None), (3, 4), (2, 3)] l.sort() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() NoneType() Maybe Python 3 should have a couple of None-like objects that compare the way you want: AlwaysComparesLess and AlwaysComparesGreater, but with better names (maybe 'PlusInfinity' and 'MinusInfinity'?). Just leave None alone, please. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 17 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com -- Gustavo J. A. M. Carneiro Gambit Research LLC The universe is always one step beyond logic. -- Frank Herbert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17.02.2014 12:23, Gustavo Carneiro wrote: On 17 February 2014 11:14, M.-A. Lemburg m...@egenix.com wrote: On 15.02.2014 07:03, Stephen J. Turnbull wrote: M.-A. Lemburg writes: IMO, it was a mistake to have None return a TypeError in comparisons, since it makes many typical data operations fail, e.g. I don't understand this statement. The theory is that they *should* fail. The example of sort is a good one. Sometimes you want missing values to be collected at the beginning of a list, sometimes at the end. Sometimes you want them treated as top elements, sometimes as bottom. And sometimes it is a real error for missing values to be present. Not to mention that sometimes the programmer simply hasn't thought about the appropriate policy. I don't think Python should silently impose a policy in that case, especially given that the programmer may have experience with any of the above treatments in other contexts. None is special in Python and has always (and intentionally) sorted before any other object. In data processing and elsewhere in Python programming, it's used to signal: no value available. Python 3 breaks this notion by always raising an exception when using None in an ordered comparison, making it pretty much useless for the above purpose. Yes, there are ways around this, but none of them are intuitive. Here's a particularly nasty case: l = [(1, None), (2, None)] l.sort() l [(1, None), (2, None)] l = [(1, None), (2, None), (3, 4)] l.sort() l [(1, None), (2, None), (3, 4)] l = [(1, None), (2, None), (3, 4), (2, 3)] l.sort() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() NoneType() Maybe Python 3 should have a couple of None-like objects that compare the way you want: AlwaysComparesLess and AlwaysComparesGreater, but with better names (maybe 'PlusInfinity' and 'MinusInfinity'?). Just leave None alone, please. This doesn't only apply to numeric comparisons. In Python 2 you can compare None with any kind of object and it always sorts first, based on the intuition that nothing is less than anything :-) FWIW, I don't think we need to invent a new name for it, just add an appropriate tp_richcompare slot to the PyNoneType or readd the special case to Object/object.c. This would also aid in porting existing Python 2 code to Python 3. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 17 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
17.02.14 13:14, M.-A. Lemburg написав(ла): Here's a particularly nasty case: l = [(1, None), (2, None)] l.sort() l [(1, None), (2, None)] l = [(1, None), (2, None), (3, 4)] l.sort() l [(1, None), (2, None), (3, 4)] l = [(1, None), (2, None), (3, 4), (2, 3)] l.sort() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() NoneType() If you replace None to another value that cannot be compared with int (e.g. string), you will got the same nasty case. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17 February 2014 11:43, M.-A. Lemburg m...@egenix.com wrote: On 17.02.2014 12:23, Gustavo Carneiro wrote: On 17 February 2014 11:14, M.-A. Lemburg m...@egenix.com wrote: On 15.02.2014 07:03, Stephen J. Turnbull wrote: M.-A. Lemburg writes: IMO, it was a mistake to have None return a TypeError in comparisons, since it makes many typical data operations fail, e.g. I don't understand this statement. The theory is that they *should* fail. The example of sort is a good one. Sometimes you want missing values to be collected at the beginning of a list, sometimes at the end. Sometimes you want them treated as top elements, sometimes as bottom. And sometimes it is a real error for missing values to be present. Not to mention that sometimes the programmer simply hasn't thought about the appropriate policy. I don't think Python should silently impose a policy in that case, especially given that the programmer may have experience with any of the above treatments in other contexts. None is special in Python and has always (and intentionally) sorted before any other object. In data processing and elsewhere in Python programming, it's used to signal: no value available. Python 3 breaks this notion by always raising an exception when using None in an ordered comparison, making it pretty much useless for the above purpose. Yes, there are ways around this, but none of them are intuitive. Here's a particularly nasty case: l = [(1, None), (2, None)] l.sort() l [(1, None), (2, None)] l = [(1, None), (2, None), (3, 4)] l.sort() l [(1, None), (2, None), (3, 4)] l = [(1, None), (2, None), (3, 4), (2, 3)] l.sort() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() NoneType() Maybe Python 3 should have a couple of None-like objects that compare the way you want: AlwaysComparesLess and AlwaysComparesGreater, but with better names (maybe 'PlusInfinity' and 'MinusInfinity'?). Just leave None alone, please. This doesn't only apply to numeric comparisons. In Python 2 you can compare None with any kind of object and it always sorts first, based on the intuition that nothing is less than anything :-) I still think that relying on your intuition is not the right way for Python. Refuse the temptation to guess. FWIW, I don't think we need to invent a new name for it, just add an appropriate tp_richcompare slot to the PyNoneType or readd the special case to Object/object.c. This would also aid in porting existing Python 2 code to Python 3. Based on your comment, SortsFirst and SortsLast sound like good names ;-) These would be universal sortable objects, that could be compared to any other type. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 17 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- Gustavo J. A. M. Carneiro Gambit Research LLC The universe is always one step beyond logic. -- Frank Herbert ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17 February 2014 11:49, Gustavo Carneiro gjcarne...@gmail.com wrote: FWIW, I don't think we need to invent a new name for it, just add an appropriate tp_richcompare slot to the PyNoneType or readd the special case to Object/object.c. This would also aid in porting existing Python 2 code to Python 3. Based on your comment, SortsFirst and SortsLast sound like good names ;-) These would be universal sortable objects, that could be compared to any other type. I think that having both is over-engineered. For the use cases I know of, all that is wanted is *one* object that doesn't raise a TypeError when compared with any other object, and compares predictably (always before or always after, doesn't matter which). Whether that object is None, or whether it should be a new singleton, is not obvious. The advantage of None is that it's Python 2 compatible (which aids porting as noted). The advantage of a new object is that not all uses of None need universal sortability, and indeed in some cases universal sortability will hide bugs. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17.02.2014 12:47, Serhiy Storchaka wrote: 17.02.14 13:14, M.-A. Lemburg написав(ла): Here's a particularly nasty case: l = [(1, None), (2, None)] l.sort() l [(1, None), (2, None)] l = [(1, None), (2, None), (3, 4)] l.sort() l [(1, None), (2, None), (3, 4)] l = [(1, None), (2, None), (3, 4), (2, 3)] l.sort() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() NoneType() If you replace None to another value that cannot be compared with int (e.g. string), you will got the same nasty case. Yes, but that's not the point. Unlike strings or other mixed types that you cannot compare, None is used as placeholder in data processing as special value to mean no value available. You intentionally use such values in programming. It's not a bug to have None in a data list or as value of a variable. -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17.02.2014 12:49, Gustavo Carneiro wrote: On 17 February 2014 11:43, M.-A. Lemburg m...@egenix.com wrote: On 17.02.2014 12:23, Gustavo Carneiro wrote: On 17 February 2014 11:14, M.-A. Lemburg m...@egenix.com wrote: On 15.02.2014 07:03, Stephen J. Turnbull wrote: M.-A. Lemburg writes: IMO, it was a mistake to have None return a TypeError in comparisons, since it makes many typical data operations fail, e.g. I don't understand this statement. The theory is that they *should* fail. The example of sort is a good one. Sometimes you want missing values to be collected at the beginning of a list, sometimes at the end. Sometimes you want them treated as top elements, sometimes as bottom. And sometimes it is a real error for missing values to be present. Not to mention that sometimes the programmer simply hasn't thought about the appropriate policy. I don't think Python should silently impose a policy in that case, especially given that the programmer may have experience with any of the above treatments in other contexts. None is special in Python and has always (and intentionally) sorted before any other object. In data processing and elsewhere in Python programming, it's used to signal: no value available. Python 3 breaks this notion by always raising an exception when using None in an ordered comparison, making it pretty much useless for the above purpose. Yes, there are ways around this, but none of them are intuitive. Here's a particularly nasty case: l = [(1, None), (2, None)] l.sort() l [(1, None), (2, None)] l = [(1, None), (2, None), (3, 4)] l.sort() l [(1, None), (2, None), (3, 4)] l = [(1, None), (2, None), (3, 4), (2, 3)] l.sort() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: int() NoneType() Maybe Python 3 should have a couple of None-like objects that compare the way you want: AlwaysComparesLess and AlwaysComparesGreater, but with better names (maybe 'PlusInfinity' and 'MinusInfinity'?). Just leave None alone, please. This doesn't only apply to numeric comparisons. In Python 2 you can compare None with any kind of object and it always sorts first, based on the intuition that nothing is less than anything :-) I still think that relying on your intuition is not the right way for Python. Refuse the temptation to guess. Hmm, are you sure ? There should be one-- and preferably only one --obvious way to do it. and then Although that way may not be obvious at first unless you're Dutch. which directly relates to: changeset: 16123:f997ded4e219 branch: legacy-trunk user:Guido van Rossum gu...@python.org date:Mon Jan 22 19:28:09 2001 + summary: New special case in comparisons: None is smaller than any other object :-) FWIW, I don't think we need to invent a new name for it, just add an appropriate tp_richcompare slot to the PyNoneType or readd the special case to Object/object.c. This would also aid in porting existing Python 2 code to Python 3. Based on your comment, SortsFirst and SortsLast sound like good names ;-) These would be universal sortable objects, that could be compared to any other type. Of course, it's easy to add a new type for this, but a lot of Python 2 code relies on None behaving this way, esp. code that reads data from databases, since None is the Python mapping for SQL NULL. -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17 Feb 2014 21:15, M.-A. Lemburg m...@egenix.com wrote: On 15.02.2014 07:03, Stephen J. Turnbull wrote: M.-A. Lemburg writes: IMO, it was a mistake to have None return a TypeError in comparisons, since it makes many typical data operations fail, e.g. I don't understand this statement. The theory is that they *should* fail. The example of sort is a good one. Sometimes you want missing values to be collected at the beginning of a list, sometimes at the end. Sometimes you want them treated as top elements, sometimes as bottom. And sometimes it is a real error for missing values to be present. Not to mention that sometimes the programmer simply hasn't thought about the appropriate policy. I don't think Python should silently impose a policy in that case, especially given that the programmer may have experience with any of the above treatments in other contexts. None is special in Python and has always (and intentionally) sorted before any other object. In data processing and elsewhere in Python programming, it's used to signal: no value available. This is the first I've ever heard of that sorting behaviour being an intentional feature, rather than just an artefact of Python 2 allowing arbitrarily ordered comparisons between different types. Can you point me to the relevant entry in the Python 2 language reference? Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
17.02.14 13:56, M.-A. Lemburg написав(ла):
Yes, but that's not the point. Unlike strings or other mixed types that
you cannot compare, None is used as placeholder in data processing as
special value to mean no value available.
Isn't float('nan') such placeholder?
You intentionally use such values in programming. It's not a bug to
have None in a data list or as value of a variable.
You can't have None in array('f'), you can't add or multiply by None.
Relation operators don't looks an exception here. Applying sorted() to a
list which contains numbers and Nones makes as much sense as applying
sum() to it.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17.02.2014 13:12, Nick Coghlan wrote: On 17 Feb 2014 21:15, M.-A. Lemburg m...@egenix.com wrote: On 15.02.2014 07:03, Stephen J. Turnbull wrote: M.-A. Lemburg writes: IMO, it was a mistake to have None return a TypeError in comparisons, since it makes many typical data operations fail, e.g. I don't understand this statement. The theory is that they *should* fail. The example of sort is a good one. Sometimes you want missing values to be collected at the beginning of a list, sometimes at the end. Sometimes you want them treated as top elements, sometimes as bottom. And sometimes it is a real error for missing values to be present. Not to mention that sometimes the programmer simply hasn't thought about the appropriate policy. I don't think Python should silently impose a policy in that case, especially given that the programmer may have experience with any of the above treatments in other contexts. None is special in Python and has always (and intentionally) sorted before any other object. In data processing and elsewhere in Python programming, it's used to signal: no value available. This is the first I've ever heard of that sorting behaviour being an intentional feature, rather than just an artefact of Python 2 allowing arbitrarily ordered comparisons between different types. Can you point me to the relevant entry in the Python 2 language reference? This is not documented anywhere in the language spec, AFAIK. It is documented in the code (Python 2.7; Object/object.c): default_3way_compare(PyObject *v, PyObject *w) ... /* None is smaller than anything */ if (v == Py_None) return -1; if (w == Py_None) return 1; Note that it's not important whether None is smaller or greater than any other object. The important aspect is that it's sorting order is consistent and doesn't raise a TypeError when doing an ordered comparison with other objects. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 17 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17.02.2014 13:19, Serhiy Storchaka wrote:
17.02.14 13:56, M.-A. Lemburg написав(ла):
Yes, but that's not the point. Unlike strings or other mixed types that
you cannot compare, None is used as placeholder in data processing as
special value to mean no value available.
Isn't float('nan') such placeholder?
You can easily construct other such placeholders, but None was intended
for this purpose:
http://docs.python.org/2.7/c-api/none.html?highlight=none#Py_None
The Python None object, denoting lack of value. ...
You intentionally use such values in programming. It's not a bug to
have None in a data list or as value of a variable.
You can't have None in array('f'), you can't add or multiply by None.
Relation operators don't looks
an exception here. Applying sorted() to a list which contains numbers and
Nones makes as much sense
as applying sum() to it.
Of course, you cannot apply any operations with None - it doesn't
have a value -, but you can compare it to other objects and it provides
a consistent behavior in Python 2. Python 3 is missing such an object.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 17 2014)
Python Projects, Consulting and Support ... http://www.egenix.com/
mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53
: Try our mxODBC.Connect Python Database Interface for free ! ::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17 February 2014 12:30, M.-A. Lemburg m...@egenix.com wrote:
On 17.02.2014 13:19, Serhiy Storchaka wrote:
17.02.14 13:56, M.-A. Lemburg написав(ла):
Yes, but that's not the point. Unlike strings or other mixed types that
you cannot compare, None is used as placeholder in data processing as
special value to mean no value available.
Isn't float('nan') such placeholder?
You can easily construct other such placeholders, but None was intended
for this purpose:
http://docs.python.org/2.7/c-api/none.html?highlight=none#Py_None
The Python None object, denoting lack of value. ...
You intentionally use such values in programming. It's not a bug to
have None in a data list or as value of a variable.
You can't have None in array('f'), you can't add or multiply by None.
Relation operators don't looks
an exception here. Applying sorted() to a list which contains numbers
and Nones makes as much sense
as applying sum() to it.
Of course, you cannot apply any operations with None - it doesn't
have a value -, but you can compare it to other objects and it provides
a consistent behavior in Python 2. Python 3 is missing such an object.
I agree with you that Python 3 could use such an object. Just don't make
it the default. Leave None as it is.
Also I agree that my previous naming suggestions are bad. What we need is
only one (or two) additional object whose main semantic meaning is still
no value, but which also adds a meaning of comparable. Then it's a
matter of choosing a good name for it, with lots of bikeshedding involved.
Just lets not change None only because we're too lazy to discuss a proper
alternative name. Also this use case is not _that_ common, so it's ok if
it has a slightly longer name than None.
Also think of the implications of changing None at this point. It would
allow us to write programs that work Python = 3.5 and Python = 2.7, but
fail mysteriously in all other versions in between. What a mess that would
be...
--
Gustavo J. A. M. Carneiro
Gambit Research LLC
The universe is always one step beyond logic. -- Frank Herbert
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17.02.2014 14:29, Gustavo Carneiro wrote:
On 17 February 2014 12:30, M.-A. Lemburg m...@egenix.com wrote:
On 17.02.2014 13:19, Serhiy Storchaka wrote:
17.02.14 13:56, M.-A. Lemburg написав(ла):
Yes, but that's not the point. Unlike strings or other mixed types that
you cannot compare, None is used as placeholder in data processing as
special value to mean no value available.
Isn't float('nan') such placeholder?
You can easily construct other such placeholders, but None was intended
for this purpose:
http://docs.python.org/2.7/c-api/none.html?highlight=none#Py_None
The Python None object, denoting lack of value. ...
You intentionally use such values in programming. It's not a bug to
have None in a data list or as value of a variable.
You can't have None in array('f'), you can't add or multiply by None.
Relation operators don't looks
an exception here. Applying sorted() to a list which contains numbers
and Nones makes as much sense
as applying sum() to it.
Of course, you cannot apply any operations with None - it doesn't
have a value -, but you can compare it to other objects and it provides
a consistent behavior in Python 2. Python 3 is missing such an object.
I agree with you that Python 3 could use such an object. Just don't make
it the default. Leave None as it is.
Also I agree that my previous naming suggestions are bad. What we need is
only one (or two) additional object whose main semantic meaning is still
no value, but which also adds a meaning of comparable. Then it's a
matter of choosing a good name for it, with lots of bikeshedding involved.
Just lets not change None only because we're too lazy to discuss a proper
alternative name. Also this use case is not _that_ common, so it's ok if
it has a slightly longer name than None.
Also think of the implications of changing None at this point. It would
allow us to write programs that work Python = 3.5 and Python = 2.7, but
fail mysteriously in all other versions in between. What a mess that would
be...
Yes, that's unfortunately true.
If you regard this as bug in the Python 3 series, we could still fix
it for 3.3 and 3.4, though. After all, we'd just be removing an unwanted
exception and not make already working Python 3 applications fail.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 17 2014)
Python Projects, Consulting and Support ... http://www.egenix.com/
mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53
: Try our mxODBC.Connect Python Database Interface for free ! ::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On Tue, Feb 18, 2014 at 1:30 AM, M.-A. Lemburg m...@egenix.com wrote: Also think of the implications of changing None at this point. It would allow us to write programs that work Python = 3.5 and Python = 2.7, but fail mysteriously in all other versions in between. What a mess that would be... Yes, that's unfortunately true. I don't know that that's in itself that much of a problem. (BTW, I wouldn't call it = 2.7; it'd be all 2.x, it's not like some of the 2.7.y versions aren't included.) There are already barriers to supporting 2.7 and 3.1/3.2, like the uasdf notation for Unicode literals. Making it easier to support 2.x and 3.x from the same codebase is an improvement that has been done and will be done more. It's not such a mysterious failure; it's just that you support Python 2.5+ and 3.4+ (or whatever the specific versions are). ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On Mon, Feb 17, 2014 at 12:43:25PM +0100, M.-A. Lemburg wrote: This doesn't only apply to numeric comparisons. In Python 2 you can compare None with any kind of object and it always sorts first, No you can't. See http://bugs.python.org/issue1673405 . According to Tim Peters, the None is less than everything rule never existed. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17.02.2014 15:38, Jon Ribbens wrote: On Mon, Feb 17, 2014 at 12:43:25PM +0100, M.-A. Lemburg wrote: This doesn't only apply to numeric comparisons. In Python 2 you can compare None with any kind of object and it always sorts first, No you can't. See http://bugs.python.org/issue1673405 . According to Tim Peters, the None is less than everything rule never existed. Well, then Tim probably didn't read the code in object.c :-) Seriously, the datetime module types were the first types to experiment with the new mixed type operation mechanism added at the time: http://www.python.org/dev/peps/pep-0207/ http://www.python.org/dev/peps/pep-0208/ Objects implementing the rich comparison slot can indeed override these defaults and also raise exceptions in comparison operations, so you're right: None comparisons can still be made to raise exceptions, even in Python 2.7. Still, None comparisons work just fine for most types in Python 2.x and people have written code assuming that it works for many years. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 17 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 2/17/2014 7:25 AM, M.-A. Lemburg wrote: On 17.02.2014 13:12, Nick Coghlan wrote: On 17 Feb 2014 21:15, M.-A. Lemburg m...@egenix.com wrote: On 15.02.2014 07:03, Stephen J. Turnbull wrote: M.-A. Lemburg writes: IMO, it was a mistake to have None return a TypeError in comparisons, since it makes many typical data operations fail, e.g. I don't understand this statement. The theory is that they *should* fail. The example of sort is a good one. Sometimes you want missing values to be collected at the beginning of a list, sometimes at the end. Sometimes you want them treated as top elements, sometimes as bottom. And sometimes it is a real error for missing values to be present. Not to mention that sometimes the programmer simply hasn't thought about the appropriate policy. I don't think Python should silently impose a policy in that case, especially given that the programmer may have experience with any of the above treatments in other contexts. None is special in Python and has always (and intentionally) sorted before any other object. In data processing and elsewhere in Python programming, it's used to signal: no value available. This is the first I've ever heard of that sorting behaviour being an intentional feature, rather than just an artefact of Python 2 allowing arbitrarily ordered comparisons between different types. Can you point me to the relevant entry in the Python 2 language reference? This is not documented anywhere in the language spec, AFAIK. http://docs.python.org/2/reference/expressions.html#not-in The operators , , ==, =, =, and != compare the values of two objects. The objects need not have the same type. If both are numbers, they are converted to a common type. Otherwise, objects of different types always compare unequal, and are ordered consistently but arbitrarily. http://docs.python.org/2/library/stdtypes.html#comparisons Objects of different types, except different numeric types and different string types, never compare equal; such objects are ordered consistently but arbitrarily It goes on to note the exception for complex numbers, but none for None. It continues CPython implementation detail: Objects of different types except numbers are ordered by their type names; Again, there is no exception noted for None, although, since the type name of None is 'NoneType', its behavior does not match that doc note. I believe that CPython implementation detail was some of the arbitrary orderings changed in CPython between 1.3 and 2.7. I do not know whether other implementations all mimicked CPython or not, but the reference manual does not require that. It is documented in the code (Python 2.7; Object/object.c): default_3way_compare(PyObject *v, PyObject *w) This is the 'final fallback' for comparisons, not the first thing tried. ... /* None is smaller than anything */ Reading CPython C code is not supposed to be a requirement for programming in Python. If that comment were true, I would regard it as only documenting a version of CPython, not the language standard. But it is not even true in 2.7.6. But it is not even true. class Bottom(object): # get same results below without 'object' def __lt__(self, other): return True # the following two results are consistent and # contradict the claim that 'None is smaller than anything' Bottom() None True cmp(Bottom(), None) -1 # the following two results are not consistent with the # definition of cmp, so 1 of the 2 is buggy None Bottom() True cmp(None, Bottom()) 1 It appears that 'anything' needs to be qualified as something like 'anything that does not itself handle comparison with None or is not given a chance to do so in a particular comparison expression'. if (v == Py_None) return -1; if (w == Py_None) return 1; Note that it's not important whether None is smaller or greater than any other object. The important aspect is that it's sorting order is consistent and doesn't raise a TypeError when doing an ordered comparison with other objects. I can agree that it might have been nice if None had been defined as a universal bottom object, but it has not been so defined and it did not act as such. To make it (or anything else) a true bottom object would require a change in the way comparisons are evaluated. Comparisons with 'bottom' would have to be detected and special-cased at the beginning of the code, not at the end as a fallback. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/16/2014 03:45 PM, Paul Moore wrote: http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here on the issue to make sure it's not missed... If it has an issue number like that, then generally Roundup Robot will notify the issue when something is checked in. And those comments will have the revision id in them. Also, you can scan the output of hg log to find the revision numbers. The first line of each stanza looks like changeset: 89231:75a12cf63f20 Here, 75a12cf63f20 is the revision id. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Thanks, I see. Greg already filed a tracking issue, so it's covered anyway. On 17 February 2014 15:33, Larry Hastings la...@hastings.org wrote: On 02/16/2014 03:45 PM, Paul Moore wrote: http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here on the issue to make sure it's not missed... If it has an issue number like that, then generally Roundup Robot will notify the issue when something is checked in. And those comments will have the revision id in them. Also, you can scan the output of hg log to find the revision numbers. The first line of each stanza looks like changeset: 89231:75a12cf63f20 Here, 75a12cf63f20 is the revision id. /arry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: What to do about the Derby patches
On 02/16/2014 04:03 PM, Victor Stinner wrote: Hi, The PEP 436 is still a draft and not mentionned in Python 3.4 changelog. The PEP proposes to add a DSL, not to modify all modules implemented in C. I think that it should be marked as Final and mentionned in the changelog. http://www.python.org/dev/peps/pep-0436/ I need to clean it up and submit it for final inspection. This is on my to-do list for before 3.4.0 final. 2014-02-16 19:31 GMT+01:00 Larry Hastings la...@hastings.org: 1) We merge the Derby patch for the builtins module into 3.4, simply because it will demo well. Where is the issue to implement this feature? Anyway, I expect a huge patch which is non-trivial and so very risky for such a very important module :-/ It's too late IMO. http://bugs.python.org/issue20184 The point is that it *is* trivial and not particularly risky. Doing this right means that we execute essentially the same statements in the same order, merely split across two functions, and with a slightly different docstring. Literally the only detectable runtime difference that should exist after applying the patch is that the functions now publish docstrings. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 2/17/2014 10:22 AM, M.-A. Lemburg wrote: On 17.02.2014 15:38, Jon Ribbens wrote: On Mon, Feb 17, 2014 at 12:43:25PM +0100, M.-A. Lemburg wrote: This doesn't only apply to numeric comparisons. In Python 2 you can compare None with any kind of object and it always sorts first, No you can't. See http://bugs.python.org/issue1673405 . According to Tim Peters, the None is less than everything rule never existed. Tim is correct. Copying from my other response (posted after you wrote this) class Bottom(object): # get same results below without 'object' def __lt__(self, other): return True # the following two results are consistent and # contradict the claim that 'None is smaller than anything' Bottom() None True cmp(Bottom(), None) -1 # the following two results are not consistent with the # definition of cmp, so 1 of the 2 is buggy None Bottom() True cmp(None, Bottom()) 1 Well, then Tim probably didn't read the code in object.c :-) I did, as I suspect Time has also. Function default_3way_compare is a 'final fallback'. The comment within, besides being a code comment and not the doc, is wrong unless 'anything' is qualified. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
17.02.14 14:11, M.-A. Lemburg написав(ла): Of course, it's easy to add a new type for this, but a lot of Python 2 code relies on None behaving this way, esp. code that reads data from databases, since None is the Python mapping for SQL NULL. At the same time a lot of Python 2 relies on the assumption that any two values are comparable. I suppose that I see a code that try to sort a heterogeneous list more often than a code which want to sort a list containing only numbers and Nones. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
17.02.14 20:18, Serhiy Storchaka написав(ла): 17.02.14 14:11, M.-A. Lemburg написав(ла): Of course, it's easy to add a new type for this, but a lot of Python 2 code relies on None behaving this way, esp. code that reads data from databases, since None is the Python mapping for SQL NULL. At the same time a lot of Python 2 relies on the assumption that any two values are comparable. I suppose that I see a code that try to sort a heterogeneous list more often than a code which want to sort a list containing only numbers and Nones. Sorry, I press Send too early. If we consider the idea to make None universally comparable, we should consider the idea to make all other values universally comparable too. And consider again the reasons which caused these changes in Python 3. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 2/17/2014 12:59 PM, Terry Reedy wrote: On 2/17/2014 10:22 AM, M.-A. Lemburg wrote: On 17.02.2014 15:38, Jon Ribbens wrote: On Mon, Feb 17, 2014 at 12:43:25PM +0100, M.-A. Lemburg wrote: This doesn't only apply to numeric comparisons. In Python 2 you can compare None with any kind of object and it always sorts first, No you can't. See http://bugs.python.org/issue1673405 . This issue was about the fact that datetimes do not compare with None, which means that even in 2.x, putting None in a list of datetimes (to mean no datetime) means that the list cannot be sorted. According to Tim Peters, the None is less than everything rule never existed. Tim is correct. Copying from my other response (posted after you wrote this) class Bottom(object): # get same results below without 'object' def __lt__(self, other): return True # the following two results are consistent and # contradict the claim that 'None is smaller than anything' Bottom() None True cmp(Bottom(), None) -1 # the following two results are not consistent with the # definition of cmp, so 1 of the 2 is buggy None Bottom() True cmp(None, Bottom()) 1 Well, then Tim probably didn't read the code in object.c :-) I did, as I suspect Time has also. Function default_3way_compare is a 'final fallback'. The comment within, besides being a code comment and not the doc, is wrong unless 'anything' is qualified. FWIW: do_cmp first calls try_rich_to_3way_compare and if that fails it calls try_3way_compare and if that fails it calls default_3way_compare. Somewhat confusingly, try_rich_to_3way_compare first calls try_3way_compare and if that fails, it calls default_3way_compare. So the backup calls in do_cmp are redundant, as they will have already failed in try_rich_to_3way_compare. The special casing of None in default_3way_compare was added by Guido in rev. 16123 on 2001 Jan 22. Before that, None was compared by the typename, as still specified in the docs. Tim was correct when he wrote For older types, the result of inequality comparison with None isn't defined by the language, and the outcome does vary across CPython releases. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 2/17/2014 1:18 PM, Serhiy Storchaka wrote: 17.02.14 14:11, M.-A. Lemburg написав(ла): Of course, it's easy to add a new type for this, but a lot of Python 2 code relies on None behaving this way, esp. code that reads data from databases, since None is the Python mapping for SQL NULL. At the same time a lot of Python 2 relies on the assumption that any two values are comparable. That assumption was very intentionally broken and abandoned by Guido when complex numbers were added over a decade ago. It was further abandoned, intentionally, when datetimes were added. I think it was decided then to finish the job in 3.0. I suppose that I see a code that try to sort a heterogeneous list more often than a code which want to sort a list containing only numbers and Nones. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
The behavior of None in comparisons is intentional in Python 3. You can agitate to change it, but it will probably die when Guido gets wind of it ;-) The catch-all mixed-type comparison rules in Pythons 1 and 2 were only intended to be arbitrary but consistent. Of course each specific release picked some specific scheme, but these schemes weren't documented, and intentionally not. For a long time CPython's default for mixed-typed comparisons was to compare the names of the types (as strings). And for just as long, nobody had noticed that this _wasn't_ always consistent. For example, 3L 4 must be true. But [] 3L was also true (because list long), and 4 [] was true too (because int list). So, in all, [] 3L 4 [] was true, implying [] []. Part of fixing that was removing some cases of compare objects of different types by comparing the type name strings. Guido I were both in the office at the time, and one said to the other: what about None? Comparing that to other types via comparing the string 'None' doesn't make much sense. Ya, OK ... how about changing None to - by default - comparing 'less than' objects of other types? Don't see why not - sure. OK, done!. No more than 2 minutes of thought went into it. There was no intent to cater to any real use case here - the only intent was to pick some arbitrary-but-consistent rule that didn't suck _quite_ as badly as pretending None was the string None ;-) Guido wanted to drop all the arbitrary but consistent mixed-type comparison crud for Python 3. Nothing special about None in that. As already noted, the various `datetime` types were the first to experiment with implementing full blown Python3-ish mixed-type comparison rules. After the first two times that caught actual bugs in code using the new types, there was no turning back. It's not so much that Python 3 finished the job as that Python 2 started it ;-) much-ado-about-nonething-ly y'rs - tim ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 17.02.2014 21:12, Tim Peters wrote: [...] Guido wanted to drop all the arbitrary but consistent mixed-type comparison crud for Python 3. Nothing special about None in that. As already noted, the various `datetime` types were the first to experiment with implementing full blown Python3-ish mixed-type comparison rules. After the first two times that caught actual bugs in code using the new types, there was no turning back. It's not so much that Python 3 finished the job as that Python 2 started it ;-) Well, I guess it depends on how you look at it. None worked as compares less than all other objects simply due to the fact that None is a singleton and doesn't implement the comparison slots (which for all objects not implementing rich comparisons, meant that the fallback code triggered in Python 2). In Python 3 the special casing was dropped and because None still doesn't implement the comparison slot (tp_richcompare this time), it doesn't support ordering comparisons anymore. Now, the choice to have None compare less than all other objects may have been arbitrary, but IMO it was a good, consistent and useful choice. So why not bring it back and perhaps this time in a way that actually does work consistently for all Python objects by implementing the tp_richcompare slot on PyNoneType objects and documenting it ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 17 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-02-12: Released mxODBC.Connect 2.0.4 ... http://egenix.com/go53 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: What to do about the Derby patches
On 18 Feb 2014 03:37, Larry Hastings la...@hastings.org wrote: On 02/16/2014 04:03 PM, Victor Stinner wrote: Hi, The PEP 436 is still a draft and not mentionned in Python 3.4 changelog. The PEP proposes to add a DSL, not to modify all modules implemented in C. I think that it should be marked as Final and mentionned in the changelog. http://www.python.org/dev/peps/pep-0436/ I need to clean it up and submit it for final inspection. This is on my to-do list for before 3.4.0 final. 2014-02-16 19:31 GMT+01:00 Larry Hastings la...@hastings.org: 1) We merge the Derby patch for the builtins module into 3.4, simply because it will demo well. Where is the issue to implement this feature? Anyway, I expect a huge patch which is non-trivial and so very risky for such a very important module :-/ It's too late IMO. http://bugs.python.org/issue20184 The point is that it *is* trivial and not particularly risky. Doing this right means that we execute essentially the same statements in the same order, merely split across two functions, and with a slightly different docstring. Literally the only detectable runtime difference that should exist after applying the patch is that the functions now publish docstrings. (Last docstrings should be introspectable signatures) The ones which weren't trivial, either won't be changed at all until 3.5 (with a comment in the existing patch explaining why not), or else have had their automated generation disabled after the initial conversion so I could move them back closer to their existing behaviour. I also discovered that gdb depends on the *exact* signature of the id() C API, but Argument Clinic was able to handle that. That said, I still recommend leaving this particular change until 3.4.1 at this stage of the release cycle - it's a nice-to-have, not a must have, and I think there are more important things to focus on right now (like handling any identified regressions relative to 3.3, since the release candidates see a higher level of third party testing than any of the earlier pre-releases). The current patch also can't be applied as is - it needs to be regenerated to account for the signature format change and to move the argument parsing helpers out to a separate file. Something I think we *should* do (and I'm willing to take care of) is update the What's New to say explicitly that adding programmatic introspection support to a function implemented in C is now considered a bug fix (as long as it can be done without changing semantics and the inspect module can handle it), and so more builtin and extension module APIs will start supporting that over the course of the 3.4.x series. I'll also find some already converted examples to include in the What's New description (relying on the converted builtin slots if I have to, but I suspect some better examples are already available, even without the builtins converted). Cheers, Nick. /arry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 18 Feb 2014 08:25, Nick Coghlan ncogh...@gmail.com wrote: On 17 Feb 2014 22:25, M.-A. Lemburg m...@egenix.com wrote: On 17.02.2014 13:12, Nick Coghlan wrote: On 17 Feb 2014 21:15, M.-A. Lemburg m...@egenix.com wrote: None is special in Python and has always (and intentionally) sorted before any other object. In data processing and elsewhere in Python programming, it's used to signal: no value available. This is the first I've ever heard of that sorting behaviour being an intentional feature, rather than just an artefact of Python 2 allowing arbitrarily ordered comparisons between different types. Can you point me to the relevant entry in the Python 2 language reference? This is not documented anywhere in the language spec, AFAIK. It is documented in the code (Python 2.7; Object/object.c): default_3way_compare(PyObject *v, PyObject *w) ... /* None is smaller than anything */ if (v == Py_None) return -1; if (w == Py_None) return 1; Note that it's not important whether None is smaller or greater than any other object. The important aspect is that it's sorting order is consistent and doesn't raise a TypeError when doing an ordered comparison with other objects. Thanks, that's enough to persuade me that it is a good idea to restore that behaviour (and make it an official part of the language spec) as part of the eliminate remaining barriers to migration from Python 2 effort in 3.5. It will mean that SQL sorting involving NULL values maps cleanly again, and it's easy enough to use any() to check that container doesn't contain None. Note that I sent this before reading Tim's reply regarding the origin of the Python 2 sorting behaviour, and Terry's point that the relevant Python 2 code lived in the legacy 3 way comparison fallback that was deliberately removed from 3.0. MAL's perspective does still at least mean I am only -0 rather than -1 on making None always sorts first rather than throwing an exception, but my preferred solution remains to provide backporting-friendly support for handling of None values in comparisons (and particularly sorting operations): http://bugs.python.org/issue20630 Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On Feb 18, 2014, at 08:25 AM, Nick Coghlan wrote: Thanks, that's enough to persuade me that it is a good idea to restore that behaviour (and make it an official part of the language spec) as part of the eliminate remaining barriers to migration from Python 2 effort in 3.5. At the very least, it's an idea worth PEP-ifying. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 2/17/2014 5:25 PM, Nick Coghlan wrote: On 17 Feb 2014 22:25, M.-A. Lemburg m...@egenix.com mailto:m...@egenix.com wrote: default_3way_compare(PyObject *v, PyObject *w) ... /* None is smaller than anything */ Unless it is not, as with datetimes, perhaps other classes written similarly, and some user class instances. Note that it's not important whether None is smaller or greater than any other object. The important aspect is that it's sorting order is consistent and doesn't raise a TypeError when doing an ordered comparison with other objects. Thanks, that's enough to persuade me that it is a good idea to restore that behaviour Would you restore the actual sometimes inconsistent 2.x behavior or implement something new -- what M-A claims but never was? I doubt the former would be trivial since it was part of the now deleted cmp and 3way machinery. To make None a true bottom object, the rich comparison methods would have to special-case None as either argument before looking at the __rc__ special methods of either. Regardless of how implemented, such a change would break user code that defines a Bottom class and depends on Bottom() None == True. Given the python-ideas discussions about adding a top or bottom class, I expect that such classes are in use. So a deprecation period would be needed, pushing the change off to 3.7. It is also possible that someone took the ending of cross-type comparisons seriously and is depending on the TypeError. while True: x = f(args) try: if x 10: a(x) else: b(x) except TypeError: # f did not return a number break -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/17/2014 03:20 PM, Victor Stinner wrote: 2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org: You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! Does it mean that the default branch is open for changes which target 3.4.1? Basically, yes. //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
[M.-A. Lemburg] ... None worked as compares less than all other objects simply due to the fact that None is a singleton and doesn't implement the comparison slots (which for all objects not implementing rich comparisons, meant that the fallback code triggered in Python 2). And the fallback code - which you've already found - went on to special-case the snot out of None to make less than work. It's not like it was a natural outcome: it was forced. In Python 3 the special casing was dropped and because None still doesn't implement the comparison slot (tp_richcompare this time), it doesn't support ordering comparisons anymore. Which makes mixed-type non-numeric default comparisons involving None work the same way all other mixed-type non-numeric default comparisons work in Python 3. This was the result of a deliberate design decision about how comparison _should_ work in Python 3, not an accidental consequence of the None type not defining tp_richcompare. IOW, this is about design, not about implementation. The differing implementations you see are consequences of the differing designs. Staring at the implementations is irrelevant to the design decisions. Now, the choice to have None compare less than all other objects may have been arbitrary, but IMO it was a good, consistent and useful choice. Possibly useful for some apps, sure. Not for my apps. For example, when I initialize an object attribute to None in Python 3, I _expect_ I'll get an exception if I try to use that attribute in most contexts. It makes no more sense to ask whether that attribute is, say, less than 3, than it does to add 3 to it. The exception is most useful then. More often than not, it was annoying to me that Python 2 _didn't_ whine about trying to compare None. So why not bring it back A huge barrier is (or should be) that Python 3 is over 5 years old now. Fiddling with the semantics of basic builtin types was possible - and even welcome - 6 years ago. Now they really shouldn't be touched in the absence of a critical bug, or a wholly backward-compatible (with Python 3) addition. and perhaps this time in a way that actually does work consistently for all Python objects by implementing the tp_richcompare slot on PyNoneType objects and documenting it ?! Something to suggest for Python 4, in which case I'll only be -0 ;-) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 2/17/2014 6:20 PM, Victor Stinner wrote: 2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org: You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! Does it mean that the default branch is open for changes which target 3.4.1? Presumably. That is what I started doing today. However, the top section of 3.4 News says 3.4.0rc2 rather than 3.4.1. It should be relabeled and a 3.4.0rc2 sections with items actually added to 3.4.0c2 (and those items should not be in the 3.4.1 section. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
Tim Peters wrote: Guido wanted to drop all the arbitrary but consistent mixed-type comparison crud for Python 3. Nobody is asking for a return to the arbitrary-but- [in]consistent mess of Python 2, only to bring back *one* special case, i.e. None comparing less than everything else. I think there is a reasonable argument to be made in favour of that. Like it or not, None does have a special place in Python as the one obvious way to represent a null or missing value, and often one wants to sort a collection of objects having keys that can take on null values. Refusing to make that easy seems like allowing purity to beat practicality. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
[Tim] Guido wanted to drop all the arbitrary but consistent mixed-type comparison crud for Python 3. [Greg Ewing] Nobody is asking for a return to the arbitrary-but- [in]consistent mess of Python 2, only to bring back *one* special case, i.e. None comparing less than everything else. Of course. My point was that dropping None comparisons wasn't specifically aimed at None comparisons. I think there is a reasonable argument to be made in favour of that. There may have been 6 years ago, but Python 3 isn't a thought experiment anymore. It was first released over 5 years ago, and has its own compatibility (with Python 3, not Python 2) constraints now. Like it or not, None does have a special place in Python as the one obvious way to represent a null or missing value, and often one wants to sort a collection of objects having keys that can take on null values. Perhaps that's often true of your code, but it's never been true of mine. Refusing to make that easy seems like allowing purity to beat practicality. Since I've never had a need for it, I can't say for sure whether or not it's easy - but the .sort() interface is rich enough that I almost always find even truly complex key transformations easy enough. Perhaps a real, concrete use case would help. I have a hard time imagining why I'd _want_ to sort a list of objects with null or missing keys, instead of filtering such garbage out of the list first and sorting what remains. But even with a compelling use case, I'd still think it's years too late to change this in Python 3. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Close #20656: Fix select.select() on OpenBSD 64-bit
On Mon, Feb 17, 2014 at 6:36 PM, victor.stinner
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/79ccf36b0fd0
changeset: 89239:79ccf36b0fd0
user:Victor Stinner victor.stin...@gmail.com
date:Tue Feb 18 01:35:40 2014 +0100
summary:
Close #20656: Fix select.select() on OpenBSD 64-bit
files:
Modules/selectmodule.c | 22 --
1 files changed, 12 insertions(+), 10 deletions(-)
This changeset caused a compile warning on 32-bit Windows:
..\Modules\selectmodule.c(238): warning C4244: '=' : conversion from
'time_t' to 'long', possible loss of data
[P:\ath\to\cpython\PCbuild\select.vcxproj]
diff --git a/Modules/selectmodule.c b/Modules/selectmodule.c
--- a/Modules/selectmodule.c
+++ b/Modules/selectmodule.c
@@ -212,11 +212,18 @@
return NULL;
}
else {
-#ifdef MS_WINDOWS
+/* On OpenBSD 5.4, timeval.tv_sec is a long.
+ * Example: long is 64-bit, whereas time_t is 32-bit. */
time_t sec;
-if (_PyTime_ObjectToTimeval(tout, sec, tv.tv_usec,
+/* On OS X 64-bit, timeval.tv_usec is an int (and thus still 4
+ bytes as required), but no longer defined by a long. */
+long usec;
+if (_PyTime_ObjectToTimeval(tout, sec, usec,
_PyTime_ROUND_UP) == -1)
return NULL;
+#ifdef MS_WINDOWS
+/* On Windows, timeval.tv_sec is a long (32 bit),
+ * whereas time_t can be 64-bit. */
assert(sizeof(tv.tv_sec) == sizeof(long));
#if SIZEOF_TIME_T SIZEOF_LONG
if (sec LONG_MAX) {
@@ -225,16 +232,11 @@
return NULL;
}
#endif
-tv.tv_sec = (long)sec;
#else
-/* 64-bit OS X has struct timeval.tv_usec as an int (and thus still 4
- bytes as required), but no longer defined by a long. */
-long tv_usec;
-if (_PyTime_ObjectToTimeval(tout, tv.tv_sec, tv_usec,
-_PyTime_ROUND_UP) == -1)
-return NULL;
-tv.tv_usec = tv_usec;
+assert(sizeof(tv.tv_sec) = sizeof(sec));
#endif
+tv.tv_sec = sec;
This is the offending line.
I'm not sure how best to fix it, so I'm just pointing it out :)
--
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
Terry Reedy wrote: To make None a true bottom object, the rich comparison methods would have to special-case None as either argument before looking at the __rc__ special methods of either. I don't think it would be necessary to go that far. It would be sufficient to put the special case *after* giving both operations a chance to handle the operation via the type slots. Well-behaved objects generally wouldn't go out of their way to defeat that, but they could do so if necessary, e.g. to create a Bottom() that compares less than None. Although once None becomes usable as a bottom in most cases, there shouldn't be much need for people to introduce their own bottoms. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
Tim Peters wrote:
[Greg Ewing]
often
one wants to sort a collection of objects having
keys that can take on null values.
Perhaps that's often true of your code, but it's never been true of mine.
It's fairly common in accounting circles. I have a
collection of invoices, each of which can have a due
date specified, but doesn't have to. I want to sort
the invoices by due date. It's not particularly
important whether the missing dates sort first or
last, but it *is* important that the sort *not blow
up*.
Dates seem to be a particularly irksome case. Here's
one suggestion from StackOverflow for dealing with
the problem:
import datetime
mindate = datetime.date(datetime.MINYEAR, 1, 1)
def getaccountingdate(x):
return x['accountingdate'] or mindate
results = sorted(data, key=getaccountingdate)
That's a ridiculous amount of boilerplate for doing
something that ought to be straightforward.
If you don't want to touch comparison in general,
how about an option to sort()?
results = sorted(invoices, key=attrgetter('duedate'), none='first')
I have a hard time
imagining why I'd _want_ to sort a list of objects with null or
missing keys, instead of filtering such garbage out of the list first
A piece of data is *not* garbage just because an optional
part of it is not specified.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
