[issue43552] Add locale.get_locale_encoding() and locale.get_current_locale_encoding()

2021-03-19 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 19.03.2021 16:15, Inada Naoki wrote: > > `locale.getpreferredencoding()` is special, because it "Return the encoding > used for text data, according to user preferences. User preferences are > expressed differently on different s

[issue43557] Deprecate getdefaultlocale(), getlocale() and normalize() functions

2021-03-19 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: +1 on getdefaultlocale() as mentioned in https://bugs.python.org/issue43552 However, -1 on getlocale() and normalize(). Those two are needed to access and successfully set the locale on Linux: the lib C setlocale() is very picky about locale names and so

[issue43552] Add locale.get_locale_encoding() and locale.get_current_locale_encoding()

2021-03-19 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 19.03.2021 13:25, Eryk Sun wrote: >> My assumption is that nl_langinfo(CODESET) does not work on Windows >> or gives wrong results. Is that incorrect ? > > There is no such function for CRT locales. I provided two alternatives t

[issue43391] The comments have invalid license information (broken Python 2.4 URL for Python 3)

2021-03-06 Thread Marc-Andre Lemburg
Change by Marc-Andre Lemburg : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue43391] The comments have invalid license information (broken Python 2.4 URL for Python 3)

2021-03-03 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: https://www.python.org/download/releases/2.4/license/ is the correct link for the Python 2.4 license. Note that the contributor agreement allows the PSF to distribute the code under a different OSS license and so the current Python license applies

[issue43115] locale.getlocale fails if locale is set

2021-02-18 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 18.02.2021 19:04, Eryk Sun wrote: > > Eryk Sun added the comment: > >> The APIs were written at a time where locale modifiers >> simply did mot exist. > > Technically, locale modifiers did exist circa 2000, but I suppose

[issue43115] locale.getlocale fails if locale is set

2021-02-18 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 18.02.2021 10:36, Eryk Sun wrote: > It's not just a Windows problem. For example, getlocale() doesn't return the > POSIX locale modifier in a 3-tuple (language, encoding, modifier). So it > can't be used to restore a locale for which the

[issue43115] locale.getlocale fails if locale is set

2021-02-17 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 17.02.2021 12:36, Anders Munch wrote: > getlocale is documented to return None for the encoding if no encoding can be > determined. There's no need to guess. Well, not quite... the documentation says that None can be returned, not that it will

[issue20087] Mismatch between glibc and X11 locale.alias

2021-02-17 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: I believe we can close this old issue. The discussion was certainly a useful one. I guess we should stop updating the alias table automatically and instead add new aliases or change existing ones based on more research and using the X11 files as well

[issue42988] Information disclosure via pydoc -p: /getfile?key=path allows to read arbitrary file on the filesystem

2021-01-22 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 22.01.2021 01:28, STINNER Victor wrote: > > STINNER Victor added the comment: > >> I'd suggest to print a big warning on the console, explaining that the web >> server will potentially make all content accessible by the user

[issue42988] Information disclosure via pydoc -p

2021-01-21 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Looking at the _url_handler() code in pydoc.py, this was clearly not written with web server standards in mind. None of the handlers apply security checks on the user input and there are most likely several other vulnerabilities in there to be found

[issue42967] [security] urllib.parse.parse_qsl(): Web cache poisoning - `; ` as a query args separator

2021-01-20 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Sorry for the title mess: It seems that when replying to a ticket, RoundUp uses the subject line as the new header regardless of what it was set to before. -- ___ Python tracker <https://bugs.python.

[issue42967] [security] Web cache poisoning - `; ` as a query args separator

2021-01-20 Thread Marc-Andre Lemburg
Change by Marc-Andre Lemburg : -- title: Web cache poisoning - `;` as a query args separator -> [security] Web cache poisoning - `;` as a query args separator ___ Python tracker <https://bugs.python.org/issu

[issue39457] Add an autocommit property to sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate

2021-01-06 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 05.01.2021 19:04, Géry wrote: > > @lemburg > >> I guess the SQLite driver does not start a new transaction for SELECTs, >> since these are usually read-only > > Nor for DDL statements (CREATE, DROP). Those are defin

[issue39457] Add an autocommit property to sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate

2021-01-05 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: I think there's a bit of a misunderstanding here. When relying on a DB-API driver's transaction API, you are not allowed to issue separate transaction commands to the DB backend via the .execute() methods. You have to use conn.commit() and conn.rollback

[issue42257] platform.libc_ver() doesn't consider in case of executable is empty string

2021-01-02 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Note: I did not request a backport, since this really is a new feature. -- ___ Python tracker <https://bugs.python.org/issue42

[issue42257] platform.libc_ver() doesn't consider in case of executable is empty string

2021-01-02 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: https://github.com/python/cpython/pull/23140 merged. Thanks for the patch, Kurochan. -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue42794] test_nntplib fails on CI

2021-01-01 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Thanks for the patch, Dong-hee Na. Christian: Tests relying on external resources will always have such issues. This doesn't mean that the code which is being tested is outdated or broken. It's just an issue with the tests. Perhaps we ought to disable

[issue42794] test_nntplib fails on CI

2021-01-01 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 01.01.2021 13:57, Christian Heimes wrote: > > Does this issue mean that I should include nntplib in PEP 594 again? The test fails because it was relying on an external news server's configuratoin. This doesn't mean the code itself is broken

[issue42794] test_nntplib fails on CI

2020-12-31 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: FWIW, I'm getting the same errors in PR https://github.com/python/cpython/pull/23140 Checking on the server that's being used, the newsgroup description is empty indeed: https://news.aioe.org/index.php?id=statistics-about-groups=comp.lang.python

[issue42257] platform.libc_ver() doesn't consider in case of executable is empty string

2020-12-31 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Thanks for the patch. Merging is currently prevented by an unrelated test for nntplib failing. See e.g. https://github.com/python/cpython/pull/23140/checks?check_run_id=1630509357. This is being tracked in https://bugs.python.org/issue42794

[issue42257] platform.libc_ver() doesn't consider in case of executable is empty string

2020-12-28 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Reviewed. Please check on the PR for comments. -- ___ Python tracker <https://bugs.python.org/issue42257> ___ ___ Pytho

[issue28468] Add platform.freedesktop_os_release()

2020-11-25 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 25.11.2020 11:45, Christian Heimes wrote: > > Christian Heimes added the comment: > > PS: MAL, would it be possible to suppress your email footer? BPO is not an > advertisement channel. That's an ancient bug on bpo, which apparentl

[issue28468] Add platform.freedesktop_osrelease()

2020-11-25 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 25.11.2020 10:39, Christian Heimes wrote: > >> It would be an interface to a file /etc/os-release >> that's common nowadays, just like /etc/lsb-release was some years >> ago. These things change too often to make the stdlib a go

[issue28468] Add platform.freedesktop_osrelease()

2020-11-25 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 25.11.2020 10:06, Christian Heimes wrote: > > It's not a replacement for platform.linux_distribution(). Right, not even that :-) It would be an interface to a file /etc/os-release that's common nowadays, just like /etc/lsb-release was some yea

[issue28468] Add platform.freedesktop_osrelease()

2020-11-25 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: I'm -1 on adding any kind of replacement for platform.linux_distribution() tp Python's stdlib. The experiment has failed and we should acknowledge this. The main reason why it failed was the Linux distros keep inventing new ways to identify themselves

[issue42157] Cleanup the unicodedata module

2020-10-26 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 26.10.2020 18:05, STINNER Victor wrote: > > By the way, Unicode 3.2 was released in 2002: 18 years ago. I don't think > that it's still relevant in 2020 to keep backward compatibility with Unicode > 3.2. I propose to deprecate unicodeda

[issue41842] Add codecs.unregister() to unregister a codec search function

2020-09-23 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 23.09.2020 16:49, STINNER Victor wrote: > > STINNER Victor added the comment: > >> Just found an internal API which already takes care of >> unregistering a search function: _PyCodec_Forget(). >> >> All t

[issue41420] Academic Free License v. 2.1 link is not found and is obsolete

2020-09-22 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: The Adobe form itself also still lists the broken URL. Only Ewa or Betsy can fix this, I suppose. I'll write them an email. -- ___ Python tracker <https://bugs.python.org/issue41

[issue41420] Academic Free License v. 2.1 link is not found and is obsolete

2020-09-22 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Fixed https://www.python.org/psf/contrib/ to point to https://spdx.org/licenses/AFL-2.1.html instead. The contrib-form page (https://www.python.org/psf/contrib/contrib-form/) already had this change, but the PDF you can download from there still lists

[issue40789] C-level destructor in PySide2 breaks gen_send_ex, which assumes it's safe to call Py_DECREF with a live exception

2020-05-27 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 27.05.2020 05:56, Nathaniel Smith wrote: > In CPython in general, it could be worked around by not invoking deallocators > with a live exception... I'm actually pretty surprised that this is even > possible! It seems like having a live excep

[issue35967] Better platform.processor support

2020-05-18 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Thanks, Jason. I'll have a closer look at the issue and report back later this week. -- ___ Python tracker <https://bugs.python.org/issue35

[issue40578] Deprecate numeric item access for platform.uname()

2020-05-13 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: I am closing this issue, since deprecations should really only be used when no other means are possible. The namedtuples returned by platform.uname() do support index access and so any implementation change altering this is surprising and backwards

[issue35967] Better platform.processor support

2020-05-13 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Reopening the ticket, since the implementation makes backwards incompatible changes to platform.uname(): see https://bugs.python.org/issue40570 for a discussion on a better approach to lazy evaluation of getting the processor information. Before we

[issue40570] len(platform.uname()) has changed in Python 3.9

2020-05-13 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Hi Jason, I think I have to review the whole set of changes again to understand what your motivation is/was. For https://bugs.python.org/issue35967 I had already stated that your use case is not special enough to make the platform.py logic more

[issue40570] len(platform.uname()) has changed in Python 3.9

2020-05-09 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Ok, let me add some more context: When I wrote the uname interface I was aware that calling the API will take some resources. That's why I added the cache. IMO, that was enough as optimization. Now, you added a late binding optimization for the whole

[issue40570] len(platform.uname()) has changed in Python 3.9

2020-05-09 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Hi Jason, to achieve better backwards compatibility, it's probably better to use the approach taken for CodeInfo in the codecs.py module: class CodecInfo(tuple): """Codec details when looking up the codec registry"""

[issue40505] getpath.c doesn't know about lib64

2020-05-04 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: No, I have not opened a bug report on OpenSUSE. Since the OS uses bi-arch throughout, using lib64 is the natural thing to use for libdir on the OS. I think the issue lies with getpath.c only, since it makes an assumption about the libdir config value

[issue40505] getpath.c doesn't know about lib64

2020-05-04 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Just to clarify: the CONFIG_SITE script on OpenSUSE causes configure to use lib64, not the Python configure script itself. -- ___ Python tracker <https://bugs.python.org/issue40

[issue40505] getpath.c doesn't know about lib64

2020-05-04 Thread Marc-Andre Lemburg
New submission from Marc-Andre Lemburg : On platforms which configure identifies as bi-arch platform, libdir is set to $[exec_prefix}/lib64, which results in the C extensions to get installed in e.g. /usr/local/lib64/python3.8/lib-dynload/. However, the getpath.c routines use a fixed &quo

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

2020-04-28 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Found an "Unlink" bottom at the bottom of the message view. This appears to remove the messages from the issue. -- ___ Python tracker <https://bugs.python.o

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

2020-04-28 Thread Marc-Andre Lemburg
Change by Marc-Andre Lemburg : -- Removed message: https://bugs.python.org/msg367514 ___ Python tracker <https://bugs.python.org/issue21081> ___ ___ Python-bug

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

2020-04-28 Thread Marc-Andre Lemburg
Change by Marc-Andre Lemburg : -- Removed message: https://bugs.python.org/msg367515 ___ Python tracker <https://bugs.python.org/issue21081> ___ ___ Python-bug

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

2020-04-28 Thread Marc-Andre Lemburg
Change by Marc-Andre Lemburg : -- Removed message: https://bugs.python.org/msg320603 ___ Python tracker <https://bugs.python.org/issue21081> ___ ___ Python-bug

[issue21081] missing vietnamese codec TCVN 5712:1993 in Python

2020-04-28 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: I have marked the messages as spam. Can't seem to remove them, though. -- ___ Python tracker <https://bugs.python.org/issue21

[issue39891] [difflib] Improve get_close_matches() to better match when casing of words are different

2020-03-08 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: It looks like Brian is expecting some kind of normalization of the strings before they enter the function, e.g. convert to lowercase, remove extra whitespace, convert diacritics to regular letters, combinations of such normalizations, etc. Since both

[issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores.

2020-01-14 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Just to clarify: the change in the C implementation was the breaking change. The patch just restores the previous behavior: https://github.com/python/cpython/blob/master/Lib/encodings/__init__.py#L43 Please note that external codec packages should

[issue37848] More fully implement Unicode's case mappings

2019-08-14 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: The Unicode implementation is deliberately not locale specific and this should not change. If a locale specific mapping is requested, this should be done explicitly by e.g. providing a parameter to str.lower() / upper() / title

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

2019-08-13 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: BTW: Since when do we use type annotations in Python's stdlib ? -- nosy: +lemburg ___ Python tracker <https://bugs.python.org/issue37

[issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores.

2019-08-12 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Jordon is right. Conversion has to be to underscores, not hyphens. I guess this bug was introduced when the normalization function was converted to C. -- nosy: +lemburg ___ Python tracker <ht

[issue37406] Disable runtime checks in release mode

2019-06-26 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Given that extensions call these APIs, I find it highly risky to disable these checks in any version of the Python runtime and am -1 on such a change. Using assert() in C is a pretty bad alternative, since this crashes the whole process. It should really

[issue35551] Encoding and alias issues

2019-06-05 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: 1. Background for "tactis": https://github.com/python/cpython/commit/4fd73f0465ba11c22f0986d04cf91b387ed22c47 # The codecs for these encodings are not distributed with the # Python core, but are included here for reference, since the

[issue36346] Prepare for removing the legacy Unicode C API

2019-03-18 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 18.03.2019 22:33, Stefan Behnel wrote: > > I had also looked through the unrelated changes, and while, yes, they are > unrelated, they seemed to be correct and reasonable modernisations of the > code base while touching it. They co

[issue36346] Prepare for removing the legacy Unicode C API

2019-03-18 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: I'd change the title of this bpo item to "Prepare for removing the whcar_t caching in the Unicode C API". Note that the wchar_t caching was put in place to allow for external applications and C code to easily and efficiently interface w

[issue35967] Better platform.processor support

2019-03-16 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 08.03.2019 18:50, Jason R. Coombs wrote: > >> It's also easy to bypass that by simply seeding the global cache >> for uname(): _uname_cache. >> Or you could monkey-patch the platform module >> in your utility to work ar

[issue36297] Remove unicode_internal codec

2019-03-15 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 15.03.2019 17:55, Serhiy Storchaka wrote: > Is it for debugging only? No, you can use it to store Unicode object as-is without any encoding/decoding, but after the recent changes to the internals of the Unicode implementation it's not all that use

[issue36297] Remove unicode_internal codec

2019-03-15 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 15.03.2019 17:35, Serhiy Storchaka wrote: > > What is the purpose of the unicode-internal codec at first place? It provides a fast and direct access to the internal representation of Unicode used in Python to the outside world. -

[issue35967] Better platform.processor support

2019-03-08 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 08.03.2019 18:00, Jason R. Coombs wrote: > >> Perhaps adding a more capable API to interface to /proc/cpuinfo > would be a good idea. > > The core concern I want to address is that it's not possible to use any > function i

[issue35967] Better platform.processor support

2019-03-08 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Jason: StackExchange does have lots of good hints, but it's not always the correct. In this case, it's clearly wrong. uname -p has been available on many Unix installations for decades. I started writing the module back in 1999 and even then, the support

[issue35967] Better platform.processor support

2019-03-08 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Thanks. It would be good to do some before/after tests on popular platforms, e.g. a few Linuxes, MacOS, Windows. -- ___ Python tracker <https://bugs.python.org/issue35

[issue35967] Better platform.processor support

2019-03-08 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: As the documentation says, the API is intended as fairly portable implementation of the Unix uname helper across platforms. It's fine to redirect this directly to e.g. /proc output instead of using the executable, but in whatever you do here, the output

[issue35616] Change references to '4.0'.

2019-01-05 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Why not change the wording to read "... will be considered for removal in the next major Python release". Note that removal of Py_UNICODE APIs will not only break compatibility with Python 2, but also with the early Python 3 releases. And p

[issue35544] unicode.encode docstring says return value can be unicode

2018-12-20 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: You can install any codec you like and those essentially decide on what to return as type. However, the unicode methods only allow strings or unicode to be returned in Python 2. In Python 3, .encode() only allows bytes. You can still get the full codec

[issue35348] Problems with handling the file command output in platform.architecture()

2018-12-17 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Guys, please read the doc-string of the platform.architecture() function (or ask the person who wrote most of the module). It clearly refers to inspecting a specific executable and only uses the Python interpreter as default. The running process can

[issue35389] Use gnu_get_libc_version() in platform.libc_ver()?

2018-12-05 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Nice. I never liked the "parse the executable approach", but there wasn't anything better available at the time. -- nosy: +lemburg ___ Python tracker <https://bugs.python.o

[issue35346] Modernize Lib/platform.py code

2018-11-29 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Ok, let me add some history here: When I created the platform module it was clear that this would be a module which will frequently need updates, since platforms evolve faster than Python does. I had developed this with a larger number of contributors

[issue35346] Modernize Lib/platform.py code

2018-11-29 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Please keep Python 2.7 compatibility. It should be possible to copy the module back into Python 2.7 and use it there. This is not hard to do and allows it to fulfill its purpose as platform detection module even while part of the stdlib. -- nosy

[issue31873] Inconsistent capitalization of proper noun - Unicode.

2018-11-04 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: If you want to do this correctly, you have to check each case: * if "unicode object" refers to a C PyUnicode object, it's probably better to use "PyUnicode object" * if "unicode object" refers to a C PyObject object, with

[issue25416] Add encoding aliases from the (HTML5) Encoding Standard

2018-11-02 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Please note that we can only add aliases if the encodings are indeed the same. Given that WhatWG has made changes to several standard encodings, this is especially important, since our codecs are mostly based on what the Unicode consortium defines

[issue22232] str.splitlines splitting on non-\r\n characters

2018-10-05 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Why not simply add a new parameter, to make people who want ASCII linebreaks continue to use .splitlines() ? It think it would be less than ideal to have one method break on all Unicode line breaks and another only on ASCII ones

[issue18291] codecs.open interprets FS, RS, GS as line ends

2018-10-05 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 05.10.2018 14:06, Serhiy Storchaka wrote: > > Then this particularity of codecs streams should be explicitly documented. Yes, probably. Such extensions of scope for different character types in Unicode vs. ASCII are a common gotcha when movin

[issue18291] codecs.open interprets FS, RS, GS as line ends

2018-10-05 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Sorry, I probably wasn't clear: the codecs interface is a direct interface to the Unicode codecs and thus has to work according to what Unicode defines. Your PR changes this to be non-compliant and does this for all codecs. That's a major backwards

[issue22232] str.splitlines splitting on non-\r\n characters

2018-10-05 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: I am -1 on changing the default behavior. The Unicode standard defines what a linebreak code point is (all code points with character properties Zl or bidirectional property B) and we adhere to that. This may confuse parsers coming from the ASCII world

[issue18291] codecs.open interprets FS, RS, GS as line ends

2018-10-05 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: The Unicode .splitlines() splits strings on what Unicode defines as linebreak characters (all code points with character properties Zl or bidirectional property B). This is different than what typical CSV file parsers or other parsers built

[issue34538] Remove encouragement to author a base class for all Exception subclasses in a module

2018-10-01 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: Just as extra data point: It is fairly common to have a common exception class which is then used a mixin class together with the standard exception classes, so that you can indeed identify the source of an exception and catch errors based on the source

[issue34763] Python lacks 0x4E17

2018-09-21 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: We use the Unicode database for these methods. Could you please check whether the database marks the character as numeric ? If yes, we may need to check the database generation. Otherwise, there isn't much we can do, since we use the Unicode database

[issue26544] platform.libc_ver() returns incorrect version number

2018-08-21 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: I added a comment to the PR, but other than that I think it's good to go. -- ___ Python tracker <https://bugs.python.org/issue26

[issue33598] ActiveState Recipes links in docs, and the apparent closure of Recipes

2018-05-25 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: I'd suggest to contact ActiveState first before jumping to conclusions. -- nosy: +lemburg ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue28167] remove platform.linux_distribution()

2018-05-16 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: Hi Petr, I'm fine with this. Maintaining the necessary logic Python is not really possible in the stdlib. It's better to have a PyPI module for this which can be updated much more easily.

[issue20087] Mismatch between glibc and X11 locale.alias

2018-05-06 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: Thanks, Serhiy. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20087> ___

[issue33278] libexpat uses HAVE_SYSCALL_GETRANDOM instead of HAVE_GETRANDOM_SYSCALL

2018-04-14 Thread Marc-Andre Lemburg
New submission from Marc-Andre Lemburg <m...@egenix.com>: See https://github.com/python/cpython/blob/3.6/Modules/expat/xmlparse.c#L87 The Python configure script tests and sets the variable HAVE_GETRANDOM_SYSCALL. The solution would be to have Python's config script

[issue32846] Deletion of large sets of strings is extra slow

2018-02-17 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: Reminds of some experiments someone did a while ago as part of the GIL removal attempts where the ref count integers are all kept in a separate array. The intent there was to be able to do locking on a single array rather than on indi

[issue32516] Add a shared library mechanism for win32

2018-01-17 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 17.01.2018 02:52, xoviat wrote: > > xoviat <xov...@gmail.com> added the comment: > > For the record, moving the DLL path manipulation code into the interpreter > would address the concern that importing a

[issue32516] Add a shared library mechanism for win32

2018-01-16 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: Probably better overall to go with a conda package which puts the DLLs in a central location and manages the dependencies. You can then load the DLL in the package before loading the PYD and you're all set. Whether in an __ini

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

2018-01-15 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: Sounds like a good compromise :-) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

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

2018-01-15 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> 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 tracke

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

2018-01-15 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> 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

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

2018-01-15 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> 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

[issue32516] Add a shared library mechanism for win32

2018-01-15 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> 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 DL

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

2018-01-15 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> 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

[issue31895] Native hijri calendar support

2017-10-30 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: There are other PyPI packages available for this specific calendar as well, e.g. https://pypi.python.org/pypi/umalqurra/ Perhaps you could send Neil a PR to make the calculation more accurate ?! In any case, the stdlib is not

[issue31895] Native hijri calendar support

2017-10-30 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: I agree with Steven: It's best to use a PyPI package for calendar support such as https://pypi.python.org/pypi/convertdate/. We only have the standard Gregorian calendar support in datetime and calendar modules. -

[issue31803] time.clock() should emit a DeprecationWarning

2017-10-26 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 26.10.2017 13:46, Serhiy Storchaka wrote: > > It is very bad, that the function with such attractive name has different > meaning on Windows and Unix. I'm sure that virtually all uses of clock() are > broken be

[issue31803] time.clock() should emit a DeprecationWarning

2017-10-25 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 25.10.2017 01:31, STINNER Victor wrote: > > Marc-Andre: "Yes, to avoid yet another Python 2/3 difference. It should be > replaced with the appropriate variant on Windows and non-Windows platforms. > From S

[issue31803] time.clock() should emit a DeprecationWarning

2017-10-24 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 24.10.2017 11:23, STINNER Victor wrote: > > Marc-Andre Lemburg: "Thanks for pointing that out. I didn't know." > > Do you still think that we need to modify time.clock() rather than > deprecating it? Y

[issue31803] time.clock() should emit a DeprecationWarning

2017-10-22 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 22.10.2017 15:14, Serhiy Storchaka wrote: > > Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment: > > On non-Windows platforms clock() returns the processor time, perf_counter() > does includ

[issue31803] time.clock() should emit a DeprecationWarning

2017-10-22 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 20.10.2017 19:46, Serhiy Storchaka wrote: > > This will break a code that depends on the current behavior on non-Windows > platforms. And this will contradict the expectation of non-Windows > programmers. If c

[issue31803] time.clock() should emit a DeprecationWarning

2017-10-18 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 18.10.2017 11:45, STINNER Victor wrote: > Marc-Andre, Ethan: What do you think of removing the deprecation warning from > the C (my last commit), leave the deprecation warning in the documentation, > and modify time.cl

[issue31803] time.clock() should emit a DeprecationWarning

2017-10-17 Thread Marc-Andre Lemburg
Marc-Andre Lemburg <m...@egenix.com> added the comment: time.cock() is used in a lot of code. Why can't we simply replace the functionality with one of the other functions ? The documentation certainly allows for such a change, since it pretty much just says that only the delta betwe

[issue31530] Python 2.7 readahead feature of file objects is not thread safe

2017-09-20 Thread Marc-Andre Lemburg
Marc-Andre Lemburg added the comment: On 20.09.2017 17:22, Guido van Rossum wrote: > >> Why not simply document the fact that read ahead in Python 2.7 >> is not thread-safe and leave it at that ? > > Program bugs should not crash the interpreter. (ctypes excepted.)

  1   2   3   4   5   6   7   8   9   10   >