Guido van Rossum added the comment:
Let's not do this. The time to meddle with Python 2.7 details is long gone.
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20015
Changes by Terry J. Reedy tjre...@udel.edu:
--
stage: patch review - resolved
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20015
___
___
Serhiy Storchaka added the comment:
What is your decision Guido and Benjamin?
--
nosy: +gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20015
___
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20015
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
Here is a patch with tests. Not all affected methods are tested because not all
methods and modules have tests at all.
--
Added file: http://bugs.python.org/file34284/getargs_c_unicode_2.patch
___
Python tracker
Antoine Pitrou added the comment:
This sounds reasonable to me, but the patch lacks tests.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20015
___
Antoine Pitrou added the comment:
However, do note that the semantics will end up different from other uses of
unicode. e.g.:
aa.strip(ub)
u'aa'
In str.strip(), passing an unicode parameter returns an unicode string. In
str.ljust(), passing an unicode parameter will return a byte string.
Terry J. Reedy added the comment:
The behavior of str.strip is not what I would expect from reading
'''str.strip([chars])
Return a copy of the string with the leading and trailing characters
removed.'''
but I guess it is consistent with a general rule that when mixing bytes and
unicode
Serhiy Storchaka added the comment:
However, do note that the semantics will end up different from other uses of
unicode. e.g.:
aa.strip(ub)
u'aa'
And this behavior is weird.
print 'À\n'.strip('\n')
À
print 'À\n'.strip(u'\n')
Traceback (most recent call last):
File stdin, line 1, in
Serhiy Storchaka added the comment:
Re-opened due to Python-Dev discussion
http://comments.gmane.org/gmane.comp.python.devel/146057.
--
resolution: invalid -
stage: committed/rejected - patch review
status: closed - open
___
Python tracker
Stefan Krah added the comment:
Well, generally I'd be against adding features, but this particular one
could be rationalized in the same way as PEP 414. So I'm simply unsure
whether the feature should be added, but *if* it's added, it should
be backed by a pronouncement either from the RM or
Terry J. Reedy added the comment:
PEP414 was about adding a feature to 3.3 well before the first alpha release.
What Guido has recently said about 2.7 is that after 3 1/2 years we should
concentrate on build issues such as came up with the new OSX and de-emphasize
or even cease fixing bugs.
Terry J. Reedy added the comment:
Victor and Stefan are correct. 2.7 is a fixed version of Python. CPython 2.7.z,
z = 1, only gets bug (and build) fixes. A 'new 2.7 version' would be 2.8,
which will not happen. The fact that you propose to change the unambiguous doc
shows that this is an
New submission from Serhiy Storchaka:
In most cases when str object required, unicode object is allowed too. s and
z codes (with modifiers) in PyArg_Parse*() accept both str and unicode
instances. But c code accepts only 1-character str, not unicode. This makes
harder writing version-agnostic
STINNER Victor added the comment:
I don't like the heuristic of ASCII only characters. Accepting that may lead
to bugs if later you pass a non-ASCII character.
And is it not too late to change that in Python 2.7? Version released 3 years
ago and widely used in production.
--
nosy:
Stefan Krah added the comment:
I guess it makes porting to Python 3 easier, but can we do this in a
stable release?
--
nosy: +benjamin.peterson, skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20015
Serhiy Storchaka added the comment:
I don't like the heuristic of ASCII only characters. Accepting that may
lead to bugs if later you pass a non-ASCII character.
What behavior you propose for non-ASCII values?
And is it not too late to change that in Python 2.7? Version released 3
years
17 matches
Mail list logo
