Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

* Gregory P. Smith: > The proper fix for this in the code would likely break ABI compatibility > (ie: not possible in python 2.7 or any other stable release). > > Clang's UBSAN (undefined behavior sanitizer) has been flagging this one for > a long time. > > In Python 3 a double is used instead of

[Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

I hope this is the right list for this kind of question. We recently tried to build Python 2.6 with GCC 8, and ran into this issue: Also quoting for context: | PyInstance_NewRaw contains this code: | | inst = PyObject_GC_New(PyInstanc

Re: [Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

* Victor Stinner: > CPython still has compatibility code for Linux 2.6, whereas the > support of Linux 2.6.x ended in August 2011, longer than 6 years ago. There are still reasonably widely used 2.6 kernels under support, but they have lots of (feature) backports, so maybe they do not need the 2.

Re: [Python-Dev] PEP 393: Flexible String Representation

ips are problematic. However, why would one want to write loops like the above? Don't you have to take combining characters (comprising multiple codepoints) into account most of the time when you look at individual characters? Then UTF-32 does not offer much of a simplification. -- Fl

Re: [Python-Dev] PEP 393: Flexible String Representation

this isn't initialised by default, though. Py_UNICODE is > the only representation that can be used efficiently from C code Is this really true? I don't think I've seen any C API which actually uses wchar_t, beyond that what is provided by libc. UTF-8 and even UTF-16 are much, m

Re: [Python-Dev] [RELEASED] Python 2.7 beta 2

* Benjamin Peterson: > http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python > distribution. Something is missing here: "* Multiple context managers in" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/li

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

* James Y. Knight: > On Oct 25, 2009, at 2:50 AM, Terry Reedy wrote: > >> Alex Martelli wrote: >>> Next(s) would seem good... >> >> That does not work. It has to be next(iter(s)), and that has been >> tried and eliminated because it is significantly slower. > > But who cares about the speed of get

Re: [Python-Dev] GIL, Python 3, and MP vs. UP

* Michael Hudson: > Not to my knowledge. I've always thought that it would be pretty > hard. I'd be interested in being proved wrong. The real problem is that you can ditch most extension modules. 8-( It sounds more like a fun project for the Python core, though. >> Copying GC might help to g

Re: [Python-Dev] GIL, Python 3, and MP vs. UP

* Guido van Rossum: > That assumes a very specific model for how all that MP power is going > to be used. Indeed. > I personally don't think the threaded programming model as found in > Java works all that well; without locks you end up with concurrent > modification errors, with locks you get d

Re: [Python-Dev] GIL, Python 3, and MP vs. UP

* Martin Blais: > http://www.gotw.ca/publications/concurrency-ddj.htm > The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software > Herb Sutter > March 2005 This piece is fundamentally wrong. We all have been writing concurrent server-side software for eons. I don't know what He

Re: [Python-Dev] removing nested tuple function parameters

* Brett Cannon: > Is anyone truly attached to nested tuple function parameters; ``def > fxn((a,b)): print a,b``? At one of the PyCon sprints Guido seemed > okay with just having them removed when Jeremy asked about ditching > them thanks to the pain they caused in the AST branch. Will def fxn