Re: [Python-Dev] Thank yous
On Sun, Jul 4, 2010 at 9:45 PM, Jesse Noller wrote: > On Sun, Jul 4, 2010 at 1:26 PM, Tarek Ziadé wrote: >> On Sun, Jul 4, 2010 at 7:16 PM, Paul Moore wrote: >>> On 4 July 2010 17:02, Benjamin Peterson wrote: Now that Python 2.7 is out, I'd like to thank a few of the people who made it possible: >>> >>> And not forgetting Benjamin himself for managing the whole thing! >> >> +1. Thanks a lot for your hard work > > Seriously Benjamin, you've done a great job. +1. A fantastic job. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thank yous
On Mon, Jul 05, 2010 at 08:46:57AM +0100, Mark Dickinson wrote: > >>> On 4 July 2010 17:02, Benjamin Peterson wrote: > Now that Python 2.7 is out, I'd like to thank a few of the people who > made it possible: > >>> > >>> And not forgetting Benjamin himself for managing the whole thing! > >> > >> +1. Thanks a lot for your hard work > > > > Seriously Benjamin, you've done a great job. > > +1. A fantastic job. > Yeah, there is lot to learn from you in the way you lead the release. Thank you! Senthil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?
On Fri, Jul 2, 2010 at 10:35 PM, Steven D'Aprano wrote:
> On Sat, 3 Jul 2010 11:39:07 am Greg Ewing wrote:
>> Stefan Behnel wrote:
>> > So, would it still be Python if it folded
>> >
>> > 1 + "1"
>> >
>> > into
>> >
>> > raise TypeError()
>> >
>> > at compile time?
>>
>> It would have to be
>>
>> raise TypeError("Exactly the message that would have been
>> produced at run time")
>
>
> Python doesn't make any guarantees about the message that exceptions
> display, so I don't think you need to match the message, just the
> exception. Anyone testing for specific exception messages is living in
> a state of sin and shouldn't complain when their code stops working. An
> implementation might choose to raise TypeError('is this the right place
> for an argument?') on alternate Tuesdays, and it would still meet the
> promises made by the language.
>
In theory it does not, in practice people rely on it. Besides, I would
not be overly happy if:
def f():
return 1 + "1"
and
def g():
a = 1
return a + "1"
raise different messages
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] logging package vs unicode
Hi All, The documentation for the logging package doesn't include any mention of unicode. What's the recommended usage in terms of passing unicode vs encoded strings? How does this differ from Python 2 to Python 3? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] set/dict comprehensions don't leak in Py2.7 - intentional?
Hi, I only noticed now that set/dict comprehensions were backported to 2.7 without letting the loop Variables leak into the surrounding scope. So they now behave different from list comprehensions. Is this intentional or just a backporting oversight? I'm asking because we had a discussion about the 'right' semantics several times on the Cython list, and the current behaviour is that all comprehensions leak when compiling Py2 code and the do not leak when compiling Py3 code. I would hate to fix that up to match 2.7 and then see that the behaviour in Py2.7 is to be considered an accident. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] set/dict comprehensions don't leak in Py2.7 - intentional?
On 05/07/2010 14:06, Stefan Behnel wrote: Hi, I only noticed now that set/dict comprehensions were backported to 2.7 without letting the loop Variables leak into the surrounding scope. So they now behave different from list comprehensions. Is this intentional or just a backporting oversight? I'm asking because we had a discussion about the 'right' semantics several times on the Cython list, and the current behaviour is that all comprehensions leak when compiling Py2 code and the do not leak when compiling Py3 code. I would hate to fix that up to match 2.7 and then see that the behaviour in Py2.7 is to be considered an accident. Depends on your definition of "comprehension", but generator expressions have always not leaked, so these are already different in Py2.x: [i for i in range (10)] list (i for i in range (10)) I had understood (without being able to put my finger on a relevant thread) that all comprehensions were going not leak their loop variables in the future. TJG ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] set/dict comprehensions don't leak in Py2.7 - intentional?
On 05/07/2010 14:12, Tim Golden wrote: On 05/07/2010 14:06, Stefan Behnel wrote: Hi, I only noticed now that set/dict comprehensions were backported to 2.7 without letting the loop Variables leak into the surrounding scope. So they now behave different from list comprehensions. Is this intentional or just a backporting oversight? I'm asking because we had a discussion about the 'right' semantics several times on the Cython list, and the current behaviour is that all comprehensions leak when compiling Py2 code and the do not leak when compiling Py3 code. I would hate to fix that up to match 2.7 and then see that the behaviour in Py2.7 is to be considered an accident. Depends on your definition of "comprehension", but generator expressions have always not leaked, so these are already different in Py2.x: [i for i in range (10)] list (i for i in range (10)) I had understood (without being able to put my finger on a relevant thread) that all comprehensions were going not leak their loop variables in the future. Similarly my understanding was that list comprehensions leaking was an unfortunate implementation detail and that to depend on it was therefore "a bug". I don't see it as an issue that set and dict comprehensions don't leak in 2.7 (and in fact it is a good thing as it makes it harder to write code that works in 2.7 but fails in 3.x). Michael TJG ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASE] Python 2.7 released
On Mon, Jul 5, 2010 at 2:03 AM, Benjamin Peterson wrote: > 2010/7/4 Benjamin Peterson : >> On behalf of the Python development team, I'm jocund to announce the second >> release candidate of Python 2.7. > > Arg!!! This should, of course, be "final release". It wouldn't be a proper Python release without a typo *somewhere* in the release announcement :) Well shepherded! Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] blocking 2.7
On Mon, Jul 5, 2010 at 5:20 AM, Terry Reedy wrote: > On 7/4/2010 2:31 AM, Éric Araujo wrote: >>> >>> But Python tests lack coverage stats, so it is hard to say anything. >> >> FYI: http://coverage.livinglogic.de/ > > Turns out the audioop is one of the best covered modules, at 98% Alas, those are only the stats for the audioop test suite. audioop itself is written in C, so the automatic coverage stats generated by livinglogic don't provide any details. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] set/dict comprehensions don't leak in Py2.7 - intentional?
On Mon, Jul 5, 2010 at 11:12 PM, Tim Golden wrote: > I had understood (without being able to put my finger on a relevant thread) > that all comprehensions were going not leak their loop variables in the > future. This understanding is correct (with that future being Python 3.x where all comprehensions have their own private scope). As others have noted, generator expressions in 2.x already didn't leak the iteration variable into the surrounding scope. The only reason list comprehensions continue to leak the iteration variable in 2.6 and 2.7 is that there *is* code out there that relies on that behaviour. However, since legacy code can't include set or dict comprehensions, there was no need for the backported versions to replicate this misfeature of 2.x list comprehensions. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] FWD: error: 3.2 release schedule has release in Jan 2010.
- Forwarded message from Ric Johnson - > Date: Mon, 5 Jul 2010 08:49:29 -0700 (PDT) > From: Ric Johnson > Subject: error: 3.2 release schedule has release in Jan 2010. > To: [email protected] > > Hey! > There's a typo on http://www.python.org/dev/peps/pep-0392/: > > Release Schedule > > The current schedule is: > > ... > > # 3.2 candidate 2: January 1, 2010 ==> should be 2011 > # 3.2 final: January 15, 2010 ==> should be 2011 > > > I know it is rough schedule but it looks bad ... > > Ric > > -Verba nihil operandi melius est quam absurde. > > > - End forwarded message - -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Licensing // PSF // Motion of non-confidence
Sorry for touching a sore point of if I sound like a boss to someone. I tried to be as constructive as possible, but politeness was not the point, so I can only hope you understand. I do not think PSF does its job well and here is why. 1. Python licensing terms are explained poorly In order to "advance the Python programming language", and "to support and facilitate the growth of international community" PSF should be clear about the legal stuff with no complications. So that even people without English background can understand the terms. 1.1 Let's start with http://www.python.org/psf/license/ ... Full text of the Python 2.6.2 license ... Q: Why 2.6.2? A: Nobody cares. Inside referenced doc there are several licenses for Python + historical note. I remember I've tried to read this file several times, but only after comparing freeness and beerness of PSF license to GPL in private talk with Eric I was able to go through this seriously. Moving on... 1.2. Mixed content of Python License file Attached or see http://code.python.org/hg/branches/release2.7-maint/annotate/41a3e598052f/LICENSE The file consists of several licenses for multiple versions of Python. It is an unusual mix that negatively affects understanding. For the sake of clarity the LICENSE file scope should only be relevant to the current code. It may include a historical reference to other files if needed - LICENSE-HISTORY if you like. It is important to keep LICENSE terms concise for occasional contributors with skills needed for core development, because for outsiders there are many open source projects out there. _For example_, if I see an interesting project with GPL license (Ruby) and BSD license (Go) and ask myself "What should I choose for the next time I feel too depressive to spend my weekend watching movies?" - I will choose Go. I am sure it won't be a waste of my life time, just because both languages are equally trendy (Ruby sites are truly Gems in design, and Go presentation at Google IO was awesome), so license here is deciding factor. Every language has bugs and it is inevitable that you would like them to be fixed. As it is open source.. yes - you'll be politely asked to go fix them yourself. If you're an expert - you will fix them anyway (whatever you share fixes or not is a different story). Over the time you'll become acquainted with codebase and of course you will want to use this experience in your daily job writing code for customers who pay you money for keeping the code closed. In this case GPL allows you the freedom to rewrite the code from scratch, BSD - to copy/paste with attribution notice. If I'd be an outsider - when I'd see PSF license - I'd think - "or no, thats yet another stupid big license" (YASBL) and move on to the next news item (this time from pure C universe). 1.3 Python License content I believe that contents of attached LICENSE-PYTHON-2.x single copy/paste from LICENSE is enough for understanding and complying for Python 2.1+ series. Correct me if I wrong. But thanks to Berne Convention the wording can and should be improved. I hope the example in 1.2 made it clear that to attract professionals with strong core development skills, who are able to make quality contributions and are usually sought after in commercial projects, it is important to have license terms similar to those people already familiar and comfortable with, i.e. BSD, MIT/X (or more recent ISC variant - http://en.wikipedia.org/wiki/ISC_license) I propose the simplified PSF License v3 that in comparison to PSF v2: 1.3.1 combines point 4 and 5 to standard "THE SOFTWARE IS PROVIDED AS-IS ..." copied verbatim from ISC (MIT equivalent) license 1.3.2 drops point 6 as it lacks the copyright of Captain Obvious 1.3.3 combines points 8, 1 and 2 into standard ISC (simplified MIT) header with "and the following conditions are met:" from BSD license to outline the requirements of PSF in comparison to MIT, BSD and ISC style licenses 1.3.4 replaces point 7 with standard "Neither the name of the ... " from BSD license 1.3.5 replaces point 3 with "Redistributions of derivative works should include a brief summary of the changes made to Python" Full text of license is attached as PSF-LICENSE-v3. For those who complain that I am not sending patches and only direct people what to do - LICENSE.patch contains the patch made with diff.py tool that comes bundled with Python. Please indicate if and where the license became different from legal point of view. 2. PSF fails to comply with the terms of Contributors Agreement http://python.org/psf/contrib/contrib-form/ Note that there are also: http://python.org/psf/contrib/contrib-form-python/ http://python.org/psf/contrib/contrib-form-jython/ which are reachable by "python contributor's agreement" search query and it is doesn't clear why there are multiple terms and why they differ. -- personal intermezzo -- The fact that Contributors Agreements chapter is here is that I didn't care about
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
2010/7/5 anatoly techtonik : > Sorry for touching a sore point of if I sound like a boss to someone. > I tried to be as constructive as possible, but politeness was not the > point, so I can only hope you understand. > > I do not think PSF does its job well and here is why. Please contact [email protected] then. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
On Mon, Jul 5, 2010 at 11:04, anatoly techtonik wrote: > Sorry for touching a sore point of if I sound like a boss to someone. > I tried to be as constructive as possible, but politeness was not the > point, so I can only hope you understand. > > I do not think PSF does its job well and here is why. > > > 1. Python licensing terms are explained poorly > In order to "advance the Python programming language", and "to support > and facilitate the growth of international community" PSF should be > clear about the legal stuff with no complications. So that even people > without English background can understand the terms. > > 1.1 Let's start with http://www.python.org/psf/license/ > ... > Full text of the Python 2.6.2 license > ... > Q: Why 2.6.2? > A: Nobody cares. But no one also cares that it's 2.6.2. Someone who has editing writes on the website decided to point the link to then newest version of the license at that time. But the only difference in the license between releases is that there is another line recording a release date. THAT'S IT! So who care if it is 2.6.2 that's listed? That page could get updated by the release manager for every release, but that's just another step in an already involved process. > > Inside referenced doc there are several licenses for Python + > historical note. I remember I've tried to read this file several > times, but only after comparing freeness and beerness of PSF license > to GPL in private talk with Eric I was able to go through this > seriously. > Moving on... > > 1.2. Mixed content of Python License file > Attached or see > http://code.python.org/hg/branches/release2.7-maint/annotate/41a3e598052f/LICENSE > > The file consists of several licenses for multiple versions of Python. > It is an unusual mix that negatively affects understanding. For the > sake of clarity the LICENSE file scope should only be relevant to the > current code. It may include a historical reference to other files if > needed - LICENSE-HISTORY if you like. But the license stack is required. There is code in Python that dates back to the early 1990s and is covered by the oldest license in there. Unless an explicit purge is done to rid Python of all code that falls under one of the licenses in the stack you cannot just remove it because it's old. The license is complicated and long because Python's history is complicated and long. > > It is important to keep LICENSE terms concise for occasional > contributors with skills needed for core development, because for > outsiders there are many open source projects out there. > _For example_, if I see an interesting project with GPL license (Ruby) > and BSD license (Go) and ask myself "What should I choose for the next > time I feel too depressive to spend my weekend watching movies?" - I > will choose Go. I am sure it won't be a waste of my life time, just > because both languages are equally trendy (Ruby sites are truly Gems > in design, and Go presentation at Google IO was awesome), so license > here is deciding factor. Every language has bugs and it is inevitable > that you would like them to be fixed. As it is open source.. yes - > you'll be politely asked to go fix them yourself. If you're an expert > - you will fix them anyway (whatever you share fixes or not is a > different story). Over the time you'll become acquainted with codebase > and of course you will want to use this experience in your daily job > writing code for customers who pay you money for keeping the code > closed. In this case GPL allows you the freedom to rewrite the code > from scratch, BSD - to copy/paste with attribution notice. > > If I'd be an outsider - when I'd see PSF license - I'd think - "or no, > thats yet another stupid big license" (YASBL) and move on to the next > news item (this time from pure C universe). The license is certified by the OSI and is GPL-compatible. If you want to go through the entire codebase of Python and rewrite it so that it can be licensed under a BSD-derived one, go for it. I for one, have better things to do. > > > 1.3 Python License content > > I believe that contents of attached LICENSE-PYTHON-2.x single > copy/paste from LICENSE is enough for understanding and complying for > Python 2.1+ series. Correct me if I wrong. But thanks to Berne > Convention the wording can and should be improved. > > I hope the example in 1.2 made it clear that to attract professionals > with strong core development skills, who are able to make quality > contributions and are usually sought after in commercial projects, it > is important to have license terms similar to those people already > familiar and comfortable with, i.e. BSD, MIT/X (or more recent ISC > variant - http://en.wikipedia.org/wiki/ISC_license) Out of my over 8 years of participating on python-dev, this is the first time ANYONE has brought this up. I do not think we are losing any developers who want to contribute because of the PSF license. > > I propose the simplified PSF Licens
Re: [Python-Dev] Mercurial migration readiness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. Löwis wrote: I'd love to see a more detailed description of this, including why someone new to Mercurial would choose one over the other. >>> I think someone new to Mercurial shouldn't choose either one. >>> Just sit back and wait for the real migration to happen. >> I would say that using the SVN mirror is a fine way to experiment with >> using hg against the Python sources to develop and test patches. > > I think your description already falls into the "advanced user" > category. The new-to-mercurial committer should (IMO) use a "what if it > still was svn" workflow, which uses hg pull/up/commit/push. That can > only work if pushing really has the desired effect, which isn't the case > for any of the installations that we operate. I am not a committer myself, and not really familiar with Mercurial (I know CVS/SVN best, and bzr better). I found the current hg mirror of svn quite useful as a way to work on bugs, review patches, etc. without needing any commit access. > When the test-for-two-weeks installation becomes available, the > new-to-hg users will have a chance to learn how to use it without fear > of breaking anything. Until then, they should just remain patient. Experimenting with the mirror *today* without trying to push changes back would give those users a chance to do "familiarization" drills with the majority of mercurial's features, with the exception of the final push. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwyPKwACgkQ+gerLs4ltQ6zxQCcCRFduUc97jH3g28m/xh3+fTC RtIAniyqilkaNFHS54bW+oF4YXv/cq4l =pdkc -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration readiness
> Experimenting with the mirror *today* without trying to push changes > back would give those users a chance to do "familiarization" drills with > the majority of mercurial's features, with the exception of the final push. That's true. However, for those users, I'd rather recommend to use hg on an entirely independent project. That worked for me. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FWD: error: 3.2 release schedule has release in Jan 2010.
That's now fixed. The time machine disagreed with me. Georg Am 05.07.2010 18:28, schrieb Aahz: > - Forwarded message from Ric Johnson - > >> Date: Mon, 5 Jul 2010 08:49:29 -0700 (PDT) >> From: Ric Johnson >> Subject: error: 3.2 release schedule has release in Jan 2010. >> To: [email protected] >> >> Hey! >> There's a typo on http://www.python.org/dev/peps/pep-0392/: >> >> Release Schedule >> >> The current schedule is: >> >> ... >> >> # 3.2 candidate 2: January 1, 2010 ==> should be 2011 >> # 3.2 final: January 15, 2010 ==> should be 2011 >> >> >> I know it is rough schedule but it looks bad ... >> >> Ric >> >> -Verba nihil operandi melius est quam absurde. >> >> >> > > - End forwarded message - > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
On Tue, Jul 6, 2010 at 6:04 AM, Brett Cannon wrote: > I have tried to give you the benefit of the doubt, Anatoly, and have > tried to overlook your general attitude of being somewhat pushy, but > this has pushed me over the edge. If you had some questions about the > license, you should have asked the PSF or here on python-dev instead > of saying that the PSF is not doing a good job. From where I come from > you first try to calmly talk to the people who are doing something > that you have questions about before calling for their overthrowing. > > Considering essentially all of the core developers are PSF members you > have just insulted the entire development team by saying they are > doing a poor job in shepherding the project they work on in their > spare time . Good job. And by the way, some of the core developers > also used to be (that's me) or currently are on the board of > directors. Well done indeed. Thanks for taking the time to respond Brett - saves me from saying basically the same thing. Anatoly - try to give other people a little credit for not being complete idiots, OK? A lot of stuff in the world doesn't make much sense from a green field point of view, but is comprehensible once the long and involved history is taken into account. Jumping to the conclusion that people are incompetent idiots just encourages them to ignore your input (since you're clearly not listening to anyone else). As Brett noted, yes, the LICENSE file is complicated, but most people don't bother reading it themselves - they ask what FSF and OSI think of it, and get the answers "BSD style" and "GPL compatible" and are happy with that. The corporate history is such that the PSF probably doesn't have the legal rights to simplify it (we might have some scope to tidy it up, such as splitting it into two files as you suggest, but we would have to spend money to find out for sure, and don't consider that a particularly good use of contributor's funds). As far as the issue of not including the contributor agreement related licenses in the source goes, note that the contributor agreement explicitly provides the PSF with relicensing rights. If you want to dispute the legal effectiveness of that then you'll want to A) be a lawyer or at least consult one and B) take it up with Van Lindbergh, the PSF's lawyer. Normally we don't require contributor agreements for minor patches and other submissions, but given the attitude you have displayed here, I expect we'll make an exception for you (i.e. until you provide evidence of a change of heart by signing a contributor agreement, I'd consider any patches you provide to be on sufficiently legally dubious ground that we aren't in a position to accept them). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
On Tue, Jul 6, 2010 at 7:05 AM, Nick Coghlan wrote: > Normally we don't require contributor agreements for > minor patches and other submissions, but given the attitude you have > displayed here, I expect we'll make an exception for you (i.e. until > you provide evidence of a change of heart by signing a contributor > agreement, I'd consider any patches you provide to be on sufficiently > legally dubious ground that we aren't in a position to accept them). Sorry, that crack was uncalled for. You have made positive contributions to the language in the past, and hopefully will be willing and able to do so in the future. Just try to lose the attitude that everyone else is dumber than dirt. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
On Mon, Jul 5, 2010 at 11:05 PM, Nick Coghlan wrote: > As Brett noted, yes, the LICENSE file is complicated, but most people > don't bother reading it themselves - they ask what FSF and OSI think > of it, and get the answers "BSD style" and "GPL compatible" and are > happy with that. Presumably at least the BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0 can be removed from the LICENSE file because otherwise it appears that answer to "GPL compatible" must be no? Schiavo Simon ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
On Tue, 6 Jul 2010 07:05:58 +1000 Nick Coghlan wrote: > > As Brett noted, yes, the LICENSE file is complicated, but most people > don't bother reading it themselves - they ask what FSF and OSI think > of it, and get the answers "BSD style" and "GPL compatible" and are > happy with that. Which is the very wrong thing to do, though. License text should be understandable by non-lawyer people; IIUC OpenBSD has a very sane policy in this respect. > The corporate history is such that the PSF probably > doesn't have the legal rights to simplify it Yes, that's probably the real problem and why it's not of much use to argue about it. You have to trust the PSF (and/or python-dev), because the license text may not be able to change very soon (if any day at all). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
anatoly techtonik: > The file consists of several licenses for multiple versions of Python. > It is an unusual mix that negatively affects understanding. A simpler license would be better. There have been moves in the past to simplify the license of Python but this would require agreement from the current rights owners including CWI and CNRI. IIRC not all of the rights owners are willing to agree to a change. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
Neil Hodgson wrote: > anatoly techtonik: > >> The file consists of several licenses for multiple versions of Python. >> It is an unusual mix that negatively affects understanding. > >A simpler license would be better. > >There have been moves in the past to simplify the license of Python > but this would require agreement from the current rights owners > including CWI and CNRI. IIRC not all of the rights owners are willing > to agree to a change. > That is the current position. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SVN <-> HG workflow to split Python Library by Module
Jesse Noller writes: > On Sat, Jul 3, 2010 at 7:05 AM, Dirkjan Ochtman wrote: > > On Sat, Jul 3, 2010 at 12:53, Stephen J. Turnbull > > wrote: > >> The point of submodules a la git is subtly different. It is that you > >> can mix and match *known versions* of the modules. So, eg, in order > >> to work on recent urllib, maybe you need a recent *but stable* email > >> but you don't want any of the work being done on removing the GIL > >> because it's somewhat unstable. > > > > This sounds like it could also be done with good branching + merging. > > > > Cheers, > > > > Dirkjan > > What Dirkjan said; since using mercurial more and more lately, local > branches are an insanely good tool and method of coordinating work I have nothing against local branches as a tool and method of coordinating work. But what Dirkjan said is insufficiently precise. It's not about the branching and merging operations (submodules are, after all, just a way of specifying certain branch/merge patterns). It's about knowing certain things about what's in the branch, and how the content is referenced (ie, with submodule-local tags, rather than project-global tags). It's about modularity over history, as well as in the static, instantaneous structure of the application. Since history needs to be modular, too, it might not work as well as I made it sound above, I admit. But there are times when such a capability is quite useful, and in the stdlib it seems likely that most of the modules will have sufficiently independent histories. Consider the problem going *backwards*. You have a current Python 3 in your workspace, and you suddenly realize that if you rewind the GIL (core) work to about March a nagging intermittent bug will go away, but email needs to be at least May 1 but no later than June 15. How do you spell that without submodules, or a preexisting branch that happens to have exactly the right stuff in it? I know it can be done, but it requires some thought and quite a bit of dexterity with branching, checking out the right versions of the right files and overlaying them on the branch you are creating without pulling in unwanted versions of other files. Now, how do you keep that branch updated with bugfixes and stuff that doesn't directly affect your current work? You'll have to keep rewinding the GIL- related and email-related files by hand. Submodules make that easy. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration readiness
Georg Brandl writes: > I wouldn't say that. strip works well and it does so logically, > once one understands the DAG. The only thing discouraged is to strip > changesets once pushed to the public repo, but that holds as well for > getting rid of the changesets by making a new clone without them. Actually, neither method of "rewinding" a local repo is especially discouraged, if you know what you're doing. What you mustn't do is strip the changes in the public repo itself (or turn them into unreferencable garbage). Back in the bad old days of git, "push" often had such effects, but with modern versions of any of the dVCSes, public repos are allowed to refuse pushes that would garbage any changesets, and even if they're permitted, you need to use a --force option to push. There's nothing wrong with stripping your local repo(s), even if the stripped changes have already been pushed to the public repo. I would say it's unusual for most people to want to strip publicly available changesets, but after all, you just end up with an out-of-date repo, which is exactly what Mercurial is all about handling. Ie, it is *normal* to have an out-of-date repo locally when there are other active committers; it's just unusual to intentionally strip. But the consequences are the same. As with any out-of-date repo, you will need to merge before pushing. New users probably shouldn't do it to excess, because of the possibility of exposing yourself to a difficult merge. But the flip side is that new users probably want to update from the public repo before doing significant work for exactly the same reasons. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
Antoine Pitrou writes: > Which is the very wrong thing to do, though. License text should be > understandable by non-lawyer people; This is a common mistake, at least with respect to common-law systems. Licenses are written in a formal language intended to have precise semantics, especially in the event of a dispute going to court. What you wrote is precisely analogous to "a computer program should be understandable to non-programmer people". The fact is, in the U.S. if an ordinary person thinks they understand a license, then it's probably quite unpredictable what a court will say about attempts to enforce it. WTF-an-economist-defending-lawyers??!?!!-ly y'rs, ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
Le mardi 06 juillet 2010 à 12:58 +0900, Stephen J. Turnbull a écrit : > Antoine Pitrou writes: > > > Which is the very wrong thing to do, though. License text should be > > understandable by non-lawyer people; > > This is a common mistake, at least with respect to common-law systems. > Licenses are written in a formal language intended to have precise > semantics, especially in the event of a dispute going to court. What > you wrote is precisely analogous to "a computer program should be > understandable to non-programmer people". The point of free software licenses, though (as opposed to proprietary licenses), is not mainly to go to court (to “protect IP”, as the PSF says - quite naively in my opinion); it is to enable trust among people. Hence the requirement for being readable and understandable by the very people whom they help work together. (and besides, of course, a lawyer's opinion can never make you sure of anything wrt. court testing; lawyers very frequently disagree between themselves, and they are very careful to never provide any formal guarantee; for example, several French “IP” lawyers have argued that free licenses have no value in French authorship right; that hasn't prevented companies from making business with the GPL and other free licenses here) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing // PSF // Motion of non-confidence
On Tue, Jul 6, 2010 at 6:47 AM, Antoine Pitrou wrote: > Le mardi 06 juillet 2010 à 12:58 +0900, Stephen J. Turnbull a écrit : >> Antoine Pitrou writes: >> >> > Which is the very wrong thing to do, though. License text should be >> > understandable by non-lawyer people; >> >> This is a common mistake, at least with respect to common-law systems. >> Licenses are written in a formal language intended to have precise >> semantics, especially in the event of a dispute going to court. What >> you wrote is precisely analogous to "a computer program should be >> understandable to non-programmer people". > > The point of free software licenses, though (as opposed to proprietary > licenses), is not mainly to go to court (to “protect IP”, as the PSF > says - quite naively in my opinion); it is to enable trust among people. > Hence the requirement for being readable and understandable by the very > people whom they help work together. Really? That's the *last* thing where I would be looking for trust. among developers. Open source licenses do take part into a trust relationship -- however it is trust between corporate entities with too many lawyers who wouldn't trust the open source development communities otherwise. Their worries are mainly about people contributing tainted material to open source projects which then later can be used to place pressure on deep pockets (see the SCO UNIX suit for example). A secondary reasoning for some open source licenses might be to prevent others from running off with the good stuff and selling it for profit. The GPL is big on that, but it's never motivated me with Python (hence the tenuous relationship at best with the FSF and GPL software). > (and besides, of course, a lawyer's opinion can never make you sure of > anything wrt. court testing; lawyers very frequently disagree between > themselves, and they are very careful to never provide any formal > guarantee; for example, several French “IP” lawyers have argued that > free licenses have no value in French authorship right; that hasn't > prevented companies from making business with the GPL and other free > licenses here) There are two systems. The courts and the lawyers. The lawyers are the most important -- they control the backroom deals and trust. The courts are mostly there as a back-up threat since even winning a lawsuit is incredibly expensive compared to settling. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Licensing
Guido van Rossum writes: > A secondary reasoning for some open source licenses might be to > prevent others from running off with the good stuff and selling it for > profit. The GPL is big on that […] Really, it's not. Please stop spreading this canard. The GPL explicitly and deliberately grants the freedom to sell the work for profit. Every copyright holder who grants license under the terms of the GPL is explicitly saying “you can seel this software for any price you like” http://www.gnu.org/philosophy/selling.html>. Whatever other complaints people may have against the GPL, it's simply *false* to claim what Guido did above. Please stop it. -- \“We cannot solve our problems with the same thinking we used | `\ when we created them.” —Albert Einstein | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
