[issue32561] Add API to io objects for non-blocking reads/writes

Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker ___ ___

[issue32561] Add API to io objects for non-blocking reads/writes

Nathaniel Smith added the comment: > BufferedIOBase is an abstract class and, despite the name, doesn’t > necessitate a buffer or cache Right, sorry, skimmed too fast. > In Issue 32475 there is a proposal to add a “getbuffn” method returning the > amount of unread pending

[issue31368] Support asynchronous, non-blocking buffered reads (RWF_NONBLOCK)

Change by Nitish : -- nosy: +nitishch ___ Python tracker ___ ___ Python-bugs-list

[issue29723] 3.6.1rc1 adds the current directory to sys.path when running a subdirectory's __main__.py; previous versions did not

Change by Serhiy Storchaka : -- pull_requests: -585 ___ Python tracker ___ ___

[issue32551] Zipfile & directory execution in 3.5.4 adds the current directory to sys.path

Nick Coghlan added the comment: I've updated the issue title to reduce the need to have read bpo-29723 first to understand it. I've also filed https://github.com/pantsbuild/pex/issues/440 essentially asking the pex folks to check if they're affected. -- stage:

[issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1

Nick Coghlan added the comment: PR submitted for 3.5. Since the problem was in a full release this time (rather than a pre-release the way it was for 3.6), I've reclassified it as a security bug, since it means some previously safe operations (where no user-writable

[issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1

Change by Nick Coghlan : -- keywords: +patch pull_requests: +5050 stage: -> patch review ___ Python tracker ___

[issue29319] Embedded 3.6.0 distribution cannot run pyz files

Change by Nick Coghlan : -- pull_requests: +5051 ___ Python tracker ___ ___

[issue32563] -Werror=declaration-after-statement expat build failure on Python 3.5

Nick Coghlan added the comment: Details of the compilation failure: ``` building 'pyexpat' extension gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -DHAVE_EXPAT_CONFIG_H=1

[issue32563] -Werror=declaration-after-statement expat build failure on Python 3.5

New submission from Nick Coghlan : A fresh Python 3.5 checkout failed to build the embedded expat XML library for me, due to the configure check that adds "-Werror=declaration-after-statement" to the compiler flags. I'm guessing this was introduced via the expat code

[issue32561] Add API to io objects for non-blocking reads/writes

Change by Martin Panter : -- dependencies: +Add ability to query number of buffered bytes available on buffered I/O ___ Python tracker

[issue32561] Add API to io objects for non-blocking reads/writes

Martin Panter added the comment: BufferedIOBase is an abstract class and, despite the name, doesn’t necessitate a buffer or cache. Adding methods and properties might break compatibility with third-party implementations, or get ugly with optional methods and multiple

[issue32475] Add ability to query number of buffered bytes available on buffered I/O

Martin Panter added the comment: If I remember the implementation of “peek” right, it may do what you want. But the documentation doesn’t guarantee much about its behaviour; see Issue 5811. Anyway, I agree that a “getbuffn” method (or property) would be nice. (Perhaps

[issue32562] Support fspath protocol in AF_UNIX sockaddr resolution

New submission from Nathaniel Smith : In 3.6, trying to connect to a AF_UNIX socket using a pathlib.Path object doesn't work: Python 3.6.4 (default, Dec 27 2017, 13:02:49) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import

[issue31368] Support asynchronous, non-blocking buffered reads (RWF_NONBLOCK)

Nathaniel Smith added the comment: Whoa, cool. bpo-32561 is complementary to this. (They both make sense on their own, but they're even better together.) -- ___ Python tracker

[issue32561] Add API to io objects for non-blocking reads/writes

New submission from Nathaniel Smith : Background: Doing I/O to files on disk has a hugely bimodal latency. If the I/O happens to be in or going to cache (either user-space cache, like in io.BufferedIOBase, or the OS's page cache), then the operation returns instantly (~1 µs)

[issue32560] inherit the py launcher's STARTUPINFO

Steve Dower added the comment: This sounds like a good idea to me - feel free to contribute your PR. -- versions: +Python 3.7 ___ Python tracker

[issue31368] Support asynchronous, non-blocking buffered reads (RWF_NONBLOCK)

Antoine Pitrou added the comment: In any case, I think this would take the form of new low-level calls in the posix module, i.e. add thin wrappers around the new system / libc calls. -- nosy: +njs, pitrou ___ Python tracker

[issue29240] PEP 540: Add a new UTF-8 mode

STINNER Victor added the comment: > New changeset 7ed7aead9503102d2ed316175f198104e0cd674c by Victor Stinner in > branch 'master': > bpo-29240: Fix locale encodings in UTF-8 Mode (#5170) Oh, this change broke test_nonascii() of test_readline() on FreeBSD.

[issue32553] venv says to use python3 which does not exist in 3.6.4

Eryk Sun added the comment: `PATHEXT` is irrelevant here, so that should be removed. As to the py launcher, it's optional and not always installed for all users, though that's the default. I'd prefer `python` that's found in PATH as the first example. Then add another

[issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1

Brett Cannon added the comment: Nick makes this sound like it really should land in 3.5.5, so marking as a release blocker for now. -- nosy: +brett.cannon priority: normal -> release blocker ___ Python tracker

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

Antoine Pitrou added the comment: Ok, there has been enough reviews in the last four months :-) This is now merged. -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

Antoine Pitrou added the comment: New changeset 94e1696d04c65e19ea52e5c8664079c9d9aa0e54 by Antoine Pitrou in branch 'master': bpo-14976: Reentrant simple queue (#3346) https://github.com/python/cpython/commit/94e1696d04c65e19ea52e5c8664079c9d9aa0e54 --

[issue32553] venv says to use python3 which does not exist in 3.6.4

Paul Moore added the comment: That's why I suggest using the launcher rather than absolute paths - there are far too many variations to enumerate with absolue paths (you didn't mention per-user Python 3.6 installations, for example). If you have a suggested wording that

[issue32534] Speed-up list.insert

Antoine Pitrou added the comment: Perhaps the patch is interfering weirdly with PGO? > Should I run the benchmark without a PGO build (i.e without > --enable-optimizations)? That would help clear things up, IMHO. -- ___ Python

[issue32534] Speed-up list.insert

Jeethu Rao added the comment: I rebased my branch off of master and rebuilt it, and also rebuilt the baseline from master. Both versions were configured with --with-lto and --enable-optimizations. The benchmark numbers are rather different this time[1]. pidigits is

[issue32555] Encoding issues with the locale encoding

STINNER Victor added the comment: New changeset b92c159efada05b3a5ff9d0dbce3fcb2334631f6 by Victor Stinner in branch '3.6': [3.6] bpo-32555: Fix locale encodings (#5193) https://github.com/python/cpython/commit/b92c159efada05b3a5ff9d0dbce3fcb2334631f6 --

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: New changeset 5f959c4f9eca404b8bc4bc6348fed27c4b907b89 by Victor Stinner in branch '3.6': [3.6] bpo-31900: Fix localeconv() encoding for LC_NUMERIC (#4174) (#5192)

[issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible

Serhiy Storchaka added the comment: Maybe deprecate using a hash? -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue32539] os.listdir(...) on deep path on windows in python2.7 fails with errno 123

Serhiy Storchaka added the comment: Thank you Anthony for your patch! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue32539] os.listdir(...) on deep path on windows in python2.7 fails with errno 123

Serhiy Storchaka added the comment: New changeset 27f32e938ff51fd5d90a29abbbabc6b81d156f33 by Serhiy Storchaka (Anthony Sottile) in branch '2.7': bpo-32539: Fix OSError for os.listdir() for extended-length paths on Windows (#5169)

[issue32560] inherit the py launcher's STARTUPINFO

New submission from Eryk Sun : I've occasionally seen requests to find the path of the LNK shortcut that was used to run a script -- for whatever reason. This can be reliably supported in most cases by calling WinAPI GetStartupInfo. If the flag STARTF_TITLEISLINKNAME is

[issue32553] venv says to use python3 which does not exist in 3.6.4

Paul Watson added the comment: Ok, I do find later on where it says to do something different on Windows. However, the first "Note" box in "28.3. venv" specifies using "python3". It does not say that this is for non-Windows systems. This should be changed. Also,

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

Antoine Pitrou added the comment: Hi all, The PR has been ready for quite some time now. Raymond posted some review comments back in September, which I addressed by making the requested changes. If someone wants to add their comments, now is the time. Otherwise I plan to

[issue32146] multiprocessing freeze_support needed outside win32

Change by bbayles : -- keywords: +patch pull_requests: +5049 stage: needs patch -> patch review ___ Python tracker ___

[issue15115] Duplicated Content-Transfer-Encoding header when applying email.encoders

R. David Murray added the comment: I believe so. For python3 I think it should only apply to the legacy API docs (you would use set_content (directly or indirectly) in python3, not set_payload). I've updated the versions. -- versions: +Python 3.6, Python 3.7

[issue29708] support reproducible Python builds

Barry A. Warsaw added the comment: On Jan 15, 2018, at 11:31, Brett Cannon wrote: > > 1. SOURCE_DATE_EPOCH acts as an environment variable flag to forcibly > generate hash-based .pyc files with the check_source bit set in py_compile > and compileall

[issue32516] Add a shared library mechanism for win32

Brett Cannon added the comment: To answer Steve's question, what you would want is a finder which recognized the directory of the package so as to return a special loader just for that package (basically __path__ is sent through the normal import mechanism and so you would

[issue29708] support reproducible Python builds

Brett Cannon added the comment: Bernhard's idea of SOURCE_DATE_EPOCH being an implicit envvar to forcibly switch on hash-based .pyc files in py_compile is intriguing. I assume this would force the check_source bit to be set? Or since SOURCE_DATE_EPOCH should only be used in

[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

Change by Raymond Hettinger : -- pull_requests: +5048 ___ Python tracker ___

[issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible

Raymond Hettinger added the comment: > This is very confusing, I hope you can fix the behavior, not the doc string. I'll fix the docstring to make it more specific. We really don't want to use hash(obj) because it produces too few bits of entropy. --

[issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible

Change by Raymond Hettinger : -- Removed message: https://bugs.python.org/msg310006 ___ Python tracker ___

[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

Raymond Hettinger added the comment: I'm getting a nice improvement in dispersion statistics by shuffling in higher bits right at the end: /* Disperse patterns arising in nested frozensets */ + hash ^= (hash >> 11) ^ (~hash >> 25); hash = hash *

[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

Change by Raymond Hettinger : -- Removed message: https://bugs.python.org/msg310007 ___ Python tracker ___

[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

Raymond Hettinger added the comment: Messages (3) msg309956 - (view) Author: Johnny Dude (JohnnyD) Date: 2018-01-15 01:08 When using a tuple that include a string the results are not consistent when invoking a new interpreter or process. For example

[issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible

Raymond Hettinger added the comment: I'm getting a nice improvement in dispersion statistics by shuffling in higher bits right at the end: /* Disperse patterns arising in nested frozensets */ + hash ^= (hash >> 11) ^ (~hash >> 25); hash = hash *

[issue32346] Speed up slot lookup for class creation

Change by Antoine Pitrou : -- status: pending -> closed ___ Python tracker ___ ___

[issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible

Change by Raymond Hettinger : -- assignee: docs@python -> rhettinger ___ Python tracker ___

[issue32559] logging - public function to get level from name

New submission from Varun Agrawal : Currently, the logging module has a function `getLevelName` and directly accessing the `_nameToLevel` dict is poor practice bordering on non-pythonic. It would be nice to have a simple method like `getNameLevel` in the module to

[issue32553] venv says to use python3 which does not exist in 3.6.4

Paul Moore added the comment: Actually, for Windows, the docs don't recommend "python3", they say: """ On Windows, invoke the venv command as follows: c:\>c:\Python35\python -m venv c:\path\to\myenv """ This should probably be altered to say "py -m venv" (or maybe "py -3

[issue31368] Support asynchronous, non-blocking buffered reads (RWF_NONBLOCK)

Ned Deily added the comment: It seems to me there are two issues here: 1. What are the pros and cons of adding support for this new mode, e.g. are there any potential gotchas? 2. Assuming the result of 1 is we should go ahead, then omeone needs to generate a pull request

[issue32553] venv says to use python3 which does not exist in 3.6.4

Ned Deily added the comment: Thanks! Pinging the Windows team. -- ___ Python tracker ___

[issue32553] venv says to use python3 which does not exist in 3.6.4

Change by Ned Deily : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker ___

[issue32553] venv says to use python3 which does not exist in 3.6.4

Paul Watson added the comment: I am running 3.6.4 from a download on pythong.org yesterday. Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32 There is a python3.dll, but no python3 executable. --

[issue32553] venv says to use python3 which does not exist in 3.6.4

Ned Deily added the comment: Unfortunately, it may depend on what environment and/or from which distributor you obtain Python 3.6 as to whether there is a "python3" link installed. On Unix-like systems, the default Python installation built from source ("make install") does

[issue11191] test_search_cpp error on AIX (with xlc)

Michael Felt added the comment: a) Is this normal? root@x065:[/data/prj/python/git/python3-3.7]./python -m unittest test.test_distutils -- Ran 0 tests in 0.000s OK In short - at the start I had:

[issue32555] Encoding issues with the locale encoding

Change by STINNER Victor : -- keywords: +patch pull_requests: +5047 stage: -> patch review ___ Python tracker ___

[issue32558] Socketserver documentation : error in server example

Tristan Colombo added the comment: Running on Debian Etch Ok, my python3 was broken and links to python3.5.3 All my apologizes -- stage: -> resolved status: open -> closed ___ Python tracker

[issue32558] Socketserver documentation : error in server example

Ned Deily added the comment: In what environment are you trying this? The example works for me (on a current macOS) system. -- nosy: +ned.deily ___ Python tracker

[issue32558] Socketserver documentation : error in server example

Tristan Colombo added the comment: Correction of my previous correction : server = socketserver.TCPServer((HOST, PORT), MyTCPHandler) 'with' statement can not be used... -- ___ Python tracker

[issue32558] Socketserver documentation : error in server example

New submission from Tristan Colombo : In the documentation, at page : - https://docs.python.org/3.6/library/socketserver.html - Section 21.21.4.1 In the server side code : if __name__ == "__main__": HOST, PORT = "localhost", # Create the server, binding

[issue32555] Encoding issues with the locale encoding

STINNER Victor added the comment: Example of bug on FreeBSD 11: haypo@freebsd$ LC_ALL=C ./python -c 'import locale, os; locale.setlocale(locale.LC_ALL, "fr_FR.ISO8859-1"); print(ascii(os.strerror(2)))' 'Fichier ou r\udce9pertoire inexistant' Expected result:

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Change by STINNER Victor : -- pull_requests: +5046 ___ Python tracker ___ ___

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: lc_numeric.py contains a typo, used fixed lc_numeric2.py instead to test my PR 5191 which fixes decimal.Decimal. -- Added file: https://bugs.python.org/file47386/lc_numeric2.py ___ Python

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Change by STINNER Victor : -- pull_requests: +5045 ___ Python tracker ___ ___

[issue32557] allow shutil.disk_usage to take a file path

New submission from Eryk Sun : Issue 26330 was resolved by documenting that shutil.disk_usage requires a directory. However, the shutil module is in a position to harmonize cross-platform behavior in ways that aren't normally possible or recommended in the low-level os

[issue32544] Speed up hasattr(o, name) and getattr(o, name, default)

Serhiy Storchaka added the comment: I considered the idea of implementing _PyObject_GetAttrWithoutError() for issue31572, but dropped it because the code simplification was too small. But if this has performance benefits I'm +1 to implementing it. I'll update my

[issue32556] support bytes paths in nt _getdiskusage, _getvolumepathname, and _getfinalpathname

New submission from Eryk Sun : In issue 26330 it was noted that nt._getdiskusage doesn't accept bytes paths. The same applies to nt._getvolumepathname and nt._getfinalpathname. Callers of these functions shouldn't have to manually implement PEP 529 UTF-8 support to handle

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: New changeset cb064fc2321ce8673fe365e9ef60445a27657f54 by Victor Stinner in branch 'master': bpo-31900: Fix localeconv() encoding for LC_NUMERIC (#4174)

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: On macOS 10.13.2, I failed to find any non-ASCII decimal_point or thousands_sep in localeconv(). I wrote a script to find all non-ASCII data in all locales: https://github.com/vstinner/misc/blob/master/python/all_locales.py

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: Test on Linux (Fedora 27, glibc 2.26): locale.setlocale(locale.LC_ALL, "fr_FR") locale.setlocale(locale.LC_NUMERIC, "es_MX.utf8") It works as expected, result: decimal_point: '.' thousands_sep: '\u2009' Python 3.6 returns mojibake:

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: I tested localeconv() with PR 4174 on FreeBSD: -- locale.setlocale(locale.LC_ALL, "C") locale.setlocale(locale.LC_NUMERIC, "ar_SA.UTF-8") -- It works as expected, result: -- decimal_point: '\u066b' thousands_sep: '\u066c' -- Compare

[issue26330] shutil.disk_usage() on Windows can't properly handle unicode

Mariatta Wijaya added the comment: Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 ___ Python tracker

[issue26330] shutil.disk_usage() on Windows can't properly handle unicode

Mariatta Wijaya added the comment: New changeset fb8569e36f2629654d5bc9c7ba05978edce408f4 by Mariatta (Miss Islington (bot)) in branch '3.6': bpo-26330: Update shutil.disk_usage() documentation (GH-5184) (GH-5188)

[issue32534] Speed-up list.insert

Antoine Pitrou added the comment: I'm quite surprised so many benchmarks would be speeded up so significantly by a list.insert() optimization (why a 27% speedup on computing digits of pi, or a 33% speedup on a N-body simulation?). Are you sure the two executables are

[issue11191] test_search_cpp error on AIX (with xlc)

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___

[issue11191] test_search_cpp error on AIX (with xlc)

Change by Michael Felt : -- versions: +Python 3.7 -Python 3.2 ___ Python tracker ___

[issue11191] test_search_cpp error on AIX (with xlc)

Michael Felt added the comment: After even more years - I see the same test failing, just a bit different. And, others in short: ./python Lib/test/test_distutils.py ... Ran 245 tests in 10.337s FAILED (errors=7, skipped=31) I have managed to get this to: FAILED

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Marc-Andre Lemburg added the comment: Sounds like a good compromise :-) -- ___ Python tracker ___

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: > I would not consider this a bug in Python, but rather in the locale settings > passed to setlocale(). Past 10 years, I repeated to every single user I met that "Python 3 is right, your system setup is wrong". But that's a waste of

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: See #32546 for the hash=None problem. -- ___ Python tracker ___

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Marc-Andre Lemburg added the comment: Indeed. The major problem with all libc locale functions is that they are not thread safe. The GIL does help a bit protecting against corrupted data, though. -- ___ Python tracker

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: The technical issue here is that the libc has no "stateless" function to process bytes and text with one specific locale. All functions rely on the *current* locales. To decode byte strings, we use mbstowcs(), and this function

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Marc-Andre Lemburg added the comment: Ok, it seems that the C setlocale() itself does not follow the conventions set forth for environment variables: http://pubs.opengroup.org/onlinepubs/7908799/xsh/setlocale.html (see the example at the bottom) So the behavior shown by

[issue32513] dataclasses: make it easier to use user-supplied special methods

Eric V. Smith added the comment: Another case to consider is that if a class defines __eq__, Python will automatically set hash=False before the decorator gets involved. NOte to self: be sure to add a test case for this. -- ___

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: Example of Fedora 27 and Python 3.6: vstinner@apu$ env -i LC_NUMERIC=uk_UA.koi8u python3 -c 'import locale; print(locale.setlocale(locale.LC_ALL, "")); print(locale.getpreferredencoding(),

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: Marc-Andre Lemburg: "If you first set LC_ALL and then one of the other categories such as LC_NUMERIC, locale C functions will still use the LC_ALL setting for everything. LC_NUMERIC does not override the LC_ALL setting." The root of

[issue29708] support reproducible Python builds

Bernhard M. Wiedemann added the comment: I think, there is no single nice and clean solution with time-based .pyc files, but to get a whole distribution to build reproducibly, there are two other ways: 1) if the SOURCE_DATE_EPOCH environment variable is set, make

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Stefan Krah added the comment: On Mon, Jan 15, 2018 at 12:37:28PM +, Marc-Andre Lemburg wrote: > If you first set LC_ALL and then one of the other categories such as > LC_NUMERIC, locale C functions will still use the LC_ALL setting for > everything. LC_NUMERIC does

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Marc-Andre Lemburg added the comment: I just wanted to note that the description and title may cause a wrong interpretation of what should happen: If you first set LC_ALL and then one of the other categories such as LC_NUMERIC, locale C functions will still use the LC_ALL

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: > Please confirm the bug without having LC_ALL or LANG set. lc_numeric.py uses: locale.setlocale(locale.LC_ALL, "fr_FR") Are you talking about that? What is the problem with this configuration? I'm sure that there is a bug :-)

[issue32516] Add a shared library mechanism for win32

Marc-Andre Lemburg added the comment: >From experience with doing something similar in egenix-pyopenssl, I recommend >putting the DLLs into the same directory as the PYD file on Windows. If you >want to be extra safe, you can explicitly load the DLL, but normally this is

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

Christian Heimes added the comment: It's not just the headers. The shared library is now /usr/lib64/nsl/libnsl.so.2 instead of /usr/lib64/libnsl.so.1. -- ___ Python tracker

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

Change by Christian Heimes : -- pull_requests: +5044 ___ Python tracker ___ ___

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

Marc-Andre Lemburg added the comment: Just FYI: LC_ALL has precedence over all other more specific LC_* settings: http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html http://man7.org/linux/man-pages/man7/locale.7.html Please confirm the bug without having LC_ALL or

[issue32555] Encoding issues with the locale encoding

STINNER Victor added the comment: Another issue: _Py_DecodeUTF8Ex() creates surrogate pairs with 16-bit wchar_t (on Windows), whereas input bytes should be escaped. I'm quite sure that it's a bug. -- ___ Python tracker

[issue32555] Encoding issues with the locale encoding

STINNER Victor added the comment: I'm not sure that locale.bindtextdomain() uses the right encoding neither. I propose the following fix: diff --git a/Modules/_localemodule.c b/Modules/_localemodule.c index 324b694b83..1de17d3620 100644 --- a/Modules/_localemodule.c

[issue32555] Encoding issues with the locale encoding

New submission from STINNER Victor : Python 3.6 doesn't use the right encoding in os.strerror(), time.stftime(), locale.localeconv(), time.tzname, etc. on macOS, FreeBSD and other platforms. See my fix locale encodings in bpo-29240: commit

[issue29240] PEP 540: Add a new UTF-8 mode

Change by STINNER Victor : -- pull_requests: +5043 ___ Python tracker ___ ___

[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

STINNER Victor added the comment: Oops lc_numeric.py contains a typo: d = decimal.Decimal(1234) print("Decimal.__format__: %a" % f"{i:n}") => it should be f"{d:n}" -- ___ Python tracker

  1   2   >