Re: [Python-Dev] The fate of the -U option
On Feb 03, 2010, at 09:55 AM, Guido van Rossum wrote: >On Wed, Feb 3, 2010 at 9:09 AM, Barry Warsaw wrote: >> -snip snip- >> from __future__ import unicode_literals >> >> def func(foo, bar): >> print foo, bar >> >> kw = {'foo': 7, 'bar': 9} >> func(**kw) >> -snip snip- >> >> That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and >> feasible to back port that to Python 2.6? I remember talking about this a >> while back but I don't remember what we decided and I can't find a bug on the >> issue. > >I don't know about feasible but I think it's (borderline) appropriate. >There are various other paths that lead to this error and it feels to >me it's just a long-standing bug that we never took care of until 2.7. >However, I don't think it needs to support non-ASCII characters in the >keywords (even though 2.7 does seem to support those). The back port from trunk of r68805 to fix this was really pretty trivial. http://bugs.python.org/issue4978 http://bugs.python.org/file16124/py26-backport.patch Assigned to Benjamin for review. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of the -U option
On Wed, Feb 3, 2010 at 12:00 PM, "Martin v. Löwis" wrote: >>> That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and >>> feasible to back port that to Python 2.6? I remember talking about this a >>> while back but I don't remember what we decided and I can't find a bug on >>> the >>> issue. >> >> I don't know about feasible but I think it's (borderline) appropriate. > > I fail to see the point there as well. There will be about two more 2.6 > releases until we stop fixing bugs in it, and start recommending 2.7. > > So who would be helped if such a feature would be added to 2.6? Presumably the people who asked for it want it. Regardless of what you (or I) recommend, 2.6 will be in use for a long time. >> There are various other paths that lead to this error and it feels to >> me it's just a long-standing bug that we never took care of until 2.7. >> However, I don't think it needs to support non-ASCII characters in the >> keywords (even though 2.7 does seem to support those). > > Is it really necessary to ban them? No, that's not what I meant -- I just meant that it wasn't necessary to support non-ASCII if it would in any way complicate the patch. > In the regular keyword argument > syntax (arg=value), the lexer will reject them. If you pass them through > a dictionary, why go through the dictionary and ban those that you don't > like? If the callee also uses the **kw syntax, they may actually be able > to receive them. > > Notice that this works also in 2.5: > > py> def foo(**kw):pass > ... > py> foo(**{'':None}) > py> foo(**{'\0':None}) OTOH a more conservative solution would convert the keywords to str instances so that the receiving end (the body of foo) would never see Unicode objects even while allowing (some) Unicode objects on the sending end (foo's caller). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of the -U option
>> That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and >> feasible to back port that to Python 2.6? I remember talking about this a >> while back but I don't remember what we decided and I can't find a bug on the >> issue. > > I don't know about feasible but I think it's (borderline) appropriate. I fail to see the point there as well. There will be about two more 2.6 releases until we stop fixing bugs in it, and start recommending 2.7. So who would be helped if such a feature would be added to 2.6? > There are various other paths that lead to this error and it feels to > me it's just a long-standing bug that we never took care of until 2.7. > However, I don't think it needs to support non-ASCII characters in the > keywords (even though 2.7 does seem to support those). Is it really necessary to ban them? In the regular keyword argument syntax (arg=value), the lexer will reject them. If you pass them through a dictionary, why go through the dictionary and ban those that you don't like? If the callee also uses the **kw syntax, they may actually be able to receive them. Notice that this works also in 2.5: py> def foo(**kw):pass ... py> foo(**{'':None}) py> foo(**{'\0':None}) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of the -U option
On Wed, Feb 3, 2010 at 9:09 AM, Barry Warsaw wrote: > On Feb 03, 2010, at 04:21 PM, M.-A. Lemburg wrote: > >>exar...@twistedmatrix.com wrote: >>> On 02:52 pm, m...@egenix.com wrote: Note that in Python 2.7 you can use from __future__ import unicode_literals on a per module basis to achieve much the same effect. >>> >>> In Python 2.6 as well. >> >>Right, but there are a few issues in 2.6 that will be fixed >>in 2.7. > > The one that bites me most often is that in 2.6, keyword arguments must be > strs; unicodes are not accepted: > > -snip snip- > from __future__ import unicode_literals > > def func(foo, bar): > print foo, bar > > kw = {'foo': 7, 'bar': 9} > func(**kw) > -snip snip- > > That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and > feasible to back port that to Python 2.6? I remember talking about this a > while back but I don't remember what we decided and I can't find a bug on the > issue. I don't know about feasible but I think it's (borderline) appropriate. There are various other paths that lead to this error and it feels to me it's just a long-standing bug that we never took care of until 2.7. However, I don't think it needs to support non-ASCII characters in the keywords (even though 2.7 does seem to support those). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of the -U option
On Feb 03, 2010, at 04:21 PM, M.-A. Lemburg wrote: >exar...@twistedmatrix.com wrote: >> On 02:52 pm, m...@egenix.com wrote: >>> >>> Note that in Python 2.7 you can use >>> >>> from __future__ import unicode_literals >>> >>> on a per module basis to achieve much the same effect. >> >> In Python 2.6 as well. > >Right, but there are a few issues in 2.6 that will be fixed >in 2.7. The one that bites me most often is that in 2.6, keyword arguments must be strs; unicodes are not accepted: -snip snip- from __future__ import unicode_literals def func(foo, bar): print foo, bar kw = {'foo': 7, 'bar': 9} func(**kw) -snip snip- That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and feasible to back port that to Python 2.6? I remember talking about this a while back but I don't remember what we decided and I can't find a bug on the issue. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of the -U option
On Feb 03, 2010, at 11:10 PM, Nick Coghlan wrote: >Ripping it out is probably a reasonable idea given that there is a much >better approach available now (i.e. trying to run under Py3k) that >actually has a vague hope of working. > >Then again, if 2.7 really is the last non-maintenance 2.x release, >what's to be gained by messing with it? Well, in case we decide to do it, this bug tracks that effort: http://bugs.python.org/issue7847 -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of the -U option
exar...@twistedmatrix.com wrote: > On 03:21 pm, m...@egenix.com wrote: >> exar...@twistedmatrix.com wrote: >>> On 02:52 pm, m...@egenix.com wrote: Note that in Python 2.7 you can use from __future__ import unicode_literals on a per module basis to achieve much the same effect. >>> >>> In Python 2.6 as well. >> >> Right, but there are a few issues in 2.6 that will be fixed >> in 2.7. > > Ah. I don't see anything on the "What's New" page. Got a link? http://mail.python.org/pipermail/python-dev/2009-January/085110.html http://bugs.python.org/issue4978 and related: http://bugs.python.org/issue2931 http://bugs.python.org/issue4319 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new 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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of the -U option
On 03:21 pm, m...@egenix.com wrote: exar...@twistedmatrix.com wrote: On 02:52 pm, m...@egenix.com wrote: Note that in Python 2.7 you can use from __future__ import unicode_literals on a per module basis to achieve much the same effect. In Python 2.6 as well. Right, but there are a few issues in 2.6 that will be fixed in 2.7. Ah. I don't see anything on the "What's New" page. Got a link? Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of the -U option
exar...@twistedmatrix.com wrote: > On 02:52 pm, m...@egenix.com wrote: >> >> Note that in Python 2.7 you can use >> >> from __future__ import unicode_literals >> >> on a per module basis to achieve much the same effect. > > In Python 2.6 as well. Right, but there are a few issues in 2.6 that will be fixed in 2.7. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new 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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of the -U option
On 02:52 pm, m...@egenix.com wrote: Note that in Python 2.7 you can use from __future__ import unicode_literals on a per module basis to achieve much the same effect. In Python 2.6 as well. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The fate of the -U option
Nick Coghlan wrote: > Barry Warsaw wrote: >> On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote: >> >>> We deliberate don't document -U because its typical effect is "break the >>> world" - it makes all strings unicode in 2.x. It only affects string literals, not all strings. >> As an aside, I think this should be documented *somewhere* other than just in >> import.c! I'd totally forgotten about it until I read the source and almost >> missed it. Either it should be documented or it should be ripped out. > > Ripping it out is probably a reasonable idea given that there is a much > better approach available now (i.e. trying to run under Py3k) that > actually has a vague hope of working. > > Then again, if 2.7 really is the last non-maintenance 2.x release, > what's to be gained by messing with it? Nothing much, but then it's been undocumented for a number of releases in order to be able to remove it at some point, so +1 to get rid off it for 2.7. Note that in Python 2.7 you can use from __future__ import unicode_literals on a per module basis to achieve much the same effect. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new 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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] The fate of the -U option
Barry Warsaw wrote: > On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote: > >> We deliberate don't document -U because its typical effect is "break the >> world" - it makes all strings unicode in 2.x. > > As an aside, I think this should be documented *somewhere* other than just in > import.c! I'd totally forgotten about it until I read the source and almost > missed it. Either it should be documented or it should be ripped out. Ripping it out is probably a reasonable idea given that there is a much better approach available now (i.e. trying to run under Py3k) that actually has a vague hope of working. Then again, if 2.7 really is the last non-maintenance 2.x release, what's to be gained by messing with it? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com