Mailman 3 December 2013 - docs

[issue19871] json module won't parse a float that starts with a decimal point
by Antoine Pitrou Dec. 3, 2013

Dec. 3, 2013

Changes by Antoine Pitrou <pitrou(a)free.fr>: ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19871> _______________________________________

1 0

[issue19871] json module won't parse a float that starts with a decimal point
by Antoine Pitrou Dec. 3, 2013

Dec. 3, 2013

Antoine Pitrou added the comment: I think it would be better to adhere to the JSON spec, which doesn't allow numbers to start with a decimal point: http://json.org/ If we go this way, the documentation should at least be fixed; and, as you say, we could also add a unit test for it. ---------- assignee: -> docs@python components: +Documentation, Tests -Library (Lib) nosy: +docs@python, pitrou stage: -> needs patch versions: -Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19871> _______________________________________

1 0

[issue19847] Setting the default filesystem-encoding
by Sworddragon Dec. 2, 2013

Dec. 2, 2013

Sworddragon added the comment: > This idea was already proposed in issue #8622, but it was a big fail. Not completely: If your locale is utf-8 and you want to operate on an utf-8 filesystem all is fine. But what if you want then to operate on a ntfs (non-utf-8) partition? As I know there is no way to apply Python-environment variables on the fly with an effect to the interpreter. In my opinion this is the reason why a setter is needed here. Otherwise the user has to go sure to use .encode() on all filesystem operations. Also he must ensure that .encode() doesn't throw any exception if the code must be robust. And with issue http://bugs.python.org/issue19846 this must likely be done with the content too. This will be really a hell in increasing the number of lines due to exception checking. Is there a special reason that is against such a setter? The current advantage would be a huge increasing in maintainability of Python scripts who are relying on a high stability. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19847> _______________________________________

1 0

[issue14787] pkgutil.walk_packages returns extra modules
by Martijn Faassen Dec. 2, 2013

Dec. 2, 2013

Martijn Faassen added the comment: I just ran into this bug myself with namespace packages (in Python 2.7). When you have multiple packages (ns.a, ns.b) under a namespace package (ns), and constrain the paths in walk_packages so it should only pick up ns.a, it will pick up ns.b as well. Any hope for a fix or workaround? ---------- nosy: +faassen _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14787> _______________________________________

1 0

[issue19847] Setting the default filesystem-encoding
by STINNER Victor Dec. 2, 2013

Dec. 2, 2013

STINNER Victor added the comment: "It is nice that you could fixed the documentation due to this report but this was just a sideeffect - so closing this report and moving it to "Documentation" was maybe wrong." Oh sorry, I read the issue too quickly, I stopped at the first sentence. I reopen the issue the reply to the other points. "In my opinion relying on the locale environment is risky since filesystem-encoding != locale. This is especially the case if working on a filesystem from an external media like an external hard disk drive. Operating on multiple media can also result in different filesystem-encodings." This issue is not specific to Python. If you mount an USB key formated in VFAT with the wrong encoding on Linux, you will get mojibake in your file explorer. Same issue if you connect a network share (ex: NFS) using a different encoding than the server. You can find many other examples (hint: Mac OS X and Unicode normalization). There is no good compromise here. The only two safe options are: (A) convert filenames of your filesystem to the same encoding than your computer (there are tools for that, like convmv) (B) use raw bytes instead of Unicode, Python 3 should accept bytes anywhere that OS data is expected (filenames, command line arguments, environment variables) All operating systems (except Windows) are now using UTF-8 by default for the locale encoding. So slowly, mojibake issues on filename should become very rare. "It would be useful if the user can make his own checks and change the default filesystem-encoding if needed." This idea was already proposed in issue #8622, but it was a big fail. Please read my following email for more information: https://mail.python.org/pipermail/python-dev/2010-October/104509.html ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19847> _______________________________________

1 0

[issue19847] Setting the default filesystem-encoding
by STINNER Victor Dec. 2, 2013

Dec. 2, 2013

STINNER Victor added the comment: (Oops, I specified the wrong issue number in my commits.) New changeset b231e0c3fd26 by Victor Stinner in branch '3.3': Issue #19728: Fix sys.getfilesystemencoding() documentation http://hg.python.org/cpython/rev/b231e0c3fd26 New changeset e3c48bddf621 by Victor Stinner in branch 'default': (Merge 3.3) Issue #19728: Fix sys.getfilesystemencoding() documentation http://hg.python.org/cpython/rev/e3c48bddf621 ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19847> _______________________________________

1 0

[issue19847] Setting the default filesystem-encoding
by Sworddragon Dec. 2, 2013

Dec. 2, 2013

Sworddragon added the comment: It is nice that you could fixed the documentation due to this report but this was just a sideeffect - so closing this report and moving it to "Documentation" was maybe wrong. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19847> _______________________________________

1 0

[issue19847] Setting the default filesystem-encoding
by STINNER Victor Dec. 2, 2013

Dec. 2, 2013

STINNER Victor added the comment: Code in Python 3.4. initfsencoding(): http://hg.python.org/cpython/file/e3c48bddf621/Python/pythonrun.c#l965 get_locale_encoding(): http://hg.python.org/cpython/file/e3c48bddf621/Python/pythonrun.c#l250 ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19847> _______________________________________

1 0

[issue19847] Setting the default filesystem-encoding
by STINNER Victor Dec. 2, 2013

Dec. 2, 2013

STINNER Victor added the comment: I fixed the documentation, thanks for your report! ---------- assignee: -> docs@python components: +Documentation -IO nosy: +docs@python resolution: -> fixed status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19847> _______________________________________

1 0

[issue16404] Uses of PyLong_FromLong that don't check for errors
by STINNER Victor Dec. 2, 2013

Dec. 2, 2013

Changes by STINNER Victor <victor.stinner(a)gmail.com>: ---------- nosy: +haypo _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16404> _______________________________________

1 0