Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> New submission from Antoine Pitrou :
>
> The use of sys.setdefaultencoding() has always been discouraged, and it has
> become a no-op in py3k (the encoding is hard-wired to utf-8 and changing it
> raises an
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> Attached patch fixes the issue by creating a separate "_bootlocale" module,
> used at bootstrap, which doesn't import collections, functools and friends.
I do
Marc-Andre Lemburg added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
>> I don't think that's the right way forward.
>>
>> It's much easier to either remove the need to import those
>> extra modules or defer
Marc-Andre Lemburg added the comment:
STINNER Victor wrote:
>
> New submission from STINNER Victor :
>
> Lib/platform.py was created 7 years ago by r32391. _syscmd_file() docstring
> was never changed whereas it is inconsistent with the implementation:
> ---
> def _syscm
Marc-Andre Lemburg added the comment:
Why are you removing the introductory section on how mappings work ?
Also, this wording needs to be corrected: "bytes (integers in the range from 0
to 255)". Bytes are not integers. I'd suggest to use the more correct wording
"bytes
Marc-Andre Lemburg added the comment:
On 28.11.2016 12:24, Serhiy Storchaka wrote:
>> Why are you removing the introductory section on how mappings work ?
>
> Because it is not correct. I copied it to descriptions of concrete functions
> with correcting it according to the
Marc-Andre Lemburg added the comment:
The codec code has a few (performance) issues:
* nonspacing_diacritical_marks should be a set for fast lookup
* ord(c) in range(0x00, 0xA0) should be rewritten using < and >=
* result += bytes([ord(c)]) has exponential timing (it copies
the
Marc-Andre Lemburg added the comment:
If we just restrict this to the file system encoding (and not the whole LANG
setting), how about:
* default the file system encoding to 'utf-8' and use the surrogate escape
handler as default error handler
* add a PYTHONFSENCODING env var
Marc-Andre Lemburg added the comment:
Please try to install this update from MS:
https://support.microsoft.com/en-us/kb/2999226
it includes the missing DLL.
--
nosy: +lemburg
___
Python tracker
<http://bugs.python.org/issue28
Marc-Andre Lemburg added the comment:
Thanks for the patch.
Victor has implemented the function in C, AFAIK, so an even better approach
would be to expose that function at the Python level and use it in the
encodings package.
--
versions: +Python 3.7 -Python 3.4, Python 3.5
Marc-Andre Lemburg added the comment:
On 17.12.2016 08:56, Nick Coghlan wrote:
>
> Making an explicit note of this so I remember to mention it in the draft PEP:
> one of the biggest problems that arises in any attempt at a Python-only
> solution to overriding the locale is that w
Marc-Andre Lemburg added the comment:
time.time() is not quite UTC on Unix: it usually (*) doesn't include leap
seconds, which UTC does.
The Wikipedia page has a good definition and explanation:
https://en.wikipedia.org/wiki/Unix_time
(*) "usually" because POSIX defines time()
Marc-Andre Lemburg added the comment:
I believe you need to report this problem to the setuptools maintainers. The
stdlib distutils itself never defined a setup() argument 'bugtrack_url', so
raises a warning when seeing this argument.
--
nosy
Marc-Andre Lemburg added the comment:
I did some more research: setuptools didn't have this keyword either.
It was added to PyPI at some point and then probably got picked up by some
package authors as new "optional" keyword argument for setup():
http://stackoverflow.com/que
Marc-Andre Lemburg added the comment:
As general comment, I think you'd have to check which operation modes SQLite
supports for the case of a transaction commit/rollback in the light of open
cursors.
ODBC defines the following cases and each data source can specify a different
beh
Marc-Andre Lemburg added the comment:
On 05.01.2017 10:26, Nick Coghlan wrote:
>
> Anything purely on the Python side of things doesn't work in a traditional C
> environment - CPython relies on the C lib to do conversions during startup,
> so we need the C locale to be set
Marc-Andre Lemburg added the comment:
While going for the full locale setting may be a good option,
perhaps just focusing on the FS encoding for now is a better
way forward (and also more in line with the ticket title).
So essentially go for the PEP 529 approach on Unix as well
(except that we
Marc-Andre Lemburg added the comment:
I don't think this can be considered a bug fix, since it changes behavior for
applications that read data from SQLite databases which were not created by
Python.
Those application may now see datetime values with tz infos and will likely not
be pre
Marc-Andre Lemburg added the comment:
On 11.01.2017 17:08, Serhiy Storchaka wrote:
>
> The naive datetime converter is registered under the name "timestamp". The
> aware datetime converter or the universal datetime converter (if it is
> needed) can be registered under
Marc-Andre Lemburg added the comment:
On 11.01.2017 17:04, Xiang Zhang wrote:
> I am not sure it's worth to make it even optional in 3.7. Discarding tzinfo
> sounds weird, and worse, the behaviour is not deterministic, it could also
> fail with an exception.
Best practice is to
Marc-Andre Lemburg added the comment:
I think Ronald's patch issue18378-2015-07-25-py36.txt with added darwin check
would be the best way forward.
In the current form, it would allow using 'UTF-8' as locale string on all
platforms - which is not such a good idea.
--
Marc-Andre Lemburg added the comment:
On 13.01.2017 04:47, Nick Coghlan wrote:
> Accepting "UTF-8" and interpreting it as functionally equivalent to C.UTF-8
> will mean that this setting will at least work as desired on servers that
> offer C.UTF-8.
I don't think th
Marc-Andre Lemburg added the comment:
Adding Victor, who implemented the fs codec.
AFAIK, it's not possible to change the encoding after interpreter
initialization, since it will have been already used for many different things
by the time you get to executing code.
--
nosy: +
Marc-Andre Lemburg added the comment:
According to the datetime.h file, the valid range for year is 1-, so it's a
bit surprising that Python 3.6 allows dates outside this range.
Internally, the year is represented using 2 bytes, so you could represent years
outside the range and
Marc-Andre Lemburg added the comment:
>> The only part that is not correct is "single string characters".
>> This should read "single bytes" or "bytes strings of length 1".
>
> This is not correct. Decoding mappings map not bytes strings, but
Marc-Andre Lemburg added the comment:
Reading the ticket, it seems that there is some confusion about what LDSHARED
and BLDSHARED are used for. BLDSHARED is used to override the LDSHARED value
when building libpython and the shared modules (via setup.py).
LDSHARED is what is meant to be used
Marc-Andre Lemburg added the comment:
Hmm, looking at the patch again:
diff -r a089a8b1f93d Lib/sysconfig.py
--- a/Lib/sysconfig.py Fri Jun 21 18:37:02 2013 -0400
+++ b/Lib/sysconfig.py Fri Jun 21 22:33:15 2013 -0700
@@ -368,7 +368,7 @@
# -- these paths are relative to the Python source
Marc-Andre Lemburg added the comment:
BTW: Does the ticket still apply to 3.5+ ? From reading the ticket, it seems
that the problem is already fixed for those versions.
--
___
Python tracker
<http://bugs.python.org/issue18
Marc-Andre Lemburg added the comment:
On 24.01.2017 15:23, Michael Felt wrote:
> As far as issue10656 and this issue are concerned:
>
> Python-3.4 is out of context (but 3.4.6 was just released) - and does not
> work with 'out of tree' builds.
>
> The other versi
Marc-Andre Lemburg added the comment:
On 24.01.2017 16:47, Eric N. Vander Weele wrote:
>
> I have a (large) patch that completely eliminates the need for ld_so_aix and
> makeexp_aix. I've applied and been using this with for Python 2.7 and 3.5+,
> but I still need to go back
Marc-Andre Lemburg added the comment:
On 01.02.2017 10:50, INADA Naoki wrote:
>
>> it seems as if it would make sense to not use a fixed
>> hash algorithm for all strings lengths, but instead a
>> hybrid one to increase performance for short strings
>> (which are used
Marc-Andre Lemburg added the comment:
On 01.02.2017 11:07, Serhiy Storchaka wrote:
>
> The performance of hash algorithm shouldn't affect general benchmarks since
> hash value is cached inside string object. Almost all dict lookups in
> critical parts are lookups with interne
Marc-Andre Lemburg added the comment:
On 01.02.2017 13:03, INADA Naoki wrote:
> Maybe, we should remove Py_HASH_CUTOFF completely?
I think we ought to look for a better hash algorithm
for short strings, e.g. a CRC based one.
Some interesting investigations on this:
http://www.orthogonal.com
Marc-Andre Lemburg added the comment:
I'm still -1 on the approach taken by the OP, but +1 on Martin's approach of
making such configurations more easily possible via Modules/Setup.
--
___
Python tracker
<http://bugs.python.o
Marc-Andre Lemburg added the comment:
Please note that the two sets of APIs are not identical, e.g. you cannot simply
replace PyEval_CallObject() with PyObject_Call(), since the former applies a
few extra checks and defaults, which the latter doesn't.
--
nosy: +le
Marc-Andre Lemburg added the comment:
Thanks, but you missed the main difference:
The argument tuple can be NULL for PyEval_CallObject() (it then gets replaced
with an empty tuple), but will raise a segfault for PyObject_Call().
Now, apart from looking at the use cases in the core, you also
Marc-Andre Lemburg added the comment:
PyEval_CallObject wasn't removed. It's a macro now. And it was documented for a
long time in Extending Python... in fact, the documentation was removed, not
the API :-)
--
___
Python trac
Marc-Andre Lemburg added the comment:
The PyEval_Call*() APIs indeed predate the PyObject_Call*() ones. The
PyObject_Call*() APIs came into existence when the abstract layer was added in
Python 1.3.
The PyObject_Call*() APIs lacked a way to call an object with keyword arguments
for a long
Marc-Andre Lemburg added the comment:
Looking through Python's history, it's interesting that PyObject_Call() did
apply the args == NULL checks up until Python 2.1.
In Python 2.2 this was replaced by a direct call to tp_call, without the
checks. However, the tp_call slots don'
Marc-Andre Lemburg added the comment:
On 14.02.2017 11:16, STINNER Victor wrote:
>
>> Please note that the two sets of APIs are not identical, e.g. you cannot
>> simply replace PyEval_CallObject() with PyObject_Call(), since the former
>> applies a few extra checks an
Marc-Andre Lemburg added the comment:
Indeed, there are two issue with the .tgz file:
* it uses "staff" as group for all files (which will likely exist on some
systems), but this appears unrelated in you case
* all subdirs have go-x set, which prevents changing into the dir if you&
Marc-Andre Lemburg added the comment:
While "functions" may not be accurate anymore, they are all callables.
Historically, those callables were functions. Later on some of the built-ins
were replaced with type objects.
Regarding your last comment: It is common in Python to write &q
Marc-Andre Lemburg added the comment:
I don't think rewriting party of site.py in C is a good idea. It's a rather
maintenance intense module.
However, optimizing access is certainly something that's possible, e.g. by
placing the few variables that are actually needed by
Marc-Andre Lemburg added the comment:
Thanks for the report, but there really isn't much we can do, since the API is
not geared up for handling executables which contain binaries for multiple
architectures.
AFAIK, the Python 3 binaries available from python.org are no longer bui
Marc-Andre Lemburg added the comment:
Ok, thanks for the clarification. So if I understand correctly, the main change
in Python 3 is that points to the stub launcher, not the binary itself.
In any case, a new function would have to be added to the platform module to
query multiple
Marc-Andre Lemburg added the comment:
I think there's a misunderstanding in what platform.architecture() is meant
for. The purpose is to find out more details about the executable you pass to
it, e.g. whether it's a 32-bit or 64-bit binary, or whether it's an ELF or PE
binary.
Marc-Andre Lemburg added the comment:
The term "linkage" is probably a misnomer... "execformat" would be more correct:
* https://en.wikipedia.org/wiki/Comparison_of_executable_file_formats
Too late to change, I guess.
--
___
P
Marc-Andre Lemburg added the comment:
The purpose of __version__ in the platform module is to be able to use it with
other Python as well (and then detect which version is available in
applications).
So I think it's good to keep it a
Changes by Marc-Andre Lemburg :
--
assignee: -> lemburg
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python
Marc-Andre Lemburg added the comment:
Hmm, not sure why the merge is not showing up on the ticket.
Here's the link:
https://github.com/python/cpython/commit/6059ce45aa96f52fa0150e68ea655fbfdc25609a
--
___
Python tracker
<http://bugs.py
Marc-Andre Lemburg added the comment:
Just found this ticket and apparently late to the game...
Some comments:
It is already possible to selectively build Python C extension modules in the
stdlib via editing the Modules/Setup file and this is a lot better to maintain
than a long list of
Marc-Andre Lemburg added the comment:
On 07.06.2016 13:27, Alex Gaynor wrote:
>
> This doesn't look correct to me. Despite what the Linux maintainers insist,
> it's a _bug_ that /dev/urandom will return immediately if the system's
> entropy pool has never been seed
Marc-Andre Lemburg added the comment:
On 07.06.2016 13:36, Donald Stufft wrote:
> No where in the documentation of ``os.urandom`` does it ever promise it will
> not block. In fact, on systems like FreeBSD where their /dev/urandom is
> better than Linuxes it always blocked on start u
Marc-Andre Lemburg added the comment:
On 07.06.2016 13:51, Donald Stufft wrote:
>
> Donald Stufft added the comment:
>
>> That's pretty much in line with what the implementation now does.
>
> Literally the first line of the os.urandom documentation is "Retur
Marc-Andre Lemburg added the comment:
On 07.06.2016 14:19, Donald Stufft wrote:
>
>> Note how the documentation emphasizes on os.urandom() not blocking.
>
> That line about not-blocking was added by the patch that Victor committed
> that we're objecting to.
Ah, sorr
Marc-Andre Lemburg added the comment:
Should this ticket be named "Add os.random()" ? After all,
blocking in case of missing entropy is what /dev/random is
all about.
--
nosy: +lemburg
___
Python tracker
<http://bugs.python.o
Marc-Andre Lemburg added the comment:
On 07.06.2016 14:40, Donald Stufft wrote:
>
> Donald Stufft added the comment:
>
> (Basically) nobody should ever use /dev/random (and cryptographers agree!).
> The thing you want to use is /dev/urandom and the fact that /dev/urandom on
Marc-Andre Lemburg added the comment:
On 07.06.2016 14:41, Cory Benfield wrote:
>
> Uh, sorry, I meant #26839.
Ok, then perhaps "Add os.getrandom()" - also see the discussion
there :-)
--
___
Python tracker
<http://bugs.py
Marc-Andre Lemburg added the comment:
On 07.06.2016 15:12, Donald Stufft wrote:
>
> Since there's obviously contention about what the right answer here is, I
> suggest we should revert the patch (since the old behavior already exists in
> 3.5 and is shipped to thousands of pe
Marc-Andre Lemburg added the comment:
On 07.06.2016 15:21, Donald Stufft wrote:
>
> The patch causes a regression because I'm relying on the 3.5 behavior of
> getting secure randomness from ``os.urandom`` via the ``getrandom()`` system
> call (behavior that was documented in
Marc-Andre Lemburg added the comment:
On 07.06.2016 16:18, Donald Stufft wrote:
>
> Donald Stufft added the comment:
>
>> I just don't understand why you are apparently not willing to even consider
>> compromises.
>
> I have one thing that I hold immutable
Marc-Andre Lemburg added the comment:
On 07.06.2016 16:59, Christian Heimes wrote:
>
> Christian Heimes added the comment:
>
> On 2016-06-07 16:49, Marc-Andre Lemburg wrote:
>> This gives people a clear choice and doesn't cause people
>> to have to reconsider us
Marc-Andre Lemburg added the comment:
On 07.06.2016 21:12, Cory Benfield wrote:
>
>> Python hash randomization only happens once. So it's not a matter of how
>> early we try the attack, it's a matter of how early we seed Python hash
>> randomization.
>
&
Marc-Andre Lemburg added the comment:
Even though it may sound like a minor problem that os.urandom()
blocks on startup, I think the problem is getting more and more
something to consider given how systems are used nowadays.
Today, we no longer have the case where you keep a system up
and
Marc-Andre Lemburg added the comment:
On 08.06.2016 22:49, Larry Hastings wrote:
>
> Third, because the os module is in general a thin wrapper over what the OS
> provides, I disapprove of "cryptorandom()" and "pseudorandom()" going into
> the os module. T
New submission from Marc-Andre Lemburg:
I propose to deprecate os.urandom() altogether due to all the
issues we've discussed on all those recent tickets, see e.g.
#26839, #27250, #25420.
Unlike what we've told people for many years, it's clear that in the
age of VMs/containers
Marc-Andre Lemburg added the comment:
I propose to deprecate os.urandom() altogether due to all the
issues we've discussed on all those recent tickets.
See #27279 for details.
On 09.06.2016 02:04, Nick Coghlan wrote:
> I'd also *STRONGLY* request that we avoid adding any new API
Marc-Andre Lemburg added the comment:
Please also see #27279 for an alternative plan.
--
___
Python tracker
<http://bugs.python.org/issue27250>
___
___
Python-bug
Marc-Andre Lemburg added the comment:
Fleshing out the API signatures and implementation details will have to be done
in a PEP.
The topic is (as all the related ticket show) too complex for discussions on a
bug tracker.
I just opened this ticket for reference to the idea
Marc-Andre Lemburg added the comment:
On 09.06.2016 09:57, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> I played with select() on Linux on a VM:
>
> * /dev/random: it works as expected
> * /dev/urandom: the device is already seen as readable even
Marc-Andre Lemburg added the comment:
Some resources:
* getrandom() man page:
http://man7.org/linux/man-pages/man2/getrandom.2.html
* nice readup on how getrandom() was introduced:
https://lwn.net/Articles/606141/
* random devices implementation on Linux:
http://lxr.free
Marc-Andre Lemburg added the comment:
On 09.06.2016 10:07, Larry Hastings wrote:
>
> I +1 on new functions that are designated the best-practice places to get
> your pseudo-random numbers.
>
> (IDK if the best place for both is in random; maybe the crypto one should be
> in
Marc-Andre Lemburg added the comment:
On 09.06.2016 10:16, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> Marc-Andre Lemburg:
>> I propose to deprecate os.urandom() altogether due to all the issues we've
>> discussed on all those recent tickets
Marc-Andre Lemburg added the comment:
Some more resources for FreeBSD:
* /dev/random and /dev/urandom (symlink to /dev/random) ma page:
https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4
* Developer discussion about /dev/random and its future from 2013:
https://wiki.freebsd
Marc-Andre Lemburg added the comment:
Resources for entropy gathering sources:
* Kernel based devices such as /dev/random:
https://en.wikipedia.org/wiki//dev/random
* EGD - old entropy gathering daemon; blocks when out of
entropy
http://egd.sourceforge.net/
(not maintained
Marc-Andre Lemburg added the comment:
At the time the code was written, libc and glibc were in wide spread use, so
it's not surprising that it doesn't work well for other C libs.
Note that the routine returns the highest libc version number used and required
by the executable (u
Marc-Andre Lemburg added the comment:
That must have been an oversight. __version__ should read '0.8.0'.
--
___
Python tracker
<http://bugs.python.o
Marc-Andre Lemburg added the comment:
On 20.02.2013 12:48, albertjan wrote:
>
> New submission from albertjan:
>
> This is almost identical to: http://bugs.python.org/issue854511
> However, tis602, which is mentioned in the orginal bug report, is not an
> alias to cp874. Th
Marc-Andre Lemburg added the comment:
On 20.02.2013 15:58, Benjamin Peterson wrote:
>
> Benjamin Peterson added the comment:
>
> The "locale" module does not affect Unicode operations. That's C locale; I'm
> talking about concept of Unicode locale,
Marc-Andre Lemburg added the comment:
On 20.02.2013 15:40, albertjan wrote:
>
> albertjan added the comment:
>
> Hi,
>
> I found this report that includes your name:
> http://mail.python.org/pipermail/python-bugs-list/2004-August/024564.html
>
> Othe
New submission from Marc-Andre Lemburg:
We have implemented the context manager API for connections and cursors in our
mxODBC module and this works fine in Python 2.6.
In Python 2.7 we get the following error:
Traceback (most recent call last):
File "context-manager.py",
Marc-Andre Lemburg added the comment:
After some experiments, it turned out that by simply filling in the tp_methods
slot, the problem went away.
Still, the change to use _PyObject_LookupSpecial() appears to have missed the
(older) use case where you don't define tp_members, but in
Marc-Andre Lemburg added the comment:
On 21.02.2013 17:36, Marc-Andre Lemburg wrote:
>
> After some experiments, it turned out that by simply filling in the
> tp_methods slot, the problem went away.
Sorry: *tp_methods*, not t
Marc-Andre Lemburg added the comment:
On 21.02.2013 17:36, Marc-Andre Lemburg wrote:
> After some experiments, it turned out that by simply filling in the
> tp_methods slot, the problem went away.
>
> Still, the change to use _PyObject_LookupSpecial() appears to have missed the
&
Changes by Marc-Andre Lemburg :
--
Removed message: http://bugs.python.org/msg182601
___
Python tracker
<http://bugs.python.org/issue17268>
___
___
Python-bug
New submission from Marc-Andre Lemburg:
The feature to run a ZIP file containing Python modules is not documented.
It was implemented in Python 2.6:
* http://bugs.python.org/issue1739468
and mentioned in the "What's new":
*
http://docs.python.org/2/whatsnew/2.6.html?highlig
Marc-Andre Lemburg added the comment:
Adding support for locales that are not recognized is easy and the locale
parser could also learn about formats that it doesn't yet understand, so
patches are welcome.
The main problem here is that setlocale() only understands a very limited se
Marc-Andre Lemburg added the comment:
On 23.03.2013 16:39, Steve Dower wrote:
>
> Steve Dower added the comment:
>
>>> This becomes more of an issue since VC++ 2008 Express is no longer
>>> available for download (unless you're an MSDN subscriber)
>>
&
Marc-Andre Lemburg added the comment:
On 23.03.2013 22:33, Steve Dower wrote:
>
> Steve Dower added the comment:
>
>>> That's just the service pack and it won't install unless you already have
>>> VS installed. There is no way (other than being an MSDN su
Marc-Andre Lemburg added the comment:
On 25.03.2013 23:11, Terry J. Reedy wrote:
> 2. The codecs.writelines entry says "Writes the concatenated list of strings
> to the stream (possibly by reusing the write() method)." For the base class,
> that is overly restrictive, but
Marc-Andre Lemburg added the comment:
On 31.03.2013 21:29, Larry Hastings wrote:
>
> Larry Hastings added the comment:
>
> For the record: I care. Generally speaking CPython is a lovingly
> crafted source tree, and the choices its architects made are nearly
> always sensible
Marc-Andre Lemburg added the comment:
On 30.03.2013 13:09, Mark Lawrence wrote:
>
> Is it worth applying the patch given the complete rewrite of unicode for 3.3
> via PEP393?
PEP 393 only changed the way Unicode is internally stored.
The Unicode API is mostly unaffected by th
Marc-Andre Lemburg added the comment:
I don't think that's enough documentation for the feature. There's a whole PEP
338 just for the -m option due to the subtle issue associated with the "run a
module" logic, so I'd expect somewhat more detail or an update of th
Changes by Marc-Andre Lemburg :
--
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue17359>
___
___
Python-bugs-list mailing list
Unsubscribe:
Marc-Andre Lemburg added the comment:
I still don't think that the available documentation is detailed enough. It
leaves too many unanswered question, e.g.
* What happens if you have both __init__.py and __main__.py in a directory or a
ZIP file ?
* What does "the script name is ad
Marc-Andre Lemburg added the comment:
On 04.04.2013 10:33, STINNER Victor wrote:
>>> I don't understand why the patch makes the comparaison much slower,
>>> since most time is supposed to be spend in memcmp()?
>>
>> Because reading the last character ev
Marc-Andre Lemburg added the comment:
On 04.04.2013 11:21, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
> By the way, my initial concern was to merge unicode_compare_eq() and
> unicode_eq() functions.
>
> unicode_compare_eq() only uses memcmp(), wherea
Marc-Andre Lemburg added the comment:
On 04.04.2013 19:00, Eric Snow wrote:
>
> Eric Snow added the comment:
>
>> Marc-Andre Lemburg added the comment:
>> Same here. The heuristic may work for short strings that easily fit
>> into the CPU cache, but as soon as y
New submission from Marc-Andre Lemburg:
A user reported a segfault when using our mxURL extension with Python 2.7.4.
Previous Python versions do not show this behavior, so it's new in Python 2.7.4.
The extension uses an Py_AtExit() function to clean up among other things a
reference
Marc-Andre Lemburg added the comment:
After a closer look at recent checkins, I found this checking for the trash can
mechanism: 5a2ef447b80d (ticket #13992).
This appears to be the cause:
1.20 #define Py_TRASHCAN_SAFE_BEGIN(op) \
1.21 -if (_PyTrash_delete_nesting
1601 - 1700 of 1946 matches
Mail list logo
