Marc-Andre Lemburg added the comment:
On 2008-12-15 16:34, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> Le lundi 15 décembre 2008 à 14:41 +0000, Marc-Andre Lemburg a écrit :
>> Why have you removed the complete error handling section in
>>
Changes by Marc-Andre Lemburg :
--
nosy: -lemburg
___
Python tracker
<http://bugs.python.org/issue1673409>
___
___
Python-bugs-list mailing list
Unsubscribe:
Marc-Andre Lemburg added the comment:
On 2008-12-17 00:25, Eric Eisner wrote:
> New submission from Eric Eisner :
>
> I discovered this when trying to splice a string containing unicode
> codepoints higher than U+
>
>
> all examples on 32-bit Ubuntu Linux
&
Marc-Andre Lemburg added the comment:
On 2008-12-17 00:53, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
>
> As Marc-Andre say, this is not a bug. Finding out the exact name of the
> configure option is left as an exercise.
Ah, so that changed as well... for Pyt
Marc-Andre Lemburg added the comment:
On 2008-12-20 11:54, Mark Dickinson wrote:
> New submission from Mark Dickinson :
>
> pybench needs to be updated for Python 3.0, in particular to remove use of
> cmp. Here's a patch, against the py3k branch.
>
> Questions (mainly
Marc-Andre Lemburg added the comment:
Please remember to add back PyUnicode_Compare() if that hasn't already
been done.
Thanks,
--
Marc-Andre Lemburg
eGenix.com
2008-12-02: Released mxODBC.Connect 1.0.0
Marc-Andre Lemburg added the comment:
On 2008-12-20 17:19, Alex Stapleton wrote:
> Alex Stapleton added the comment:
>
> I am trying to get a PEP together for this. Does anyone have any thoughts
> on how to handle comparison between unicode strings in a locale aware
> s
Marc-Andre Lemburg added the comment:
On 2008-12-21 22:37, Antoine Pitrou wrote:
> New submission from Antoine Pitrou :
>
> This patch prints opcode statistics at the end of a pybench run if
> DYNAMIC_EXECUTION_PROFILE has been enabled when compiling the interpreter.
>
&g
Marc-Andre Lemburg added the comment:
On 2008-12-22 15:07, Mark Dickinson wrote:
> Mark Dickinson added the comment:
>
> Thanks for the responses!
>
>> I don't think should go into 3.0.1 - they are a new feature
>> and not a bug fix.
>
> But if these c
Marc-Andre Lemburg added the comment:
On 2008-12-27 13:58, STINNER Victor wrote:
> Python 2.x allows to encode any byte string (str) and ASCII unicode
> string (unicode):
>
> $ python
> Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)
>>>> import zlib
>>>&g
Marc-Andre Lemburg added the comment:
On 2008-12-26 22:09, Antoine Pitrou wrote:
> This patch implements what is usually called "threaded code" for the
> ceval loop on compilers which support it (only gcc). The idea is that
> there is a separate opcode dispatch epilog at the
Marc-Andre Lemburg added the comment:
On 2008-12-30 13:20, John Machin wrote:
> byte-compiling C:\python26\Lib\site-packages\x9d.py to x9d.pyc
> SyntaxError: ('unknown encoding: cp1252',
> ('C:\\python26\\Lib\\site-packages\\x9d.py', 0, 0, None))
>
>
Marc-Andre Lemburg added the comment:
FWIW: POSIX defines Unix time_t *not* to include leap seconds.
You can easily check whether your platform or C lib behaves
POSIX-ly correct or not:
POSIX: 1986-12-31 23:59:59 UTC == 536457599 ticks
With leap seconds: == 536457612 ticks
Marc-Andre Lemburg added the comment:
On 2009-01-01 23:59, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> I've updated the comments as per Alexandre's request, added support for
> SUN CC, and fixed the generation script to use the new filename.
Since th
Marc-Andre Lemburg added the comment:
Moving declarations into header files is not really in line with the way
Python developers use header files:
We usually only put code into header files that is meant for public use.
Buy putting declarations into the header files without additional
Marc-Andre Lemburg added the comment:
Also note that by removing the extern "C" declarations, you not only
change the exported symbol names of functions, but also those of
exported globals.
Those would also have to get declared in the header files, to prevent
their names from bei
Marc-Andre Lemburg added the comment:
The added type casts are useful to have - even outside the context of
the idea behind the patch.
___
Python tracker
<http://bugs.python.org/issue4
Marc-Andre Lemburg added the comment:
On 2009-01-02 17:10, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
>> This is safer than enabling the support unconditionally for GCC and
>> the SUN Pro C compiler, since it is rather likely that some GCC versions
>&g
Marc-Andre Lemburg added the comment:
On 2009-01-05 17:09, Atsuo Ishimoto wrote:
> New submission from Atsuo Ishimoto :
>
> When I use Py_UNICODE_ISSPACE() in my C++ extension, I got following error.
>
> test.obj : error LNK2019: unresolved external symbol
> "__decls
Marc-Andre Lemburg added the comment:
On 2009-01-04 23:51, STINNER Victor wrote:
> STINNER Victor added the comment:
>
>> The fact that Python 2.x also accepts Unicode ASCII strings
>> where strings are normally expected is intended to help with
>> the migration to
Marc-Andre Lemburg added the comment:
On 2009-01-03 04:38, Alexander Belopolsky wrote:
> Alexander Belopolsky added the comment:
>
> On Fri, Jan 2, 2009 at 10:54 AM, Marc-Andre Lemburg
> wrote:
>> Marc-Andre Lemburg added the comment:
>>
>> Also note
Marc-Andre Lemburg added the comment:
On 2009-01-05 13:03, Marc-Andre Lemburg wrote:
> Marc-Andre Lemburg added the comment:
>
> On 2009-01-03 04:38, Alexander Belopolsky wrote:
>> Alexander Belopolsky added the comment:
>>
>> On Fri, Jan 2, 2009 at 10:54 AM, M
Marc-Andre Lemburg added the comment:
Fixed in r68344 on trunk.
Backport and forward-port candidate.
--
keywords: +26backport -patch
status: open -> closed
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/iss
Marc-Andre Lemburg added the comment:
On 2009-01-05 18:54, Alexander Belopolsky wrote:
> I also wonder whether it would be more appropriate to redefine PyAPI_*
> macros to declare API symbols with extern "C" when compiled under C++?
> This seems to be a better approach
Marc-Andre Lemburg added the comment:
On 2009-01-05 19:55, Alexander Belopolsky wrote:
> The allocs counters (tuple_zero_allocs, fast_tuple_allocs,
> quick_int_allocs, quick_neg_int_allocs) present a case where it is
> really hard to justify a change that is only motiv
Marc-Andre Lemburg added the comment:
On 2009-01-05 22:06, Alexander Belopolsky wrote:
> Alexander Belopolsky added the comment:
>> Given that you can build Python as library on Unix and as DLL on
>> Windows, there doesn't appear to be any need to actually be able
>&
Marc-Andre Lemburg added the comment:
On 2009-01-06 11:28, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
>
> Making it static is fine. I don't recall what kind of customization I
> did when I introduced it.
>
> I'm skeptical about the entire issue,
Marc-Andre Lemburg added the comment:
On 2009-01-06 13:28, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
>
>> For completeness
>
> I don't think completeness is a useful thing to have here.
>
>> and to make things easier for all developers,
Marc-Andre Lemburg added the comment:
On 2009-01-06 14:22, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
>
>> I'm only referring to exported symbols. Static globals, of course,
>> don't need such a prefix.
>
> Ok, the symbols in question
Marc-Andre Lemburg added the comment:
On 2009-01-06 15:57, Alexander Belopolsky wrote:
> Alexander Belopolsky added the comment:
>
> On Tue, Jan 6, 2009 at 7:28 AM, Martin v. Löwis
> wrote:
> ..
>> It is not easier, but more difficult. It now requires a change,
>>
Marc-Andre Lemburg added the comment:
On 2009-01-06 21:06, Lukas Lueg wrote:
> MD5 is one of the most popular cryptographic hash-functions around,
> mainly for it's good performance and availability throughout
> applications and libraries. The MD5 algorithm is currently implement
Marc-Andre Lemburg added the comment:
On 2009-01-06 22:42, Lukas Lueg wrote:
> Lukas Lueg added the comment:
>
> As I already said to Raymond: At least we should update the
> documentation. The "FAQ" currently linked is from 2005.
>
> The CERT-Advisory from
Marc-Andre Lemburg added the comment:
On 2009-01-06 23:10, Lukas Lueg wrote:
> Lukas Lueg added the comment:
>
>> It might be a good idea to remove the word "secure" from the
>> hashlib documentation, since security of these algorithms is
>> always l
Marc-Andre Lemburg added the comment:
On 2009-01-07 10:33, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
>
>> However, they are still exported from the object files,
>
> Ah. Those are "global symbols", not "exported symbols"; "export
Marc-Andre Lemburg added the comment:
On 2009-01-07 16:25, Antoine Pitrou wrote:
> New submission from Antoine Pitrou :
>
> Here is a patch to speedup utf8 decoding. On a 64-bit build, the maximum
> speedup is around 30%, and on a 32-bit build around 15%. (*)
>
>
Marc-Andre Lemburg added the comment:
On 2009-01-08 01:59, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> Patch replacing "s*" parsing format by "y*" for:
> - utf_7_decode()
> - utf_8_decode()
> - utf_16_decode()
> -
Marc-Andre Lemburg added the comment:
On 2009-01-07 01:21, Amaury Forgeot d'Arc wrote:
> First write a utf-16 file with its signature:
>
>>>> f1 = open('utf16.txt', 'w', encoding='utf-16')
>>>> f1.write('0123456789')
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> Attached patch adds acceleration for latin1 and utf16 decoding as well.
>
> All three codecs (utf8, utf16, latin1) are now in the same ballpark
> performance-wise on favo
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> Marc-Andre, this patch should address your comments.
>
> Added file: http://bugs.python.org/file12656/decode6.patch
Thanks. Much better !
BTW: I'd also change the var
Marc-Andre Lemburg added the comment:
On 2009-01-10 10:55, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
>> It looks like we still didn't manage, and since ICC is the best
>> compiler out there, this matters.
>
> Well, from the perspective of Pytho
Marc-Andre Lemburg added the comment:
On 2009-01-13 14:14, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> The patch is probably fine, but it would be nice to add some unit tests
> for the new behaviour.
+1 from my side.
Thanks for the p
Marc-Andre Lemburg added the comment:
On 2009-01-17 14:00, STINNER Victor wrote:
>> A test would be good, too.
>
> PyUnicode_FromWideChar() is not a public API. Should I write a function in
> _testcapi?
It is a public C API. Regardless of this aspect, we should always
add te
Marc-Andre Lemburg added the comment:
On 2009-01-17 14:00, STINNER Victor wrote:
> STINNER Victor added the comment:
>
>> Looks pretty good at first glance, except that it seems that the UTF-32 to
>> UTF-16 translation is skipped if HAVE_USABLE_WCHAR_T is defined. Is
Marc-Andre Lemburg added the comment:
On 2009-01-18 22:59, Mark Dickinson wrote:
> Mark Dickinson added the comment:
>
> Looks good to me.
>
> I'm not in a position to test with 16-bit wchar_t, but I can't see why
> anything would go wrong. I think we can tak
Marc-Andre Lemburg added the comment:
On 2009-01-21 16:43, Torsten Bronger wrote:
> Torsten Bronger added the comment:
>
> I ran into this problem today when writing python data structures into a
> database. Only ASCII is safe in this situation. I understood the
> Python doc
Marc-Andre Lemburg added the comment:
Note that distutils was removed from PEP 291 in r1982 "After some
discussion at the distutils sprint at PyCon 2005".
This was not discussed on the distutils mailing list at the time which I
regard as not in line with the way Python or di
Marc-Andre Lemburg added the comment:
On 2009-01-26 17:56, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> @marketdickinson, @lemburg: ping! I updated the patch, does it look
> better?
Yes, but there are a few things that still need fixing:
* SIZEOF_WCHAR_T is
Marc-Andre Lemburg added the comment:
On 2009-02-01 00:39, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> The patch changes results a lot compared to the previous version
> (BuiltinFunctionCalls is 3x slower). I propose the following patch,
> which gives r
Marc-Andre Lemburg added the comment:
Some more explanation for why keeping distutils Python 2.3 compatible is
desirable:
distutils was removed from the PEP without any public discussion outside
a sprint at PyCon and the reasons given for it did not take into account
that people will want to
Marc-Andre Lemburg added the comment:
The distutils version number is now updated automatically by the Python
release process, so the comment in that file can be removed.
___
Python tracker
<http://bugs.python.org/issue1
Marc-Andre Lemburg added the comment:
On 2009-02-03 13:39, Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc added the comment:
>
> Since r56395, ord() and chr() accept and return surrogate pairs even in
> narrow builds.
>
> The goal is to remove most differe
Marc-Andre Lemburg added the comment:
On 2009-02-03 14:14, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> amaury> Since r56395, ord() and chr() accept and return surrogate pairs
> amaury> even in narrow builds.
>
> Note: My examples are made with Pytho
Marc-Andre Lemburg added the comment:
On 2009-02-03 14:50, Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc added the comment:
>
>> That would cause major breakage in the C API
>
> Not if you recompile. I don't see how this breaks the API at the C level.
Marc-Andre Lemburg added the comment:
On 2009-02-05 14:23, Thomas Heller wrote:
> Thomas Heller added the comment:
>
>> The distutils version number is now updated automatically by the Python
>> release process, so the comment in that file can be removed.
>
> How
Marc-Andre Lemburg added the comment:
Perfect ! Thanks, Antoine. Please check it in.
On 2009-02-06 18:19, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> Updated patch.
>
> Added file: http://bugs.python.org/file12956/pyb
Marc-Andre Lemburg added the comment:
On 2009-02-06 18:35, Marc-Andre Lemburg wrote:
> Marc-Andre Lemburg added the comment:
>
> Perfect ! Thanks, Antoine. Please check it in.
Well, except for this part that sneaked in:
@@ -4,8 +4,6 @@
"""
#
-# Note: Please keep t
Marc-Andre Lemburg added the comment:
On 2009-02-06 23:25, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
>> It's ok to bump this to Python 2.3, though :-)
>
> The current version only works with 3.x, due to the use of the print
> function with
Marc-Andre Lemburg added the comment:
Hi Martin, wouldn't just uploading the pythonXX.pdb to the release page
be enough.
The distributed DLL already points to the source location on your system
:-) E.g. for Python 2.5, this was c:\loewis\25\python\PCbuild\python25.pdb
Or are you thinki
Changes by Marc-Andre Lemburg :
--
versions: +Python 2.7, Python 3.0
___
Python tracker
<http://bugs.python.org/issue1303434>
___
___
Python-bugs-list mailin
Marc-Andre Lemburg added the comment:
On 2009-02-11 22:20, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
>
>> Hi Martin, wouldn't just uploading the pythonXX.pdb to the release page
>> be enough.
>
> It's not clear to me what is being requeste
Marc-Andre Lemburg added the comment:
Could you please clarify the official status of this encoding. According
to this page:
http://www.terena.org/activities/multiling/koi8-ru/index.html
it is currently only a proposed draft which hasn't been updated since 1997.
--
nosy: +le
Marc-Andre Lemburg added the comment:
On 2009-02-12 12:49, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> ajaksu2> Not sure it's still important after 3.0 release.
>
> Python2 has too much issues related to unicode. It's easier to switch
>
Marc-Andre Lemburg added the comment:
On 2009-02-12 14:22, STINNER Victor wrote:
> STINNER Victor added the comment:
>
>> Python3 fixes the "print" statement to be a function, which allows
>> much better extensibility of the concept.
>>
>> You can have
Changes by Marc-Andre Lemburg :
--
stage: test needed -> needs patch
___
Python tracker
<http://bugs.python.org/issue460474>
___
___
Python-bugs-list mai
Marc-Andre Lemburg added the comment:
Like I said a few years: this can go in. Python is used a lot in the
financial industry.
The code page is referenced in this RFC:
http://rfc.dotsrc.org/rfc/rfc1345.html
This page has a good comparison of the various IBM code pages as shipped
with
Marc-Andre Lemburg added the comment:
I agree with Michael's comment.
Note that uname -p is hardly ever needed. uname -m is more important and
that's supported on Debian (and exposed via platform.machine()).
--
nosy: +lemburg
status: open
Marc-Andre Lemburg added the comment:
FWIW: I don't think the "locale" encoding is a good idea. Instead of
trying to fix this to make it more usable, I'd suggest to deprecate
and remove it again.
When it comes to encodings, explicit is better than implicit.
If an appli
Marc-Andre Lemburg added the comment:
On 23.03.2022 02:12, Gregory P. Smith wrote:
>
> I view the NIST standard hashes as important enough to attempt to guarantee
> as present (all the SHAs and MD5) as built-in. Others should really
> demonstrate practical application popula
Marc-Andre Lemburg added the comment:
On 23.03.2022 17:53, Larry Hastings wrote:
>
> Ok, I give up.
Sorry to spoil the fun, but there's no need to throw
everything in the bin ;-)
A lean and fast blake3 C package would still be a great thing
to have on PyPI, e.g. provide
Marc-Andre Lemburg added the comment:
With "lean" I meant: doesn't use much code and is easy to compile
and install.
I built a wheel from Jack's experimental package and it comes out to
just under 100kB on Linux x64, compared to around the 1.1MB the
Rust w
Marc-Andre Lemburg added the comment:
Here's a wheel which only includes the portable code (I disabled
all the special cases as you suggested).
Archive: dist/blake3_experimental_c-0.0.1-cp310-cp310-linux_x86_64.whl
Length DateTime
Marc-Andre Lemburg added the comment:
On 26.03.2022 08:59, Nick Coghlan wrote:
>
> The import system is already complex, so I think the hesitation about
> allowing arbitrary Path-like objects is warranted. (For example: are
> importlib's caching semantics really valid for
Marc-Andre Lemburg added the comment:
On 27.03.2022 09:56, Hubert Tournier wrote:
>
> The storage format used under Windows is completely different from the one
> used under Unix (or *BSD).
The shelve module uses the dbm module underneath and this will pick
its storage mechanism
Marc-Andre Lemburg added the comment:
Please see https://bugs.python.org/issue47000#msg415769 for what Victor
suggested.
In particular, the locale module uses the "no underscore" convention.
Not sure whether it's good to start using snake case now, but I'm also
not again
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/is
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:
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
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 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 syste
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
>
> Idea
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 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 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
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 glo
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:
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
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:
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 po
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 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/
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
Marc-Andre Lemburg added the comment:
On 31.08.2021 20:14, Brett Cannon wrote:
>
> Brett Cannon added the comment:
>
>> set __file__ (and __path__) on frozen modules?
>
> See https://bugs.python.org/issue21736
The patch on that ticket is straight from PyRun, where the
Marc-Andre Lemburg added the comment:
FWIW, I've not found the importer for frozen modules to be lacking
features. When using frozen modules, you don't expect to see source
code, so the whole part about finding source code is not really
relevant for that use case.
The only lack
Marc-Andre Lemburg added the comment:
Just to be clear: The Python code page encodings are (mostly) taken from the
unicode.org set of mappings (ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/).
This is our standards body for such mappings, where possible. In some cases,
the Unicode
Marc-Andre Lemburg added the comment:
Yes, this is intended. ASCII is used as fallback in case Python
cannot determine the I/O encoding to use during startup. This is
also the reason why later changes to the environment have no
affect on this - the determination of the encoding has already
Marc-Andre Lemburg added the comment:
On 17.09.2021 15:45, Olivier Delhomme wrote:
>
> Olivier Delhomme added the comment:
>
> Hi Marc-Andre,
>
> Please note that setting PYTHONUTF8 with "export PYTHONUTF8=1":
>
> * Is external to the program and user
Change by Marc-Andre Lemburg :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Marc-Andre Lemburg added the comment:
FWIW: Back in the days of Python 1.5.2, the ceval loop was too big for CPU
caches as well and one of the things I experimented with at the time was
rearranging the opcodes based on how often they were used and splitting the
whole switch statement we had
Marc-Andre Lemburg added the comment:
Such a change would be backwards incompatible and no longer in line with PEP
249.
I also don't understand what you regard as confusing about the message "unable
to open database file". The message could be extended to include the path,
Marc-Andre Lemburg added the comment:
Perhaps a frozen dict could be used instead of the linear search.
This could then also be made available as sys.frozen_modules for inspection by
applications and tools such as debuggers or introspection tools trying to find
source code (and potentially
701 - 800 of 1946 matches
Mail list logo
