Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16676
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16659
___
New submission from anatoly techtonik:
This following recipe from Optik examples should be added to documentation. It
is extremely helpful when porting to optparse from getopt or other option
parsing schemes.
--
assignee: docs@python
components: Documentation
messages: 177447
nosy:
Changes by anatoly techtonik techto...@gmail.com:
Added file: http://bugs.python.org/file28307/pass_through.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16678
___
anatoly techtonik added the comment:
It allows to port options to and from optparse incrementally.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16678
___
New submission from Claude Paroz:
In wsgiref/simple_server.py (WSGIRequestHandler.get_environ), Python 3 is
currently populating the env['PATH_INFO'] variable by decoding the URL path,
assuming it was encoded with 'iso-8859-1', which appears to be wrong, according
to RFC 3986/3987.
For
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16447
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16576
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16575
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14894
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16601
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16631
___
Graham Dumpleton added the comment:
The requirement per PEP is that the original byte string needs to be
converted to native string (Unicode) with the ISO-8891-1 encoding. This is to
ensure that the original bytes are preserved so that the WSGI application, with
its own knowledge of what
Changes by Berker Peksag berker.pek...@gmail.com:
--
versions: +Python 3.4 -Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16679
___
___
Claude Paroz added the comment:
Attached are my proposed changes.
Also, I just came across http://bugs.python.org/issue3300, which finally led
Python urllib.parse.quote to default to UTF-8 encoding, after a lengthy
discussion.
--
keywords: +patch
Added file:
New submission from Kristján Valur Jónsson:
socket._fileobject supports line buffering for output with the bufsize=1
option. Unfortunately, it is broken and behaves like no buffering. This patch
remedies the situation.
--
components: Library (Lib)
files: _fileobject.diff
keywords:
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +chris.jerdonek, ezio.melotti
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16677
___
Graham Dumpleton added the comment:
You can't try UTF-8 and then fall back to ISO-8859-1. PEP requires it
always be ISO-8859-1. If an application needs it as something else, it is the
web applications job to do it.
The relevant part of the PEP is:
On Python platforms where the str or
Changes by Berker Peksag berker.pek...@gmail.com:
--
title: Line buffering in socket._fileobject is borken - Line buffering in
socket._fileobject is broken
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16680
Kristján Valur Jónsson added the comment:
http://www.urbandictionary.com/define.php?term=borken
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16680
___
Ezio Melotti added the comment:
irker test
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2771
___
___
Python-bugs-list mailing list
Charles-François Natali added the comment:
It's a duplicate, otherwise the patch LGTM.
--
nosy: +neologix
resolution: - duplicate
stage: - committed/rejected
status: open - closed
superseder: - socket line buffering
___
Python tracker
Claude Paroz added the comment:
I may understand your reasoning when you cannot make any assumptions about the
encoding of a series of bytes.
I think that the case of PATH_INFO is different, because it should comply with
standards, and then you *can* make the assumption that the original path
Kristján Valur Jónsson added the comment:
Here's a patch for the current 2.7 stuff, from issue #16680 (which was deemed
duplicate).
Unless anyone objects, I'll commit that to 2.7 soon. Eight years, this has
taken.
--
keywords: +patch
nosy: +kristjan.jonsson
Added file:
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16676
___
___
Python-bugs-list mailing list
Trent Nelson added the comment:
On Thu, Dec 13, 2012 at 10:28:00PM -0800, Ned Deily wrote:
Ned Deily added the comment:
Without having reviewed the proposed change in detail, a couple of
comments. On current OS X systems and others, the compiler could be
clang which perhaps should be
R. David Murray added the comment:
We aren't encouraging people to use optparse any more. The recipe isn't needed
in argparse, as that has a parse_known_args method that achieves the same end.
--
nosy: +r.david.murray
___
Python tracker
Andrew Svetlov added the comment:
Committed. Sorry for delay.
Thanks, Vaclav!
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16421
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16377
___
___
Python-bugs-list mailing list
Roundup Robot added the comment:
New changeset 6eefe4d537b3 by Andrew Svetlov in branch 'default':
Issue #16421: allow to load multiple modules from the same shared object.
http://hg.python.org/cpython/rev/6eefe4d537b3
--
nosy: +python-dev
___
Python
Andrew Svetlov added the comment:
The error can be reproduced for 2.7 and 3.2.
Starting from 3.3 os.error and IOError both aliases for OSError and patch
doesn't needed.
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Would be nice to add a test...
--
nosy: +pitrou
versions: -Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue879399
___
Robin Schreiber added the comment:
Patch updated to work with current 3.4 Branch version of elementtree.
--
keywords: +patch
Added file: http://bugs.python.org/file28311/_elementtree_pep3121-384_v1.patch
___
Python tracker rep...@bugs.python.org
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16619
___
___
Python-bugs-list
STINNER Victor added the comment:
Some tests are failing since the changeset 6eefe4d537b3.
Example:
http://buildbot.python.org/all/builders/x86%20RHEL%206%203.x/builds/1431/steps/test/logs/stdio
Please check buildbots.
[176/371] test_pkgutil
test_getdata_filesys
Jason Huntley added the comment:
I'm attempting to build Python-3.3.0 with mingw64. I get a minute or two into
the build and fail with this error:
./Include/pythonrun.h:178:1: warning: function declaration isn't a prototype [-W
strict-prototypes]
./Modules/getpath.c: In function 'isfile':
Serhiy Storchaka added the comment:
Thanks, Anatoly. I see an actual bug. FindFirstFile and FindNextFile return
broken name if file unicode name can't be represented in current codepage.
I don't know what is perfect solution for this issue.
On 2.7 we can decode listdir() argument to unicode
Pander added the comment:
Please, also consider reviewing functionality offered by:
http://pypi.python.org/pypi/unicodescript/
and
http://pypi.python.org/pypi/unicodeblocks/
which could be used to improve and extend the proposed patch.
--
nosy: +PanderMusubi
Giampaolo Rodola' added the comment:
I don't think it is worth complicating the API for this. There have
been zero requests for this functionality. Even the doc field of
property() is rarely used.
+1
--
nosy: +giampaolo.rodola
___
Python
Kristján Valur Jónsson added the comment:
Good point, will do.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue879399
___
___
Python-bugs-list
R. David Murray added the comment:
That's what surrogateescape is for, on linux. I thought Victor dealt with this
a different way in Windows. Maybe by deprecating the bytes interface :)
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
Changes by Mark Shannon m...@hotpy.org:
--
nosy: +Mark.Shannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16676
___
___
Python-bugs-list
New submission from Pander:
Documentation in
docs.python.org/3/library/unicodedata.html
on 'bidirectional category' should be 'bidirectional class' in unicodedata
package. Please see
www.unicode.org/Public/UNIDATA/PropertyValueAliases.txt
where only bidirectional class is being referred to.
New submission from Serhiy Storchaka:
The audioop module documentation says that functions works with Python strings.
This was right in 2.x, but in 3.x here should be bytes objects (actually the
functions accept strings too, but this is an implementation detail, meaningless
in general).
Changes by Serhiy Storchaka storch...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file28312/audioop_docs_bytes.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16682
New submission from Serhiy Storchaka:
Functions in the audioop module documentation enumerated in alphabetic order.
Only one function out of order. Here is a patch that fixes this.
--
assignee: docs@python
components: Documentation
files: audioop_docs_resort.patch
keywords: patch
New submission from Pander:
The package unicodedata
http://docs.python.org/3/library/unicodedata.html
offers looking up of property values in terms of general category,
bidirectional class and east asian width for Unicode characters
unicodedata.category(unichr)
New submission from Serhiy Storchaka:
Inadvertently strings accepted as arguments of audioop functions. This is a
meaningless behavior and remnant of Python 2. We should drop string support.
--
components: Extension Modules
messages: 177477
nosy: serhiy.storchaka
priority: normal
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16685
___
___
Python-bugs-list
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15651
___
Serhiy Storchaka added the comment:
Surrogateescape is for non-decodable names. Here we have a problem with
non-encodable names.
I know that naive approach with using only Unicode API inside is not work
because Windows use complex logic for filename encoding (for example dropping
Ezio Melotti added the comment:
for certain applications it is important to be able to get the from
abbreviated name to the long name and vice versa.
What kind of application? I have a module where I defined my own dict that
maps categories with their full names, but I'm not sure this
Éric Araujo added the comment:
Patch contains unrelated changes.
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16626
___
___
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16685
___
___
Python-bugs-list mailing list
Roundup Robot added the comment:
New changeset 02de73bae814 by Ezio Melotti in branch '2.7':
#16681: use bidirectional class instead of bidirectional category.
http://hg.python.org/cpython/rev/02de73bae814
New changeset 97688292bfe5 by Ezio Melotti in branch '3.2':
#16681: use bidirectional
Ezio Melotti added the comment:
Fixed, thanks for the report!
--
assignee: - ezio.melotti
components: +Documentation
resolution: - fixed
stage: - committed/rejected
status: open - closed
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 -Python 3.5
New submission from Serhiy Storchaka:
The audioop module has some issues with an overflow.
1. It uses post-checks for an integer overflow. This means using an undefined
behavior.
2. When the result truncated in case of overflow, -maxval used as minimal
value. But real minimum value is less
Roundup Robot added the comment:
New changeset e451901e6243 by Ezio Melotti in branch '2.7':
#16683: restore alphabetical order in audioop docs. Patch by Serhiy Storchaka.
http://hg.python.org/cpython/rev/e451901e6243
New changeset 5777ac884919 by Ezio Melotti in branch '3.2':
#16683: restore
Serhiy Storchaka added the comment:
Patch contains unrelated changes.
Sorry, my fault.
Here is a cleaned patch.
--
Added file: http://bugs.python.org/file28314/glob_magic_in_drive.patch
___
Python tracker rep...@bugs.python.org
Ezio Melotti added the comment:
Fixed, thanks for the report!
--
assignee: docs@python - ezio.melotti
nosy: +ezio.melotti
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Changes by Serhiy Storchaka storch...@gmail.com:
Removed file: http://bugs.python.org/file28221/glob_magic_in_drive.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16626
___
Ezio Melotti added the comment:
What happens if you pass strings?
If it doesn't work we can just fix it to raise an exception and stop returning
random results, if it works but bytes should be used instead, we should go
through a deprecation process.
--
nosy: +ezio.melotti
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16686
___
___
Python-bugs-list mailing list
Serhiy Storchaka added the comment:
What happens if you pass strings?
They are encoded with UTF-8. See 's#' and 's*' formats in PyArg_ParseTuple()
('y*' recommended for bytes).
--
___
Python tracker rep...@bugs.python.org
Robin Schreiber added the comment:
Updated patch to work with 3.4 Branch version of _struct.c
--
keywords: +patch
Added file: http://bugs.python.org/file28315/_struct_pep3121-384_v1.patch
___
Python tracker rep...@bugs.python.org
Robin Schreiber added the comment:
Updated parsermodule patch to work with 3.4 Branch version.
--
keywords: +patch
Added file: http://bugs.python.org/file28316/parser_pep3121-384_v1.patch
___
Python tracker rep...@bugs.python.org
Stefan Krah added the comment:
Robin, if you use ...
[diff]
git = on
... in your .hgrc, then the bug tracker will automatically generate
a Rietveld review link (At least I think that's what prevents links
from being generated).
--
nosy: +skrah
___
R. David Murray added the comment:
Ah, I misunderstood your comment.
So, listdir is returning the correct the filename, it's just that we can't
encode it to the console encoding. So, it is working as expected within the
current windows console limitations, if not in a particularly useful
Robin Schreiber added the comment:
Updated posixmodule to work with the 3.4 Branch version.
--
keywords: +patch
Added file: http://bugs.python.org/file28317/posix_pep3121-384_v1.patch
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
Ah, I misunderstood your comment.
Ah, you misunderstood my comment right now.
So, listdir is returning the correct the filename, it's just that we can't
encode it to the console encoding.
listdir() returns already irremediably broken filename (all
Changes by Serhiy Storchaka storch...@gmail.com:
--
title: os.walk ignores international dirs on Windows - os.listdir() returns
unusable bytes result on Windows
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16656
Stefan Krah added the comment:
Larry Hastings rep...@bugs.python.org wrote:
Finally, since you have not addressed it directly, let me ask you:
are you interested in Clinic having a more boilerplate-friendly macro
processing mode, with templates or recycling old entries or something?
Or do
R. David Murray added the comment:
Oh, I remember Victor complaining about that behavior of Windows. I'm pretty
sure it is the windows API and not python that is doing that mangling. But
Victor would know for sure.
--
___
Python tracker
Antoine Pitrou added the comment:
I'll ask again, do you plan to write a PEP to iron out the functional
details? I don't think a tracker entry is the right format for this.
Le vendredi 14 décembre 2012 à 07:21 +, Larry Hastings a écrit :
Larry Hastings added the comment:
I don't think
Éric Araujo added the comment:
I agree with David and suggest closing this as outdated. Thanks for the
suggestion nonetheless.
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16678
Larry Hastings added the comment:
I have no current plan to write a PEP. I don't know how to settle the
difference of opinion here; the easiest thing would be if you convinced Guido
we needed one.
--
___
Python tracker rep...@bugs.python.org
Gregory P. Smith added the comment:
There's a bit of an impasse here on the PEP front. Guido said it wasn't
needed. Antoine brings up the point that CPython developers will have to live
with the result of this work so maybe something more easy to read and see in
one place like a PEP would
Antoine Pitrou added the comment:
I have no current plan to write a PEP. I don't know how to settle the
difference of opinion here; the easiest thing would be if you
convinced Guido we needed one.
This is silly. Nobody is opposed to you writing a PEP and a couple
people would like you to do
Gregory P. Smith added the comment:
PEPs are perceived as a hurdle. Regardless, clinic.txt would turn into one
pretty easily so just doing it may be easiest. :)
On Fri, Dec 14, 2012 at 12:11 PM, Antoine Pitrou rep...@bugs.python.orgwrote:
Antoine Pitrou added the comment:
I have no
Larry Hastings added the comment:
I'm a little confused. FindFirstFile is an ANSI API, so we get a narrow string
back. We call PyBytes_FromString(), which expects a narrow string and returns
a bytes object. Who's trying (and failing) to encode the filename?
--
Andrew Svetlov added the comment:
+1 for closing as won't fix
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16678
___
___
Antoine Pitrou added the comment:
That said, I think a lot of that has been done if you look at the
clinic.txt file within the patch. That already contains the meat of
what would go into a PEP.
Certainly. A PEP doesn't have to be a 100% new text.
--
Pander added the comment:
The latest version of the respective sources can be found here:
https://github.com/ConradIrwin/unicodescript
and here:
https://github.com/simukis/unicodeblocks
--
___
Python tracker rep...@bugs.python.org
Changes by R. David Murray rdmur...@bitdance.com:
--
resolution: - out of date
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16678
___
New submission from Jeff Knupp:
Original text is:
Feeding string objects is to update is not supported
Should be ... objects in to update instead of is to
Also, mark GIL as a :term: to provide a link to its definition, as it's used
without much context in the following note:
.. note::
Changes by Jeff Knupp jkn...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15743
___
___
Serhiy Storchaka added the comment:
Who's trying (and failing) to encode the filename?
Windows. File created using Unicode API and stored UTF-16 encoded in
NTFS. Windows fails to represent this filename using ANSI API.
Here is a patch against 2.7 which always uses Unicode API in listdir()
and
Serhiy Storchaka added the comment:
I can't test (and even compile) the patch as I don't have a Windows,
please test it for me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16656
___
Pander added the comment:
I myself have a lot of Python applications that process font files and interact
with fonttools and FontForge, which are both written in Python too. As you also
have your own dict for this purpose and probably other people too, it would be
justified to add these three
STINNER Victor added the comment:
On Windows with Python 2, unencodable characters are replaced with ?. It is
the default behaviour of WideCharToMultiByte() and so all ANSI functions have
this behaviour. Python doesn't try to behave differently, it just exposes
system function as Python
Changes by STINNER Victor victor.stin...@gmail.com:
--
resolution: - wont fix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16656
___
___
STINNER Victor added the comment:
And this issue is only solved in Python 3...
Ooops, I mean: this issue is *already* solved in Python 3
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16656
STINNER Victor added the comment:
Accepting Unicode strings is surprising and must fail. I don't think that a
deprecation process is required here.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16685
Serhiy Storchaka added the comment:
For example, os.listdir(bytes) doesn't fail in Python 2.7 with unencodable
names, whereas it fails with your patch.
No. The purpose of this patch is that it doesn't fail and should return
a usable result.
--
Serhiy Storchaka added the comment:
Accepting Unicode strings is surprising and must fail. I don't think that a
deprecation process is required here.
Should it be fixed in 3.4 only or in all 3.x?
--
___
Python tracker rep...@bugs.python.org
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16612
___
Ezio Melotti added the comment:
The deprecation process can be avoided only if passing strings results in a
meaningless result. If there are cases where users are passing strings and
everything works fine -- even if they should be passing bytes instead -- we
should deprecate strings first to
Serhiy Storchaka added the comment:
In 2.x it was have a little sense (if you use some 8-bit encoding as default
encoding, but the default was 7-bit ascii). But with utf-8 it doesn't have
sense and should quickly lead to an unexpected result (or just fail in most
cases).
--
New submission from pyos:
The title says it all: if a regular expression that makes use of backreferences
is compiled with `re.I` flag, it will always fail when matched against a string
that contains characters outside of U+-U+00FF range. I've been unable to
further narrow the bug down.
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16688
___
___
Python-bugs-list
1 - 100 of 117 matches
Mail list logo
