[issue17429] platform.platform() can throw Unicode error
Roundup Robot added the comment: New changeset 4580976c07cb by Victor Stinner in branch '3.3': Issue #17429: platform.linux_distribution() now decodes files from the UTF-8 http://hg.python.org/cpython/rev/4580976c07cb New changeset 407f18c8ce8a by Victor Stinner in branch 'default': (Merge 3.3) Issue #17429: platform.linux_distribution() now decodes files from http://hg.python.org/cpython/rev/407f18c8ce8a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17429 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19771] runpy should check ImportError.name before wrapping it
Fotis Koutoulakis added the comment: Hello, I'm in the process of trying to find a solution to this problem, but I'm afraid the choice of wording at some point is kind of...ambiguous. I have some questions I want to ask, to clear some doubts in my head: First one is: if __main__ in a package throws ImportError, runpy will incorrectly report the package as not being directly executable (when it actually claims to be executable, it's just broken) In the above, from what I can understand from the first part of the sentence, before the paragraph, if __main__.py is not found in a package, run py will report that it won't be directly executable. Along these lines, it's mentioned that this behaviour is incorrect, but then the sentence inside the parentheses contradicts that position, suggesting that when it does suggest it's actually executable, it's just erroneous behaviour (so both behaviours are erroneous?) The second one is: This can be fixed in 3.3+ by checking for an appropriate value in the name attribute of the caught exception, and only wrapping it if the failed lookup was for the __main__ submodule we're looking for. Ok this seems to be pretty clear, we are expected to create a new package with a __main__.py that all it does is `raise ImportError`. (Disclaimer: I may be fairly wrong here). Question is, where should we put the new package? Obviously, we shouldn't litter the real modules, with the testing one, but if I try to use the test folder as a package, I get ImportError: error while finding loader for xxx Please be lenient with me, this is one of my very first contributions to python. I will gladly accept all feedback. -- nosy: +Fotis.Koutoulakis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19771 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17429] platform.platform() can throw Unicode error
Roundup Robot added the comment: New changeset 831b2c80a9c9 by Victor Stinner in branch 'default': Issue #17429: some PEP 8 compliance fixes for the platform modules, add whitespaces http://hg.python.org/cpython/rev/831b2c80a9c9 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17429 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17429] platform.platform() can throw Unicode error
STINNER Victor added the comment:
Thanks Toshio Kuratomi for your patch. I simplified the unit test. I'm not sure
that resetlocale restores the locale in its previous state. I don't want to
rely on two specific locales ('pt_BR.UTF8' and 'pt_BR.ISO8859-1') for a such
simple test. We have enough buildbots to test other various locales.
I prefered to only change minor syntax issues (PEP 8) in Python 3.4 to limit
changes in the stable release.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17429
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17429] platform.platform() can throw Unicode error
Roundup Robot added the comment: New changeset a951ab03bda0 by Victor Stinner in branch '3.3': Issue #17429: Oops, remove unused import http://hg.python.org/cpython/rev/a951ab03bda0 New changeset 209bf9576dc8 by Victor Stinner in branch 'default': (Merge 3.3) Issue #17429: Oops, remove unused import http://hg.python.org/cpython/rev/209bf9576dc8 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17429 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17429] platform.platform() can throw Unicode error
Changes by STINNER Victor victor.stin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17429 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17429] platform.linux_distribution() should decode files from UTF-8, not from the locale encoding
Changes by STINNER Victor victor.stin...@gmail.com: -- versions: -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17429 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17429] platform.linux_distribution() should decode files from UTF-8, not from the locale encoding
Changes by STINNER Victor victor.stin...@gmail.com: -- title: platform.platform() can throw Unicode error - platform.linux_distribution() should decode files from UTF-8, not from the locale encoding ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17429 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19904] Add 128-bit integer support to struct
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19830] test_poplib emits resource warning
Roundup Robot added the comment: New changeset 1e3c7153a14d by Victor Stinner in branch 'default': Fix #19830: Fix a ResourceWarning in test_poplib. http://hg.python.org/cpython/rev/1e3c7153a14d -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19830 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec)
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: -haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18864 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19830] test_poplib emits resource warning
STINNER Victor added the comment: The patch fixes the ResourceWarning, thanks. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19830 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19846] Setting LANG=C breaks Python 3
Antoine Pitrou added the comment: On dim., 2013-12-08 at 22:22 +, STINNER Victor wrote: (b) for technical reasons, Python reuses the C codec during Python initialization to decode and encode OS data, and so currently Python *must* use the locale encoding for its filesystem encoding Ahhh! Well indeed that's a bummer :-) asciilocale.patch has many issues. Try to run the Python test suite using this patch to see what I mean. I'm assuming much of this is due to (b) (all those tests seem to spawn external processes). It seems there is more work to do to get this right, but I'm not terribly interested either. Feel free to take over. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19893] Python cApi memory problem. Py_Initialize memory leak
STINNER Victor added the comment: Sorry, but I still don't understand this issue. Invalid read of size 4 is a known false positive. It can be worked around using ./configure --with-valgrind and the suppression list, or using ./configure --without-pymalloc. If you still get the warning, you used the wrong options or you are still using another Python binary (or shared library). Make sure that you are linked to your newly compiled shared library. valgrind --leak-check=full --log-file=valgrind.log ./python -c pass shows me possibly lost: 286,779 bytes in 654 blocks. This is also another known issue: Python doesn't release all the memory at exit, they are many singletons and variables initialized once but never released. The PEP 3121 helps this issue but the PEP is not fully implemented yet, many modules should still be modified. So what is your question? Do you think that Python leaks memory? Why do you think so? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19893 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19846] Setting LANG=C breaks Python 3
STINNER Victor added the comment: It seems there is more work to do to get this right, but I'm not terribly interested either. Feel free to take over. If you are talking to me: I'm currently opposed to change anything, so I'm not interested to work on a patch. IMO Python works fine and you should try to workaround the current limitations :-) If someone is interested to write an huge patch fixing all these issues, I would be able to reconsider my opinion on point (a). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19904] Add 128-bit integer support to struct
Fil Mackay added the comment: Stefan, performance is not the principle motivator here: the intention is that it is just sensible to support this integer type, just like supporting int64 since it is an intrinsic type supported by CPU's. Of course any integer length could be handled by memoryview unpacker, but this would not really make sense for int64. My view is that any intrinsic type (ie. register type) is the key point at which it should be supported by struct, and not a custom unpacker. 128/256/512 bit integers are in this category.. Principally this is so that it can be used by ctypes (see #19905). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19904] Add 128-bit integer support to struct
Antoine Pitrou added the comment: Of course any integer length could be handled by memoryview unpacker, but this would not really make sense for int64. My view is that any intrinsic type (ie. register type) is the key point at which it should be supported by struct, and not a custom unpacker. 128/256/512 bit integers are in this category.. I don't think register types matter here. The struct module provides interoperability with low-level *data types* (in C and other common languages), not CPU *registers*. So IMHO the question is whether there is an use case for 128-bit integers; *not* for arrays of four 32-bit integers packed in a 128-bit register. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19904] Add 128-bit integer support to struct
Fil Mackay added the comment: Antoine, No, the SIMD vector should be treated as a int128 (for eg.), not as 4 python ints. It is the unpacking process that unpacks into 4 python ints. The two shouldn't be confused - you definitely want to be able to treat the vector in both states (packed and unpacked). I'm not saying that Python should necessarily make use of SIMD instructions (don't think performance is critical there in py), but that it should at least be access to a raw 128/256/512 bit integer within a C structure. Part of this is interacting with SIMD'able structures - at least in my use cases :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19904] Add 128-bit integer support to struct
Antoine Pitrou added the comment: The two shouldn't be confused - you definitely want to be able to treat the vector in both states (packed and unpacked). Why do you need the packed state as a 128-bit int, rather than as a bytes object? You are not doing arithmetic on it, AFAIU. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19905] Add 128-bit integer support to ctypes
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19905 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19880] unittest: on failure, TestCase.run() keeps a reference to the exception
Roundup Robot added the comment: New changeset 09658ea0b93d by Victor Stinner in branch 'default': Close #19880: Fix a reference leak in unittest.TestCase. Explicitly break http://hg.python.org/cpython/rev/09658ea0b93d -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19880 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19876] selectors (and asyncio?): document behaviour on closed files/sockets
Roundup Robot added the comment: New changeset c4c1c4bc8086 by Victor Stinner in branch 'default': Issue #19876: Run also test_selectors.test_unregister_after_fd_close_and_reuse() on Windows http://hg.python.org/cpython/rev/c4c1c4bc8086 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19876 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19876] selectors (and asyncio?): document behaviour on closed files/sockets
STINNER Victor added the comment: Oops, I reverted my changeset c4c1c4bc8086, I didn't read why the test was skipped on Windows. Sorry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19876 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19876] selectors (and asyncio?): document behaviour on closed files/sockets
STINNER Victor added the comment: Except that it can fail with ENOENT, but also EBADF, and EPERM if the FD has been reused by a FD which doesn't support epoll. Oh, I didn't know that. I ran the unit test, and I expected the two unit test to cover any error case. So ignore my epoll_except.patch, the current except OSError: pass is correct. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19876 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19904] Add 128-bit integer support to struct
Fil Mackay added the comment: Antoine, I don't think register types matter here. The struct module provides interoperability with low-level *data types* (in C and other common languages), not CPU *registers*. OK, see where you're coming from. I guess my thinking was such that struct (and ctypes) support is required for data types that are common within C structures. The fact that 128-bit ints are now appearing within these structures is due to the fact that CPU support has dramatically improved, and are supported natively in register types. So it was kind of an indirect connection. So the question I guess is whether you think these types are common enough in C structs, which for me they certainly are for my data processing applications.. (pretty please :) So IMHO the question is whether there is an use case for 128-bit integers; *not* for arrays of four 32-bit integers packed in a 128-bit register. Agree completely - just stick to thinking about atomic 128-bit integers. A pack/unpack function should do the conversion, and have nothing to do with this struct support. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18576] Rename and document test.script_helper as test.support.script_helper
Fotis Koutoulakis added the comment: I have finished the changes needed to move script_helper from Lib/test to Lib/test/support, and I have also documented it. Tests run gracefully (but be sure to check out if it works as intended on your machines too) Two notes though: 1. I have only made the changes on the default branch. Will do 3.3 tomorrow. 2. When it came to the documentation, I had to break the 80 characters limit, as going by it was resulting in weird rendering or wrong information depicted from sphinx (for example, when showing that script_helper functions belonged to test.support instead of the correct location, test.support.script_helper). Last but not least, this is one of my first contributions to Python, so I would appreciate your input. -- keywords: +patch nosy: +Fotis.Koutoulakis Added file: http://bugs.python.org/file33049/script_helper-default.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18576 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19771] runpy should check ImportError.name before wrapping it
Nick Coghlan added the comment:
By providing a __main__.py submodule, a package is saying I am directly
executable. When runpy says it isn't (because running that file happened to
raise ImportError), then runpy is wrong.
runpy can't make the file work (it's genuinely broken), but it can avoid
reporting a misleading error message - that's the bug to be fixed.
As far as the testing goes, if you look at the existing runpy tests, the usual
approach is to create a temporary directory, write out a package with the
desired behaviour, and then run it from there. So, for this test, it's a matter
of copying the general structure of the existing package execution test in
test_runpy, but replacing the body of the __main__.py file with something like
raise ImportError('This should not be replaced')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19771
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19846] Setting LANG=C breaks Python 3 on Linux
Nick Coghlan added the comment: End users tripping over this by setting LANG=C is one of the pain points of Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora folks to the nosy list. My current understanding of the situation: - we should leave Windows and Mac OS X alone, since they ignore the locale when choosing the OS API encoding anyway - the main problem is on Linux (but potentially other *nix systems as well), where people set LANG=C for a variety of reasons, but this has the side effect of Python 3 choosing an inappropriate encoding (ASCII rather than UTF-8) when talking to the OS APIs. Given the initialisation problems, this may be something that PEP 432 (the initialisation process rewrite) can help with (since it changes the initialisation order to create a more complete Python runtime before it starts to configure the OS interfaces). Tangentially related, we may want to consider aliasing sys.getfilesystemencoding, os.fsencode and os.fsdecode as something like sys.getosapiencoding, os.apiencode and os.apidecode, since the current naming is misleading (the value is based on the platform and environment, not any particular filesystem, and is used for almost all bytes-based OS APIs, not just filesystem metadata) -- nosy: +a.badger, bkabrda title: Setting LANG=C breaks Python 3 - Setting LANG=C breaks Python 3 on Linux ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18576] Rename and document test.script_helper as test.support.script_helper
Nick Coghlan added the comment: I wouldn't worry about 3.3 at this point - the 3.3 test suite isn't going to see major changes for its final release, so the risk of merge conflicts is low. -- versions: -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18576 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18576] Rename and document test.script_helper as test.support.script_helper
Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: docs@python - ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18576 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15403] Refactor package creation support code into a common location
Nick Coghlan added the comment: I took a look at this last night, and found the combination of moving stuff around *and* refactoring it at the same time was too hard to review. So, once the PEP 451 changes for runpy are done, I think it would make more sense to tackle this as at least three patches: 1. Do the refactoring *within* test_runpy to make the helper API a bit cleaner (this should also use types.SimpleNamespace where appropriate rather than a custom alternative) 2. Move the helper API out to a documented test.support.package_helper module without altering the test.support API 3+. Refactor other test modules to use the now shared API (there may be some pkg related functionality to move out of script_helper as well). -- dependencies: +Rename and document test.script_helper as test.support.script_helper, Update runpy for PEP 451 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15403 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19846] Setting LANG=C breaks Python 3 on Linux
STINNER Victor added the comment: End users tripping over this by setting LANG=C is one of the pain points of Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora folks to the nosy list. Sorry, I'm not aware of such issue. Do you have examples? - the main problem is on Linux (but potentially other *nix systems as well), where people set LANG=C for a variety of reasons, but this has the side effect of Python 3 choosing an inappropriate encoding (ASCII rather than UTF-8) when talking to the OS APIs. Why do you think that the issue is specific to Python 3? Try to open a terminal with LC_ALL=C and try to type non-ASCII characters with your keyboard. You can't because your terminal uses ASCII. Did you applications written in another language handling Unicode, like Perl? (Perl with Unicode support correctly enabled, it's use utf8; if I remember correctly). Can you explain the various reasons why users explictly force the encoding to ASCII? I use LANG=C to get manual pages and error messages in english. But LANG=en_US man ls would be more correct, or LC_MESSAGES=en_US man ls to be pedantic. (Env var priority: LC_ALL LANG LC_xxx). IMO if you use LANG=C, you must not complain that Unicode stopped working, but you should learn how to configure locales. Trivial examples like the one which can be found in the initial message (msg204849) are wrong: why would you force all locales to C and use non-ASCII characters? Given the initialisation problems, this may be something that PEP 432 (the initialisation process rewrite) can help with (since it changes the initialisation order to create a more complete Python runtime before it starts to configure the OS interfaces). I don't see how it would help to solve my point (b). Technically, this issue cannot be fixed. Or to be more specific, I don't want to fix it, it's a waste of time. So I don't understand what do you expect from this open issue? I would prefer to close it as invalid or wontfix to be clear. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16099] robotparser doesn't support request rate and crawl delay parameters
Berker Peksag added the comment: I left a few comments on Rietveld. -- nosy: +berker.peksag versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19846] Setting LANG=C breaks Python 3 on Linux
Nick Coghlan added the comment: On 9 December 2013 12:08, STINNER Victor rep...@bugs.python.org wrote: STINNER Victor added the comment: End users tripping over this by setting LANG=C is one of the pain points of Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora folks to the nosy list. Sorry, I'm not aware of such issue. Do you have examples? Armin's travails with remote shell access and Python 3 are just as likely today as they were a couple of years ago: http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/ (although technically that was a terminal ending up with the POSIX locale, rather than specifically LANG=C) - the main problem is on Linux (but potentially other *nix systems as well), where people set LANG=C for a variety of reasons, but this has the side effect of Python 3 choosing an inappropriate encoding (ASCII rather than UTF-8) when talking to the OS APIs. Why do you think that the issue is specific to Python 3? Try to open a terminal with LC_ALL=C and try to type non-ASCII characters with your keyboard. You can't because your terminal uses ASCII. Did you applications written in another language handling Unicode, like Perl? (Perl with Unicode support correctly enabled, it's use utf8; if I remember correctly). It's the fact this used to work transparently in Python 2 (since all these interfaces were just bytes based on the Python side as well) that's a problem. That makes the new sensitivity to the locale encoding a usability regression, and that's a concern for distros that are considering switching their default Python version. Can you explain the various reasons why users explictly force the encoding to ASCII? - testing applications for POSIX compliance - default settings on servers where you don't control the environment - because they never previously had to care, and it's only Python 3 deciding to pay attention to it which makes it relevent for them I use LANG=C to get manual pages and error messages in english. But LANG=en_US man ls would be more correct, or LC_MESSAGES=en_US man ls to be pedantic. (Env var priority: LC_ALL LANG LC_xxx). IMO if you use LANG=C, you must not complain that Unicode stopped working, but you should learn how to configure locales. Trivial examples like the one which can be found in the initial message (msg204849) are wrong: why would you force all locales to C and use non-ASCII characters? And yet, in Python 2, people could do that, and Python didn't care. *That's* the regression I'm worried about. If it hadn't round-tripped cleanly in Python 2, I wouldn't care here either. Given the initialisation problems, this may be something that PEP 432 (the initialisation process rewrite) can help with (since it changes the initialisation order to create a more complete Python runtime before it starts to configure the OS interfaces). I don't see how it would help to solve my point (b). Having a Python runtime available makes things that are currently tediously painful to deal with during startup easier to tweak. I'm not sure it *will* help in this particular case, but it's now one I'm going to keep an eye on. Technically, this issue cannot be fixed. Or to be more specific, I don't want to fix it, it's a waste of time. So I don't understand what do you expect from this open issue? A way to get Python 3 to cope as well with a misconfigured OS environment as Python 2 did. I would prefer to close it as invalid or wontfix to be clear. It's a usability regression from Python 2, so I don't want to give up on it. It may be that we just implement a ignore what the OS claims, it's misconfigured, just use UTF-8 for everything flag. But OS configuration errors shouldn't cripple the Python runtime. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19915] int.bit_at(n) - Accessing a single bit in O(1)
Tim Peters added the comment: @serhiy, Mark certainly knows the proposed addition isn't _needed_ to pick apart 64-bit integers. It's an issue there of clarity, not O() behavior. For example, `i.bits_at(0, 52)` to get at a double's mantissa requires no thought at all to write or to read later; bit-level gibberish like i ~((~0) 52) or i ((1 52) - 1) or ... is painful to write and to read. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19915] int.bit_at(n) - Accessing a single bit in O(1)
Tim Peters added the comment: [@anon] What should happen next? 1. Write docs. 2. Write a test suite and test a Python implementation. 3. Write C code, and reuse the test suite to test that. 4. Attach a patch for all of that to this issue (although a Python implementation is no longer interesting at this point). 5. After that's all ready, seek consensus on Python-Dev. The good news: this is too minor to require a PEP ;-) -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19915 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19542] WeakValueDictionary bug in setdefault()pop()
Tim Peters added the comment: The weakref.slice fix looks solid to me, although it appears to be specific to 2.7 (the methods are fancier on the current default branch, fiddling with self._pending_removals too). Does anyone know why the signature of pop is: def pop(self, key, *args) ? It doesn't make sense to me to accept any number of arguments following `key`. Perhaps it's just an obscure way to avoid doing: _noarg = object() # unique sentinel def pop(self, key, default=_noarg): ? -- nosy: +tim.peters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19542 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19846] Setting LANG=C breaks Python 3 on Linux
Sworddragon added the comment: You should keep things more simple: - Python and the operation system/filesystem are in a client-server relationship and Python should validate all. - It doesn't matter what you will finally decide to be the default encoding on various places - all will provide race-conditions with no exception. - The easiest way to fix this is to give the developer the ability to make a decision (like sys.use_strict_encoding(), sys.setfilesystemencoding(), sys.setdefaultencoding() etc.). * For example giving the developer control is especially needed if he wants to handle multiple different filesystems. Why do you think that the issue is specific to Python 3? Try to open a terminal with LC_ALL=C and try to type non-ASCII characters with your keyboard. You can't because your terminal uses ASCII. sworddragon@ubuntu:~$ LANG=C sworddragon@ubuntu:~$ ä bash: $'\303\244': command not found - The terminal doesn't pseudo-crash with an exception because it doesn't matter about encodings. - It allows to change the encoding at runtime. Did you applications written in another language handling Unicode, like Perl? Compare C: It wouldn't matter like the terminal. For example fopen will simply return NULL if it can't open the file 'ä' because the filesystem is endoded with ISO-8859-1 and we wanted to open the utf-8 counterpart. Can you explain the various reasons why users explictly force the encoding to ASCII? For example I'm using this for testcases to set the language uncomplicated to english. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19933] Round default argument for ndigits
New submission from João Bernardo: From the docs for built-in function round: If ndigits is omitted, it defaults to zero (http://docs.python.org/3/library/functions.html#round) But, the only way to get an integer from `round` is by not having the second argument (ndigits): round(3.5) 4 round(3.5, 1) 3.5 round(3.5, 0) 4.0 round(3.5, -1) 0.0 round(3.5, None) Traceback (most recent call last): File pyshell#6, line 1, in module round(3.5, None) TypeError: 'NoneType' object cannot be interpreted as an integer Either the docs are wrong or the behavior is wrong. I think it's easier to fix the former... But also there should be a way to make round return an integer (e.g. passing `None` as 2nd argument) -- assignee: docs@python components: Documentation, Interpreter Core messages: 205647 nosy: JBernardo, docs@python priority: normal severity: normal status: open title: Round default argument for ndigits versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19933 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19934] collections.Counter.most_common does not document `None` as acceptable input.
New submission from Matthew Gilson: Reading the source for collections.Counter.most_common, the docstring mentions that `n` can be `None` or omitted, but the online documentation does not mention that `n` can be `None`. -- assignee: docs@python components: Documentation messages: 205648 nosy: docs@python, mgilson priority: normal severity: normal status: open title: collections.Counter.most_common does not document `None` as acceptable input. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19934] collections.Counter.most_common does not document `None` as acceptable input.
Matthew Gilson added the comment: This is a very simple patch which addresses the issue. I am still curious whether the reported function signature should be changed from: .. method:: most_common([n]) to: .. method:: most_common(n=None) . Any thoughts? Also, while I was in there, I changed a few *None* to ``None`` for consistency with the rest of the documentation. -- keywords: +patch Added file: http://bugs.python.org/file33050/mywork.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19933] Round default argument for ndigits
Vajrasky Kok added the comment: Here is the preliminary patch. After patch: round(1.23, 0) = 1 not 1.0 round(4.67, 0) = 5 not 5.0 -- keywords: +patch nosy: +vajrasky Added file: http://bugs.python.org/file33051/fix_round_with_zero_ndigits.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19933 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19933] Round default argument for ndigits
Changes by Vajrasky Kok sky@speaklikeaking.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19933 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19934] collections.Counter.most_common does not document `None` as acceptable input.
Changes by Vajrasky Kok sky@speaklikeaking.com: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19934 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
