Re: [Python-Dev] In-Python virtualisation and packaging
On 14.06.2011, at 01:46, Carl Meyer wrote: > On 06/13/2011 08:07 AM, Nick Coghlan wrote: >> On Mon, Jun 13, 2011 at 10:50 PM, Vinay Sajip >> wrote: >>> You're right in terms of the current Python ecosystem and 3.x adoption, >>> because >>> of course this approach requires support from Python itself in terms of its >>> site.py code. However, virtual environments have a utility beyond supporting >>> older Pythons on newer OSes, since another common use case is having >>> different >>> library environments sandboxed from each other on different projects, even >>> if >>> all those projects are using Python 3.3+. >> >> Yeah, even if the innate one struggles on later OS releases that >> changed things in a backwards incompatible way, it will still be >> valuable on the OS versions that are around at the time that version >> of Python gets released. > > FWIW, historically pretty much every new Python version has broken > virtualenv, and new OS versions almost never have. Virtualenv isn't > especially OS-dependent (not nearly as much as some other stdlib > modules): the most OS-dependent piece is "shell activation", and that's > a feature I would prefer to entirely leave out of the stdlib virtualenv > (it's a convenience, not a necessity for virtualenv use, and the need to > maintain it for a variety of OS shells is a maintenance burden I don't > think Python should adopt). > > In fact, the only new-OS-version adjustment I can recall virtualenv > needing to make is when Debian introduced dist-packages -- but even that > doesn't really apply, as that was distro-packager change to Python > itself. With a built-in virtualenv it would be the distro packagers > responsibility to make sure their patch to Python doesn't break the > virtualenv module. FTR, there is some special casing for Mac OS framework installs included, too. Not sure if that should be considered a stability threatening issue though since Apple hasn't changed much on that layout, AFAIK. > So I don't think a virtualenv stdlib module would be at all likely to > break on a new OS release, if Python itself is not broken by that OS > release. (It certainly wouldn't be the stdlib module most likely to be > broken by OS changes, in comparison to e.g. shutil, threading...) Jannis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] In-Python virtualisation and packaging
On 14 Jun, 2011, at 11:15, Jannis Leidel wrote: > > On 14.06.2011, at 01:46, Carl Meyer wrote: > >> >> In fact, the only new-OS-version adjustment I can recall virtualenv >> needing to make is when Debian introduced dist-packages -- but even that >> doesn't really apply, as that was distro-packager change to Python >> itself. With a built-in virtualenv it would be the distro packagers >> responsibility to make sure their patch to Python doesn't break the >> virtualenv module. > > FTR, there is some special casing for Mac OS framework installs included, too. > Not sure if that should be considered a stability threatening issue though > since Apple hasn't changed much on that layout, AFAIK. Apple hasn't changed anything w.r.t. the basic layout of frameworks for a long time, but does mess with the structure of site-packages in their releases of Python. That shouldn't affect this feature though. For the most part a Python.framework is just a unix install stuffed inside framework. The special-case code in virtualenv for frameworks is needed because a framework uses another mechanism to look for sys.prefix than a classical unix install: sys.prefix is the directory that contains the python shared library. There is another feature of a framework install that would be nice to have in a virtualenv: the python and pythonw commands for a framework build are small programs that use execv to start the real interpreter that's stored in a Python.app inside the framework. This is needed to be able to access GUI functionality from the command-line as Apple's GUI frameworks assume they are used by code in an application bundle. Ronald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pathscale compilers open source
One of my colleagues with a background in the high performance computing realm sent me this press release: http://www.pathscale.com/ekopath4-open-source-announcement I'm not personally familiar with the Pathscale compilers, but thought some folks here might be and might want to experiment with them. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Lazy unpacking for struct module
> So I really can't see what harm it could do, except for > maybe a tiny performance reduction in the case where you > extract all the fields, or refer to extracted fields > repeatedly. Referring to the view-object multiple times should not be a problem since the object can create and hold references to the unpacked values it created; remember that they are all immutable. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
At 01:56 AM 6/14/2011 +, exar...@twistedmatrix.com wrote: On 12:35 am, ncogh...@gmail.com wrote: On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby wrote: You can still do it one at a time: CHAR, = b'C' INT, = b'I' ... etc. I just tried it with Python 3.1 and it works there. I almost mentioned that, although it does violate one of the "unwritten rules of the Zen" (in this case, "syntax shall not look like grit on Tim's monitor") [CHAR] = b'C' [INT] = b'I' ... Holy carpal tunnel time machine... That works in 2.3. (Without the 'b' of course.) Didn't know you could just use list syntax like that. It's an extra character to type, and two more shift keyings, but brevity isn't always the soul of clarity. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
P.J. Eby wrote: At 01:56 AM 6/14/2011 +, exar...@twistedmatrix.com wrote: On 12:35 am, ncogh...@gmail.com wrote: On Tue, Jun 14, 2011 at 9:40 AM, P.J. Eby wrote: You can still do it one at a time: CHAR, = b'C' INT, = b'I' ... etc. I just tried it with Python 3.1 and it works there. I almost mentioned that, although it does violate one of the "unwritten rules of the Zen" (in this case, "syntax shall not look like grit on Tim's monitor") [CHAR] = b'C' [INT] = b'I' ... Holy carpal tunnel time machine... That works in 2.3. (Without the 'b' of course.) Didn't know you could just use list syntax like that. It's an extra character to type, and two more shift keyings, but brevity isn't always the soul of clarity. I'm thinking I like to the 'new' tuple-assignment character... ,= ! CHAR,= b'C' DATE,= b'D' LOGICAL ,= b'L' ;) ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.x and bytes
Wiadomość napisana przez Ethan Furman w dniu 2011-06-14, o godz. 19:46: >>> [CHAR] = b'C' >>> [INT] = b'I' > CHAR,= b'C' > DATE,= b'D' > LOGICAL ,= b'L' Perl Jam! -- Best regards, Łukasz Langa tel. +48 791 080 144 WWW http://lukasz.langa.pl/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pathscale compilers open source
Skip Montanaro wrote: > One of my colleagues with a background in the high performance computing > realm sent me this press release: > > http://www.pathscale.com/ekopath4-open-source-announcement > > I'm not personally familiar with the Pathscale compilers, but thought some > folks here might be and might want to experiment with them. > > Skip I just rebuilt all my c++ (boost::python) modules using pathscale, and I notice many crash with double-free on exit. According to valgrind, this comes from the pathscale stl: Just a heads-up. ==1927== Invalid free() / delete / delete[] ==1927==at 0x4A0556E: free (vg_replace_malloc.c:366) ==1927==by 0xDA77622: operator delete(void*) (in /home/nbecker/ekopath-4.0.10/lib/4.0.10/x8664/64/libcxxrt.so) ==1927==by 0xD7BB91A: std::allocator::deallocate(char*, unsigned long) (in /home/nbecker/ekopath-4.0.10/lib/4.0.10/x8664/64/libstl.so) ==1927==by 0xD7BB99B: std::string::_C_unlink(char*) (in /home/nbecker/ekopath-4.0.10/lib/4.0.10/x8664/64/libstl.so) ==1927==by 0xD7C4309: std::basic_string, std::allocator >::~basic_string() (in /home/nbecker/ekopath-4.0.10/lib/4.0.10/x8664/64/libstl.so) ==1927==by 0x3D64438940: __run_exit_handlers (in /lib64/libc-2.14.so) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] packaging was not getting installed
I just fixed Makefile.pre.in to install the packaging directory and all its subdirs. Without this `python3.3 -c 'import packaging'` fails from the installation target directory. I'm not sure the Fellowship intends for every subdir to get installed, so please double check. I just added everything that came from `find Lib/packaging -type d`. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] packaging was not getting installed
In article <20110614165414.340f2...@neurotica.wooz.org>, Barry Warsaw wrote: > I just fixed Makefile.pre.in to install the packaging directory and all its > subdirs. Without this `python3.3 -c 'import packaging'` fails from the > installation target directory. I'm not sure the Fellowship intends for every > subdir to get installed, so please double check. I just added everything that > came from `find Lib/packaging -type d`. http://bugs.python.org/issue12313 -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
