Marc-Andre Lemburg added the comment:
On 28.08.2021 06:06, Guido van Rossum wrote:
>
>> With that in place, it'd be great to pre-cache all the .py files
>> automatically read in at startup.
>
> *All* the .py files? I think the binary bloat cause by deep-freezing the
Marc-Andre Lemburg added the comment:
Not sure whether you are aware, but the PyRun project I'm maintaining
does that and goes beyond this by freezing almost the complete stdlib
and statically linking most C extensions into a single binary:
https://www.egenix.com/products/python/PyRun
Marc-Andre Lemburg added the comment:
Right, the charmap codec was built with the Unicode Consortium mappings in mind.
However, you may have some luck decoding the two byte chars in ISO 6937 using
combining code points in Unicode. With some extra post processing you could
also normalize
Marc-Andre Lemburg added the comment:
Maarten, the code posted on bugs is copyrighted by the person who wrote it. We
can only accept it for inclusion in Python after the CLA has been signed, since
then we are allowed to relicense it.
As a result you can only take John's code and post
Marc-Andre Lemburg added the comment:
Yes, closing.
--
stage: needs patch -> resolved
status: pending -> closed
___
Python tracker
<https://bugs.python.org/
Marc-Andre Lemburg added the comment:
Steve: I think the point of discussing whether "pip install" can
be used to manage system wide packages is moot. It's been like that
for ages, not only for pip, but also for the distutils setup.py install
process and the old Makefile.pre.in appro
Marc-Andre Lemburg added the comment:
On 05.05.2021 10:29, Christian Heimes wrote:
>
> I mean that Steve and you are talking about different things.
Could be. I was addressing the point Steve made about not allowing
or making it hard to run "pip install" as root user.
>
Marc-Andre Lemburg added the comment:
On 05.05.2021 10:01, Christian Heimes wrote:
>
>> "as root" imply that there's no user site-packages directory at all
> ^
>
> Steve is talking about user site-packages, not global s
Marc-Andre Lemburg added the comment:
On 04.05.2021 22:58, Steve Dower wrote:
>> "pip install as root" will need to continue to work and thus distros
>> need to get a way to make sure that it doesn't corrupt the system
>> installed packages
>
> Excuse my i
Marc-Andre Lemburg added the comment:
On 04.05.2021 22:29, Steve Dower wrote:
>
> Would "pip install --user ..." in a Docker container also work, though?
> Presumably all the filesystem paths are being redirected anyway, so is there
> a difference?
>
> (My assum
Marc-Andre Lemburg added the comment:
On 23.04.2021 07:47, Inada Naoki wrote:
>
> Inada Naoki added the comment:
>
> I think it is too late. Python 3.9 has been released already. Reverting the
> change is also breaking change.
>
> PEP 100 says:
> "Search f
Marc-Andre Lemburg added the comment:
On 23.04.2021 03:37, akdor1154 wrote:
>
> akdor1154 added the comment:
>
> If I understand the target of this issue, this is a breaking change in python
> 3.9 .
>
> E.g. see https://github.com/SAP/PyHDB/issues/149
>
> I
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
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
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
Change by Marc-Andre Lemburg :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
Marc-Andre Lemburg added the comment:
Reviewed. Please check on the PR for comments.
--
___
Python tracker
<https://bugs.python.org/issue42257>
___
___
Pytho
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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"""
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
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
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
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
Change by Marc-Andre Lemburg :
--
Removed message: https://bugs.python.org/msg367514
___
Python tracker
<https://bugs.python.org/issue21081>
___
___
Python-bug
Change by Marc-Andre Lemburg :
--
Removed message: https://bugs.python.org/msg367515
___
Python tracker
<https://bugs.python.org/issue21081>
___
___
Python-bug
Change by Marc-Andre Lemburg :
--
Removed message: https://bugs.python.org/msg320603
___
Python tracker
<https://bugs.python.org/issue21081>
___
___
Python-bug
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
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
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
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
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
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
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
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
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
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
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
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
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.
-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
Marc-Andre Lemburg <m...@egenix.com> added the comment:
Thanks, Serhiy.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue20087>
___
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
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
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
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
Marc-Andre Lemburg <m...@egenix.com> added the comment:
Sounds like a good compromise :-)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
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
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
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
101 - 200 of 1900 matches
Mail list logo
