Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream
On 3/9/2011 1:27 AM, Mark Hammond wrote: your position but my personal opinion is that simple support for #! is more desirable. I agree. One weird line in a file is enough! -- Terry Jan Reedy ___ 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] hg mq workflow is broken (issue11450)
I wanted to draw attention to issue11450 [1]. In trying to using mq to work on patches for CPython, I found that I could no longer get regrtest to run. This issue comes down to the size of the output of hg id -t . being much longer than expected. $ hg qnew dummy-patch $ echo /* dummy change */ Modules/getbuildinfo.c $ ./python -c 'import sys; print(sys.version)' 3.3a0 (dummy-patch qbase qtip tip:191f047a07b4+, Mar 9 ) [GCC 4.4.5] This is a showstopper for using mq and CPython, since you can no longer run regrtest because the platform module cannot parse that truncated string. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ 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] [PEPs] Support the /usr/bin/python2 symlink upstream
On 9 March 2011 06:27, Mark Hammond mhamm...@skippinet.com.au wrote: I'm glad solving world hunger is out of scope for this :) I understand your position but my personal opinion is that simple support for #! is more desirable. I'd be happy to go with the consensus though... Just in case you need some reassurance about the level of consensus, I agree that simple support for #! is sufficient. Any more is YAGNI. (But if you manage to solve world hunger, do let us know :-)) Paul. ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, Mar 9, 2011 at 1:15 AM, Stefan Behnel stefan...@behnel.de wrote: A publicly visible list of those decisions would a) make it easier for non-core developers to follow important changes on python-dev b) allow potentially impacted people to bring up their POV more quickly, e.g. during the alpha cycle of a deprecation release rather than the following release, as in this case c) document the decision taking process by listing the relevant mailing list threads d) help in writing the what's new documents I've wondered myself if we should simply be more inclined to create PEPs for changes with a wide impact, even if they're technically a CPython-specific implementation decision (cf. zipfile/directory execution, migration from PyCObject to PyCapsule API). Both of those were backed by extensive tracker and mailing list discussions, but there's no easy reference point for anyone coming across them later. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] hg mq workflow is broken (issue11450)
On 3/9/2011 3:15 AM, Scott Dial wrote: I wanted to draw attention to issue11450 [1]. In trying to using mq to work on patches for CPython, I found that I could no longer get regrtest to run. Just to update this thread, thanks to the swift work of Nadeem Vawda and Antoine for pushing it in, it's fixed! -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ 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] Implementation of variable sized objects.
Hi, I hope this is the right place to ask this. Do anyone know why the str (unicode) object is implemented with an external buffer like list, rather than internal one like tuple and bytes? Would anything bad happen if it were changed? I'm not suggesting any changes, just doing some research. Cheers, Mark. ___ 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] Implementation of variable sized objects.
On 3/9/2011 7:55 AM, Mark Shannon wrote: Hi, I hope this is the right place to ask this. Do anyone know why the str (unicode) object is implemented with an external buffer like list, rather than internal one like tuple and bytes? Would anything bad happen if it were changed? I'm not suggesting any changes, just doing some research. See http://bugs.python.org/issue1943 Eric. ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, Mar 9, 2011 at 01:15, Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. We used to do biweekly-ish Python-Dev summaries for this reason. The original links at python.org appear to be down, but I found an example mirrored at ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html Would resuming these and putting them back on python.org address the issue? It's been on my back burner for about two years now, but I want to make sure I can keep up before diving in again. -- Tim Lesher tles...@gmail.com ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, Mar 9, 2011 at 1:15 AM, Stefan Behnel stefan...@behnel.de wrote: Martin v. Löwis, 08.03.2011 23:47: I think everything here is as it should be. People who really cared about forwards compatibility could have known, but factually, most people don't care enough. Those then learn for the first time that some feature was deprecated after it is actually removed. They then ask why it is removed, and somebody will tell them. I was not aware I could turn on deprecation warning for use of the C API. How can I do that? Not sure that you can. When I said could have known, I meant by reading the documentation. I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, and I would claim that we are a project with one of the highest probabilities of being impacted by C-API changes. Maybe the what's new document could at least include a link to the relevant python-dev discussion/decision, so that fewer people have to ask back? Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. A publicly visible list of those decisions would a) make it easier for non-core developers to follow important changes on python-dev b) allow potentially impacted people to bring up their POV more quickly, e.g. during the alpha cycle of a deprecation release rather than the following release, as in this case c) document the decision taking process by listing the relevant mailing list threads d) help in writing the what's new documents Stefan A python dev blog/news site is on the list of topics for the language summit tomorrow at PyCon. Doug hellmann is going to be managing that discussion - but there is a general agreement we have to spread word outside of core and into the general world a little bit more - and this also applies to other python VMs as well. jesse ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? I think what's new serves this purpose properly. Usually, every time I commit a new feature, I update the what's new file as well. In fact we already have a partial roadmap for Python 3.3: http://docs.python.org/dev/whatsnew/3.3.html I'm not sure who else is doing the same though. If we agree that every time a new feature is added we also update the what's new file we can have such a roadmap with relatively no effort. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/3/9 Stefan Behnel stefan...@behnel.de: Martin v. Löwis, 08.03.2011 23:47: I think everything here is as it should be. People who really cared about forwards compatibility could have known, but factually, most people don't care enough. Those then learn for the first time that some feature was deprecated after it is actually removed. They then ask why it is removed, and somebody will tell them. I was not aware I could turn on deprecation warning for use of the C API. How can I do that? Not sure that you can. When I said could have known, I meant by reading the documentation. I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, and I would claim that we are a project with one of the highest probabilities of being impacted by C-API changes. Maybe the what's new document could at least include a link to the relevant python-dev discussion/decision, so that fewer people have to ask back? Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. A publicly visible list of those decisions would a) make it easier for non-core developers to follow important changes on python-dev b) allow potentially impacted people to bring up their POV more quickly, e.g. during the alpha cycle of a deprecation release rather than the following release, as in this case c) document the decision taking process by listing the relevant mailing list threads d) help in writing the what's new documents Stefan ___ 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/g.rodola%40gmail.com ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote: On Wed, Mar 9, 2011 at 01:15, Stefan Behnel stefan...@behnel.de wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? Including a link to the relevant discussion and decision. Often enough, decisions are taken inside of huge mailing list threads that get off-topic before someone has the right idea and everyone who's still there to listen agrees. Even for people lurking around on python-dev, it's easy enough to miss these moments. We used to do biweekly-ish Python-Dev summaries for this reason. The original links at python.org appear to be down, but I found an example mirrored at ftp://ftp.ntua.gr/mirror/python/dev/summary/2005-02-01_2005-02-14.html Would resuming these and putting them back on python.org address the issue? It's been on my back burner for about two years now, but I want to make sure I can keep up before diving in again. As Jesse mentioned, this topic came up on the board mailing list recently for a reason completely unrelated to this thread. As a result of that discussion, the board has asked me in my capacity as PSF Communications Director to help the python-dev crew set up a blog (or other forum) through which you can communicate news about major projects undertaken during development. This would be in addition to, rather than a replacement for, individual developer blogs, and would provide an official channel for the team to talk about projects publicly after they are complete. Topics proposed as part of the discussion on the board list included the hg migration, the new developer's guide, changes to the Mac installer, and the updated release process for 3.2. Those are just examples, though. This deprecation would make another good topic, and I'm sure everyone can think of others. Consider the blog as an analog to the PEP process. Where PEPs come at the beginning of a project, a blog post would come at a major milestones or the completion of a project. The original request from the board was for the communications team to write the messages, but I think it is more appropriate for the people doing the work to talk about it. I will provide editorial guidance to anyone that wants me to read their posts before they are published, and I will administer the tool if needed (granting access and moderating comments that look like spam). I asked Michael to add this topic to the agenda for the language summit tomorrow to get early feedback about whether this group thinks it is a good idea. I was going to hold discussion for the mailing list until after that meeting, but since the topic came up on its own please go ahead and respond here with questions or comments, especially if you won't be in Atlanta tomorrow. Let's table discussion of tools for now, though, because I want to make sure there is enough support for the project before we spend too much energy on implementation details. Doug ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On Wed, 9 Mar 2011 19:42:36 +0100 Giampaolo Rodolà g.rod...@gmail.com wrote: Actually, why not put up a web page of upcoming changes somewhere, that lists major decisions with user impact that were taken on python-dev? I think what's new serves this purpose properly. Usually, every time I commit a new feature, I update the what's new file as well. In fact we already have a partial roadmap for Python 3.3: http://docs.python.org/dev/whatsnew/3.3.html Perhaps the part of the what's new document which deals with porting issues and compatibility breakage would need more highlighting? Regards Antoine. ___ 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] PEP 395: Module Aliasing
At 05:35 PM 3/4/2011 +, Michael Foord wrote: That (below) is not distutils it is setuptools. distutils just uses `scripts=[...]`, which annoyingly *doesn't* work with setuptools. Er, what? That's news to me. Could you file a bug report about what doesn't work, specifically? ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On 3/9/2011 4:14 PM, Antoine Pitrou wrote: On Wed, 9 Mar 2011 19:42:36 +0100 Perhaps the part of the what's new document which deals with porting issues and compatibility breakage would need more highlighting? That could go at the tops. Deletions in 3.3 ... Planned deletions in future versions ... Porting issues ... then the usual ... -- Terry Jan Reedy ___ 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] public visibility of python-dev decisions before it's too late (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)
On 3/9/2011 9:50 AM, Tim Lesher wrote: We used to do biweekly-ish Python-Dev summaries for this reason. They were, is a sense, too detailed, complete, and voluminous. In whatever format, terser announcement of just things others really need to know - like decisions that affect them, would probably be more useful. There is also python-announce, but I do not follow it. -- Terry Jan Reedy ___ 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] GPL'd python code vs Python2.6 linked against OpenSSL
It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to import ssl. Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem... Thanks to Ulrik Sverdrup (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing this out... James [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html ___ 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] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?
On 9 Mar 2011, at 06:50, Georg Brandl wrote: On 08.03.2011 23:47, Martin v. Löwis wrote: I think everything here is as it should be. People who really cared about forwards compatibility could have known, but factually, most people don't care enough. Those then learn for the first time that some feature was deprecated after it is actually removed. They then ask why it is removed, and somebody will tell them. I was not aware I could turn on deprecation warning for use of the C API. How can I do that? Not sure that you can. When I said could have known, I meant by reading the documentation. Well, it looks like the CObject functions actually emitted PendingDeprecationWarnings when used: http://hg.python.org/cpython/file/16f8f359db9c/Objects/cobject.c#l12 I changed my testing code for PyCXX to run python -W default and did indeed get a nice message: Demo/Python3/test_simple.py:1: PendingDeprecationWarning: The CObject API is deprecated as of Python 3.1. Please convert to using the Capsule API. Thanks for the info. I'm going to run PyCXX like this for all future release testing. Barry ___ 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] GPL'd python code vs Python2.6 linked against OpenSSL
On Wed, 9 Mar 2011 18:20:01 -0500 James Y Knight f...@fuhm.net wrote: It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to import ssl. Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem... A Python program is not a derivative of the Python interpreter any more than a C program is a derivative of gcc (or any other compiler). That said, with a non-shared build of Python 3.x: $ ldd ./python linux-vdso.so.1 = (0x7fffa574d000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7fd9a56d2000) libdl.so.2 = /lib64/libdl.so.2 (0x7fd9a54ce000) libutil.so.1 = /lib64/libutil.so.1 (0x7fd9a52cb000) libm.so.6 = /lib64/libm.so.6 (0x7fd9a5049000) libc.so.6 = /lib64/libc.so.6 (0x7fd9a4cdd000) /lib64/ld-linux-x86-64.so.2 (0x7fd9a58ee000) $ objdump -p ./python | grep NEEDED NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libm.so.6 NEEDED libc.so.6 Also, with the system Python 2.6 shipped on a Mandriva distribution: $ ldd /usr/bin/python linux-vdso.so.1 = (0x7fff8456d000) libpython2.6.so.1.0 = /usr/lib64/libpython2.6.so.1.0 (0x7f1a0b1e2000) libc.so.6 = /lib64/libc.so.6 (0x7f1a0ae76000) libdl.so.2 = /lib64/libdl.so.2 (0x7f1a0ac72000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f1a0aa56000) libutil.so.1 = /lib64/libutil.so.1 (0x7f1a0a853000) libm.so.6 = /lib64/libm.so.6 (0x7f1a0a5d1000) /lib64/ld-linux-x86-64.so.2 (0x7f1a0b583000) $ objdump -p /usr/bin/python | grep NEEDED NEEDED libpython2.6.so.1.0 NEEDED libc.so.6 So I'm not sure which build options led to that result. Regards Antoine. ___ 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] GPL'd python code vs Python2.6 linked against OpenSSL
On Thu, Mar 10, 2011 at 00:32, Antoine Pitrou solip...@pitrou.net wrote: Also, with the system Python 2.6 shipped on a Mandriva distribution: $ ldd /usr/bin/python linux-vdso.so.1 = (0x7fff8456d000) libpython2.6.so.1.0 = /usr/lib64/libpython2.6.so.1.0 (0x7f1a0b1e2000) libc.so.6 = /lib64/libc.so.6 (0x7f1a0ae76000) libdl.so.2 = /lib64/libdl.so.2 (0x7f1a0ac72000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f1a0aa56000) libutil.so.1 = /lib64/libutil.so.1 (0x7f1a0a853000) libm.so.6 = /lib64/libm.so.6 (0x7f1a0a5d1000) /lib64/ld-linux-x86-64.so.2 (0x7f1a0b583000) $ objdump -p /usr/bin/python | grep NEEDED NEEDED libpython2.6.so.1.0 NEEDED libc.so.6 (just nitpicking) but it's there on a debian system: $ ldd /usr/bin/python linux-vdso.so.1 = (0x77bff000) libpthread.so.0 = /lib/libpthread.so.0 (0x7f9abcb82000) libdl.so.2 = /lib/libdl.so.2 (0x7f9abc97e000) libutil.so.1 = /lib/libutil.so.1 (0x7f9abc77a000) libssl.so.0.9.8 = /usr/lib/libssl.so.0.9.8 (0x7f9abc525000) libcrypto.so.0.9.8 = /usr/lib/libcrypto.so.0.9.8 (0x7f9abc184000) libz.so.1 = /usr/lib/libz.so.1 (0x7f9abbf6c000) libm.so.6 = /lib/libm.so.6 (0x7f9abbcea000) libc.so.6 = /lib/libc.so.6 (0x7f9abb989000) /lib64/ld-linux-x86-64.so.2 (0x7f9abcdc4000) $ objdump -p /usr/bin/python | grep NEEDED NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libssl.so.0.9.8 NEEDED libcrypto.so.0.9.8 NEEDED libz.so.1 NEEDED libm.so.6 NEEDED libc.so.6 It seems introduced by the patch debian/patches/setup-modules-ssl.diff with description # DP: Modules/Setup.dist: patch to build _hashlib and _ssl extensions statically Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] constant folding of -0
Hello, I've noticed since version 3.2 python doesn't fold -0: Python 3.1.3 (r313:86834, Nov 28 2010, 10:01:07) def foo(): return -0 dis(foo) 1 0 LOAD_CONST 1 (0) 3 RETURN_VALUE Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) def foo(): return -0 dis(foo) 1 0 LOAD_CONST 1 (0) 3 UNARY_NEGATIVE 4 RETURN_VALUE (version built from head behaves the same way). It looks like folding -0 is disabled in peephole since this commit http://hg.python.org/cpython/diff/660419bdb4ae/Python/compile.c which was a long time ago. Before 3.2 -0 was likely folded in the parser -- in a more complex case no folding happens in either version: def foo(): return -(1-1) dis(foo) 1 0 LOAD_CONST 2 (0) 3 UNARY_NEGATIVE 4 RETURN_VALUE In 3.2 parser no longer folds -0. So I wanted to ask why folding of -0 was disabled in peephole? Commit message makes me think this was a work-around for a problem in marshal -- perhaps it couldn't save -0.0 properly and so not creating -0.0 in the code objects was a simple fix. (This would mean the change predates folding in the parser.) Was marshal fixed? If I revert the change everything seems to work and all tests pass. Since tests are run with .pyc-s I assume they test marshal? Maybe this check is no longer needed and can be reverted? Or is it there for some different reason which still holds? Regards, Eugene ___ 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] constant folding of -0
Hello, I've noticed since version 3.2 python doesn't fold -0: Indeed, see http://bugs.python.org/issue11244 Regards Antoine. ___ 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] Bugs in thread_nt.h
Atomic operations (InterlockedCompareExchange, et al.) are used on the
field 'owned' in NRMUTEX. These methods require the memory to be aligned
on 32-byte boundaries. They also require the volatile qualifer. Three
small changes are therefore needed (see below).
Regards,
Sturla Molden
typedef struct NRMUTEX {
volatile LONG owned ; /* Bugfix: remember volatile */
DWORD thread_id ;
HANDLE hevent ;
} NRMUTEX, *PNRMUTEX;
NRMUTEX
AllocNonRecursiveMutex(void)
{
PNRMUTEX mutex = (PNRMUTEX)_aligned_malloc(sizeof(NRMUTEX),32) ; /*
Bugfix: align to 32-bytes */
if (mutex !InitializeNonRecursiveMutex(mutex))
{
free(mutex) ;
mutex = NULL ;
}
return mutex ;
}
void
FreeNonRecursiveMutex(PNRMUTEX mutex)
{
if (mutex)
{
DeleteNonRecursiveMutex(mutex) ;
_aligned_free(mutex) ; /* Bugfix: align to 32-bytes */
}
}
___
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] GPL'd python code vs Python2.6 linked against OpenSSL
On Wed, Mar 9, 2011 at 8:20 PM, James Y Knight f...@fuhm.net wrote: It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to import ssl. Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem... Hi - Any libraries commonly avaliable with a CPython instalation can be considered as system libraries for GPL purposes - and so this would fall in the system library exception as described by the FAQ: http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs In GPLv2 we have However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. And in v3: The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. regards, js -- Thanks to Ulrik Sverdrup (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing this out... James [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html ___ 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/jsbueno%40python.org.br ___ 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] Bugs in thread_nt.h
These issues are best put in the tracker so they don't get lost -
especially at the moment with lots of regulars at pycon.
It would also be good to know if there is an actual behaviour bug caused
by this (ie, what problems can be observed which are caused by the
current code?)
Cheers,
Mark
On 10/03/2011 12:25 PM, Sturla Molden wrote:
Atomic operations (InterlockedCompareExchange, et al.) are used on the
field 'owned' in NRMUTEX. These methods require the memory to be aligned
on 32-byte boundaries. They also require the volatile qualifer. Three
small changes are therefore needed (see below).
Regards,
Sturla Molden
typedef struct NRMUTEX {
volatile LONG owned ; /* Bugfix: remember volatile */
DWORD thread_id ;
HANDLE hevent ;
} NRMUTEX, *PNRMUTEX;
NRMUTEX
AllocNonRecursiveMutex(void)
{
PNRMUTEX mutex = (PNRMUTEX)_aligned_malloc(sizeof(NRMUTEX),32) ; /*
Bugfix: align to 32-bytes */
if (mutex !InitializeNonRecursiveMutex(mutex))
{
free(mutex) ;
mutex = NULL ;
}
return mutex ;
}
void
FreeNonRecursiveMutex(PNRMUTEX mutex)
{
if (mutex)
{
DeleteNonRecursiveMutex(mutex) ;
_aligned_free(mutex) ; /* Bugfix: align to 32-bytes */
}
}
___
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/skippy.hammond%40gmail.com
___
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] constant folding of -0
Indeed, see http://bugs.python.org/issue11244 Yes, I've noticed that too. However, if I'm not missing something, your patches do not address folding of -0. Btw, there's an alternative approach to allow recursive constant folding. Instead of keeping a stack of last constants, you can keep a pointer to the start of the last (LOAD_CONSTs + NOPs) run and the number of LOAD_CONSTs in that run (called lastlc in the current version). When you want Nth constant from the end, you start from that pointer and skip lastlc-N constants. You also make a function to get next constant from that point. This approach has worse time complexity for searching in a long run of LOAD_CONSTs, however, there are upsides: - very long runs of constants are rare in real code - it uses less memory and doesn't have arbitrary limits on the size of the run - it's book-keeping overhead is smaller, so when you don't have long runs of constants (common case, I believe), it should be faster - I think it's simpler to implement (There's also an optimization -- if (current_position - start_of_run) / 3 == lastlc there are no NOPs in the run and you can get constants by simple indexing). Eugene ___ 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] Support the /usr/bin/python2 symlink upstream
On 4 Mar, 2011, at 16:35, Martin v. Löwis wrote: I'd still like the PEP to tell me whether it's python3w.exe or pythonw3.exe (and yes, that's bikeshedding - so somebody just tell me). It would also be good if the PEP took a position on providing pythonXY.exe binaries on Windows (with the related question of whether it's python32w.exe, python3.2w.exe, pythonw32.exe or pythonw3.2.exe) It is pythonw3 and pythonw3.2 on OSX. 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
Re: [Python-Dev] Bugs in thread_nt.h
Den 10.03.2011 03:02, skrev Mark Hammond: These issues are best put in the tracker so they don't get lost - especially at the moment with lots of regulars at pycon. Ok, sorry :-) It would also be good to know if there is an actual behaviour bug caused by this (ie, what problems can be observed which are caused by the current code?) None that I have observed, but this is required according to MSDN. Theoretically, an optimizing compiler could cache the 'owned' field if it's not declared volatile. It currently works because a wait on the lock is implemented with a WaitForSingleObject on a kernel event object when the waitfalg is set. If the wait mechanism is changed to a much less expensive user-space spinlock, just releasing the time-slice by Sleep(0) for each iteration, it will certainly fail without a volatile qualifier. As for InterlockedCompareExchange et al., MSDN says this: The parameters for this function must be aligned on a 32-bit boundary; otherwise, the function will behave unpredictably on multiprocessor x86 systems and any non-x86 systems. See _aligned_malloc. Well, it does not hurt to obey :-) Regards, Sturla ___ 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] GPL'd python code vs Python2.6 linked against OpenSSL
On Wed, 2011-03-09 at 18:20 -0500, James Y Knight wrote: It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to import ssl. Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem... Thanks to Ulrik Sverdrup (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing this out... James [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html Is it legal to distribute GPL programs that use the Win32 API? ___ 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] hg diff
IMO, it's hg diff --git that's broken, as it doesn't include the base
revision (other formats, such as hg export, do).
I agree that it's poor form to omit the revisions, and we should
supplicate Mercury at his temple. But I don't see the problem for
Reitveld integration; they're easily available, no? At least, so far
in the discussion the two -r form has been used, so this should do
the trick:
improved-hg-diff--git () {
# usage: improved-hg-diff--git BASE TIP
hg identify -i -r $1
hg identify -i -r $2
hg diff --git -r $1 -r $2
}
What am I missing?
Not sure what problem you are trying to solve. To make such a script
useful, users would actually have to use it, instead of using what they
use now, right? If so, how does that help me with patches that don't
have this form?
If I can get users to use something different, any of diff without
--git, export with or without --git, outgoing with or without --git
would do (although outgoing uses a localized header, which would make
it more difficult to parse).
Regards,
Martin
___
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] GPL'd python code vs Python2.6 linked against OpenSSL
Am 09.03.11 18:20, schrieb James Y Knight: [1] Python (from 2.6) is *always* linked against openssl Others have already pointed that out, but let me stress it again: this statement is false. It is as possible and easy to build Python without OpenSSL as it always was. instead of waiting for you to import ssl. In addition, that is also false. Even if OpenSSL is used, it is easy to build Python so that OpenSSL is only loaded when needed. Regards, Martin ___ 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] GPL'd python code vs Python2.6 linked against OpenSSL
On Thu, Mar 10, 2011 at 12:49 AM, Westley Martínez aniko...@gmail.com wrote: On Wed, 2011-03-09 at 18:20 -0500, James Y Knight wrote: It's well known that OpenSSL is incompatible with the GPL. [1] Python (from 2.6) is *always* linked against openssl, instead of waiting for you to import ssl. Doesn't this mean it's now impossible (rather, a license violation) to distribute a GPL'd python program (or to use a GPL'd library in your python program)? This seems like a problem... Thanks to Ulrik Sverdrup (http://lists.debian.org/debian-python/2011/03/msg00082.html) for pointing this out... James [1] http://people.gnome.org/~markmc/openssl-and-the-gpl.html Is it legal to distribute GPL programs that use the Win32 API? Of course it is -- otherwise no program running on windows could ever be under the GPL. You probably are thinking of Python programs that would specifically use the win32 extensions -- but implicitly any program, including binary programs, using Windows will have to use some API from the OS in order to communicate with the rest of the system and the world. This system library exception could not apply automatically to Python win32 if its terms where too restrictive or if it was a component hard to set up, or with a high commercial cost (neither is the case). But even then, since the licensing of a Software is ultimately upon its authors, they are always OK to add special exceptions to the License file distributed with the program, stating that this or that library is exempted from the GPL terms. What one can't do is to take a work under the GPL, build upon it, and in this process make use of a library or module with a license incompatible with the GPL, and redistribute that work (though, note that even then one is free to use such a work on his own systems). Because then he'd have to add that exception to the original license. js -- That is clear from the examples on the FAQ. ___ 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/jsbueno%40python.org.br ___ 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] hg diff
On Tue, Mar 8, 2011 at 6:30 PM, Éric Araujo mer...@netwok.org wrote: What’s the command you use with git? Maybe someone will find the Mercurial one. Something like the following, assuming we're both working on branch master to begin with. git fetch their-repository master:experimental-branch git diff master...experimental-branch The idea is to pull their remote branch but not merge it, which will create multiple heads locally. Then find the common ancestor of my regular local head and the new head, and diff the ancestor with the new head. -- Daniel Stutzbach ___ 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] Bugs in thread_nt.h
Am 09.03.11 20:25, schrieb Sturla Molden: These methods require the memory to be aligned on 32-byte boundaries. You misread the documentation - it's a 32-*bit* boundary that the LONG variable must be on. The malloc() call that is currently used trivially meets this requirement. As for the volatile marker - I believe the code is also correct without it, since the owned field is only accessed through initialization and Interlocked operations. Regards, Martin ___ 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] GPL'd python code vs Python2.6 linked against OpenSSL
Joao S. O. Bueno writes: Any libraries commonly avaliable with a CPython instalation can be considered as system libraries for GPL purposes - and so this would fall in the system library exception as described by the FAQ: Note that your interpretation would allow Python to distribute arbitrarily licensed libraries and GPL programs to link with them. That is surely not the intent of the authors of the GPL, and in the past, the FSF has explicitly restricted the interpretation of system library. Specifically, in Major Component, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. the word essential would refer to running the compiler or the operating system or interpreter, not to a component essential to running the program but in general optional for using the system. Perhaps this has changed with the advent of GPL v3, but the FSF used this interpretation to block the consideration of (old-Qt-licensed) Qt as a system library on GNU/Linux systems, even where distributed by vendors such as Red Hat. OTOH, for some reason Motif on Sun and HP systems, and Windows and Mac GUIs were considered essential. ___ 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] GPL'd python code vs Python2.6 linked against OpenSSL
On Mar 9, 2011, at 6:45 PM, Sandro Tosi wrote:
It seems introduced by the patch debian/patches/setup-modules-ssl.diff
with description # DP: Modules/Setup.dist: patch to build _hashlib
and _ssl extensions statically
Indeed you're right -- out of the box, python still builds _ssl.so as a
separate module. Sorry for the misinformation -- indeed *nothing* has changed
here upstream, it was just a build patch added to debian's python packaging.
[[
BTW, the actual thing causing that special behavior is not that diff, but
rather is in debian/rules:
egrep \
^#($$(awk '$$2 ~ /^extension$$/ {print $$1}'
debian/PVER-minimal.README.Debian.in | tr '\012' '|')XX) \
Modules/Setup.dist \
| sed -e 's/^#//' -e 's/-Wl,-Bdynamic//;s/-Wl,-Bstatic//' \
$(buildd_shared)/Modules/Setup.local
which causes all the modules listed as extension in
PVER-minimal.README.Debian.in to be compiled in to the python interpreter
instead of built as separate .so files.
]]
Despite that not having changed recently, it still seems like there's a problem
in upstream python, which perhaps nobody has thought much about: even if you
don't use SSL, many modules indirectly import either _hashlib or _ssl, and thus
your program is linked against openssl.
You can of course prevent that from happening:
sys.modules['_ssl'] = None; sys.modules['_hashlib'] = None
Luckily, basically everything is already written to keep working if 'import
ssl' fails, so that's fine. (assuming you don't want SSL support, of course).
But you're also left with not being able to 'import hashlib'. While python has
fallback code, those modules (_md5, _sha, _sha256, _sha512) aren't built if
openssl was found at build time. So you can't just select at runtime that you
didn't want to use openssl.
Not being able to import hashlib unfortunately makes urllib2 (and a lot of 3rd
party packages) fail to import.
Possibly distributors like Debian should just cause _hashopenssl to never be
used, and always use the fallback code, for maximal license compatibility?
On Mar 9, 2011, at 8:27 PM, Joao S. O. Bueno wrote:
Any libraries commonly avaliable with a CPython instalation can be
considered as system libraries for GPL purposes - and so
this would fall in the system library exception as described by the FAQ:
The system library exception is often held not to apply when you are
distributing your program as part of the same system as said system library.
The system library exception would also not be applicable if it is the
license of a system library itself that you're violating, e.g. if I have a
BSD-licensed program which starts with import hashlib, readline.
See also:
http://curl.haxx.se/legal/distro-dilemma.html
James
___
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] GPL'd python code vs Python2.6 linked against OpenSSL
Westley Martínez writes: Is it legal to distribute GPL programs that use the Win32 API? Yes. Their use of the Win32 API falls under the essential system library clause. The criterion for essential is that normal, basic use of the system would fail without the library. Windows won't boot without Win32 API support, so it satisfies that clause. OpenSSL is needed only by a minority of programs, and Python itself will run without it, so OpenSSL will not qualify for that exception. As Martin points out, that's not relevant to Python, since it can be built without and Python is not a GPL program. And as Antoine points out, it's not relevant to Python programs unless they actually call OpenSSL functions. In that case only, the program becomes a derivative of OpenSSL, and only with agreement of all owners of GPLed code in the program may the program be distributed. (Ie, if they all agree to the special exception for specific non-GPL libraries that Joao Bueno describes.) ___ 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] GPL'd python code vs Python2.6 linked against OpenSSL
James Y Knight, 10.03.2011 06:52: But you're also left with not being able to 'import hashlib'. While python has fallback code, those modules (_md5, _sha, _sha256, _sha512) aren't built if openssl was found at build time. So you can't just select at runtime that you didn't want to use openssl. Not being able to import hashlib unfortunately makes urllib2 (and a lot of 3rd party packages) fail to import. Agreed. Could you file a bug report, in case there isn't one yet? Stefan ___ 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
