From ben+python at benfinney.id.au Tue Dec 9 00:40:59 2014 From: ben+python at benfinney.id.au (Ben Finney) Date: Tue, 09 Dec 2014 10:40:59 +1100 Subject: [Python-legal-sig] Making it possible to accept contributions without CLA Message-ID: <85sigpiub8.fsf@benfinney.id.au> Howdy all, The PSF presently madates that any contributor to Python sign the ?Contributor Agreement?. I raise this, not to start another disagreement about whether this is desirable; I understand that some within the PSF regard it as an unfortunate barrier to entry, even if it is necessary. Rather, I'm asking what, specifically, necessitates this situation; and how to remove the necessity. What would need to change, for the PSF to accept contributions to the Python copyrighted works, without requiring the contributor to do anything but license the work under Apache 2.0 license? The PSF licenses its work (Python and other associated copyrighted works) to recipients under the terms of a specific Python license . That license is a collection of terms and conditions from software components in Python. Which specific components would be incompatible with contributions licensed simply under Apache 2.0 license, without any CLA? Components such as the ?http.cookie? code are licensed under terms that are clearly compatible with other contributions to the PSF under Apache 2.0 terms. But some other components are not. Presumably, whatever remains of code that was licensed under the CNRI License Agreement would not be compatible with a simple Apache 2.0 license grant. If some persons were to do the work of replacing code licensed under such incompatible terms (such as the CNRI terms) with code licensed to everyone under Apache 2.0 terms, would that be sufficient to then drop the PSF's requirement for a CLA? Is there some other dependency? What, specifically; and what can be done to remove that dependency? My goal is to see the PSF reach a state where the licensing situation is an equal-footing ?inbound = outbound? like most free software projects; where the PSF can happily receive from a contributor only the exact same license the PSF grants to any recipient of Python. This would make contributing to Python a simple matter of licensing the contribution to all recipients (including but not especially the PSF) under the Apache 2.0 license, without special agreement with anyone. For that to happen, we need to know the specific barriers to such a goal. What are they? -- \ ?A computer once beat me at chess, but it was no match for me | `\ at kick boxing.? ?Emo Philips | _o__) | Ben Finney From mal at python.org Tue Dec 9 10:28:29 2014 From: mal at python.org (M.-A. Lemburg) Date: Tue, 09 Dec 2014 10:28:29 +0100 Subject: [Python-legal-sig] Making it possible to accept contributions without CLA In-Reply-To: <85sigpiub8.fsf@benfinney.id.au> References: <85sigpiub8.fsf@benfinney.id.au> Message-ID: <5486C0BD.3020903@python.org> Hi Ben, On 09.12.2014 00:40, Ben Finney wrote: > Howdy all, > > The PSF presently madates that any contributor to Python sign > > the ?Contributor Agreement?. > > I raise this, not to start another disagreement about whether this is > desirable; I understand that some within the PSF regard it as an > unfortunate barrier to entry, even if it is necessary. > > Rather, I'm asking what, specifically, necessitates this situation; and > how to remove the necessity. The purpose of the contrib forms is to allow the PSF to relicense the work under an open source license we see fit (at the moment the PSF v2 license). This was done in order to avoid adding more licenses to the Python distribution. > What would need to change, for the PSF to accept contributions to the > Python copyrighted works, without requiring the contributor to do > anything but license the work under Apache 2.0 license? > > The PSF licenses its work (Python and other associated copyrighted > works) to recipients under the terms of a specific Python license > . > > That license is a collection of terms and conditions from software > components in Python. Which specific components would be incompatible > with contributions licensed simply under Apache 2.0 license, without any > CLA? That's really the wrong question to ask. As you know, one of the contrib form licenses is the Apache 2.0 license, so as contributor you can license the code under the Apache 2.0 license to the PSF and additionally give the PSF the right to relicense the code under different terms. To be clear: We currently have no motivation to change the Python license terms to Apache 2.0 (or rather add the Apache 2.0 license to the stack). > Components such as the ?http.cookie? code are licensed under terms that > are clearly compatible with other contributions to the PSF under Apache > 2.0 terms. > > But some other components are not. Presumably, whatever remains of code > that was licensed under the CNRI License Agreement would not be > compatible with a simple Apache 2.0 license grant. > > If some persons were to do the work of replacing code licensed under > such incompatible terms (such as the CNRI terms) with code licensed to > everyone under Apache 2.0 terms, would that be sufficient to then drop > the PSF's requirement for a CLA? No, because we don't want to be stuck with this single license choice forever and we don't want to have to contact each an every contributor when changing the license. Also note that the CLAs make sure that the contributor is actually licensing code that he or she owns to the PSF. This is different from just adding a license to a code repository. > Is there some other dependency? What, specifically; and what can be done > to remove that dependency? > > My goal is to see the PSF reach a state where the licensing situation is > an equal-footing ?inbound = outbound? like most free software projects; > where the PSF can happily receive from a contributor only the exact same > license the PSF grants to any recipient of Python. > > This would make contributing to Python a simple matter of licensing the > contribution to all recipients (including but not especially the PSF) > under the Apache 2.0 license, without special agreement with anyone. > > For that to happen, we need to know the specific barriers to such a > goal. What are they? I don't see how this could happen, simply because the Apache 2.0 license does not give us the right to relicense the code under a different license. The PSF needs to be able to defend the IP rights in Python and without proper legal setups, we cannot fulfill this role. -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ From techtonik at gmail.com Tue Dec 9 11:19:47 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 9 Dec 2014 13:19:47 +0300 Subject: [Python-legal-sig] Making it possible to accept contributions without CLA In-Reply-To: <5486C0BD.3020903@python.org> References: <85sigpiub8.fsf@benfinney.id.au> <5486C0BD.3020903@python.org> Message-ID: node.js dropped CLA and Python should do the same. https://www.joyent.com/blog/broadening-node-js-contributions > The PSF needs to be able to defend the IP rights in Python PSF could handle such issues on a case by case basis. If it chooses to generalize it then I read it as mistrust in contributors. If it mistrusts me, why I should trust it? It is a wrong way. From mal at python.org Tue Dec 9 11:47:05 2014 From: mal at python.org (M.-A. Lemburg) Date: Tue, 09 Dec 2014 11:47:05 +0100 Subject: [Python-legal-sig] Making it possible to accept contributions without CLA In-Reply-To: References: <85sigpiub8.fsf@benfinney.id.au> <5486C0BD.3020903@python.org> Message-ID: <5486D329.1010807@python.org> On 09.12.2014 11:19, anatoly techtonik wrote: > node.js dropped CLA and Python should do the same. > https://www.joyent.com/blog/broadening-node-js-contributions > >> The PSF needs to be able to defend the IP rights in Python > > PSF could handle such issues on a case by case basis. If it > chooses to generalize it then I read it as mistrust in > contributors. If it mistrusts me, why I should trust it? It is a > wrong way. This doesn't have anything to do with trust in contributors. We can only defend the IP rights in court, if we have such rights and can prove this. Without the CLAs we would have no such proof and indeed no rights to defend the IP rights arising from contributions, since the PSF would only be a user of the contribution's code license and only the contributor could defend the rights to the contributed code. Such a setup would neither be in the interest of the contributor nor the PSF or the Python community. -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ From ben+python at benfinney.id.au Tue Dec 9 21:23:20 2014 From: ben+python at benfinney.id.au (Ben Finney) Date: Wed, 10 Dec 2014 07:23:20 +1100 Subject: [Python-legal-sig] Making it possible to accept contributions without CLA References: <85sigpiub8.fsf@benfinney.id.au> <5486C0BD.3020903@python.org> Message-ID: <85bnncind3.fsf@benfinney.id.au> "M.-A. Lemburg" writes: > The purpose of the contrib forms is to allow the PSF to relicense the > work under an open source license we see fit (at the moment the PSF v2 > license). I'm going to assume, then, that if this need to relicense contributions under the PSF license did not exist, the CLA would not be required. Is that right? > This was done in order to avoid adding more licenses to the Python > distribution. Okay. What about removing existing license conditions? In particular, those incompatible with the incoming (Apache License 2.0) license? > > That license is a collection of terms and conditions from software > > components in Python. Which specific components would be > > incompatible with contributions licensed simply under Apache 2.0 > > license, without any CLA? > > That's really the wrong question to ask. As you know, one of the > contrib form licenses is the Apache 2.0 license, so as contributor you > can license the code under the Apache 2.0 license to the PSF and > additionally give the PSF the right to relicense the code under > different terms. If there were no longer any code incompatible with Apache License 2.0 in Python, then contributors would not need to give PSF that special power. Right? > To be clear: We currently have no motivation to change the Python > license terms to Apache 2.0 (or rather add the Apache 2.0 license to > the stack). I'm presenting such a motivation: the ability to accept contributions licensed under Apache License 2.0, without needing to obtain a CLA from the contributor. > > If some persons were to do the work of replacing code licensed under > > such incompatible terms (such as the CNRI terms) with code licensed > > to everyone under Apache 2.0 terms, would that be sufficient to then > > drop the PSF's requirement for a CLA? > > No, because we don't want to be stuck with this single license choice > forever and we don't want to have to contact each an every contributor > when changing the license. The Apache License 2.0 is compatible with a wide range of free-software license conditions, including the conditions of many licenses in works already in Python (such as ?http.cookie? and others). If all the code in Python were under such licenses, the PSF could choose to license Python as a whole under any license conditions compatible with that set, without needing to contact any contributor. > Also note that the CLAs make sure that the contributor is actually > licensing code that he or she owns to the PSF. This is different from > just adding a license to a code repository. That is different, yes. The PSF does not need any special powers for that; the contributor can be asked merely for some certification they have the authority to grant Apache License 2.0 in their contribution. So that's a separate need from the CLA, and no CLA is needed for that. > I don't see how this could happen, simply because the Apache 2.0 > license does not give us the right to relicense the code under a > different license. Yes, it does: Apache License 2.0 ?2 explicitly grants the recipient (PSF, in this case) the freedom to sublicnese the work. So, subject to the other terms in Apache License 2.0, PSF is free to grant some other license compatible with Apache License 2.0, such as GPLv3 or Expat or BSD 2-clause, etc. > The PSF needs to be able to defend the IP rights in Python and > without proper legal setups, we cannot fulfill this role. Given that contributions under Apache License 2.0 explicitly grant PSF the freedom to choose a different, compatible license for redistribution, I think this is already addressed. If I understand correctly, the only barrier to actually doing this is some existing components in Python that are under license conditions incompatible with Apache License 2.0. -- \ ?The entertainment industry calls DRM "security" software, | `\ because it makes them secure from their customers.? ?Cory | _o__) Doctorow, 2014-02-05 | Ben Finney From donald at stufft.io Tue Dec 9 21:49:54 2014 From: donald at stufft.io (Donald Stufft) Date: Tue, 9 Dec 2014 15:49:54 -0500 Subject: [Python-legal-sig] Making it possible to accept contributions without CLA In-Reply-To: <85bnncind3.fsf@benfinney.id.au> References: <85sigpiub8.fsf@benfinney.id.au> <5486C0BD.3020903@python.org> <85bnncind3.fsf@benfinney.id.au> Message-ID: <187ECF65-85DB-4158-B3D9-2B4529A41BD3@stufft.io> > On Dec 9, 2014, at 3:23 PM, Ben Finney wrote: > > The Apache License 2.0 is compatible with a wide range of free-software > license conditions, including the conditions of many licenses in works > already in Python (such as ?http.cookie? and others). > > If all the code in Python were under such licenses, the PSF could choose > to license Python as a whole under any license conditions compatible > with that set, without needing to contact any contributor. I don?t have an opinion on CLAs, and I quite like the ALv2 license, however I do want to point out that it is the opinion of the FSF that the ALV2 is not compatible with GPLv2 (though it is with GPLv3). I?m not a fan of the GPL so that doesn?t bother me so much, but I assume that such an incompatible license would not be acceptable to the PSF. This can be worked around by doing something like dual licensing with BSD and ALv2 or just BSD but the ALv2 on it?s own is likely not suitable. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA From mal at python.org Tue Dec 9 21:55:37 2014 From: mal at python.org (M.-A. Lemburg) Date: Tue, 09 Dec 2014 21:55:37 +0100 Subject: [Python-legal-sig] Making it possible to accept contributions without CLA In-Reply-To: <85bnncind3.fsf@benfinney.id.au> References: <85sigpiub8.fsf@benfinney.id.au> <5486C0BD.3020903@python.org> <85bnncind3.fsf@benfinney.id.au> Message-ID: <548761C9.5080508@python.org> On 09.12.2014 21:23, Ben Finney wrote: > "M.-A. Lemburg" writes: > >> The purpose of the contrib forms is to allow the PSF to relicense the >> work under an open source license we see fit (at the moment the PSF v2 >> license). > > I'm going to assume, then, that if this need to relicense contributions > under the PSF license did not exist, the CLA would not be required. Is > that right? No. In order for the PSF to be able to defend the IP in court, we have to have a paper trail for all IP in the Python distribution. Note that IP that's well separated such as a single module, or a library, can be handled in a different way, if there's no alternative, but our preference generally is to be able to relicense all contributions in order to avoid having to carry along too many licenses. >> This was done in order to avoid adding more licenses to the Python >> distribution. > > Okay. What about removing existing license conditions? In particular, > those incompatible with the incoming (Apache License 2.0) license? That's only possible by identifying and reimplementing the code in question. >>> That license is a collection of terms and conditions from software >>> components in Python. Which specific components would be >>> incompatible with contributions licensed simply under Apache 2.0 >>> license, without any CLA? >> >> That's really the wrong question to ask. As you know, one of the >> contrib form licenses is the Apache 2.0 license, so as contributor you >> can license the code under the Apache 2.0 license to the PSF and >> additionally give the PSF the right to relicense the code under >> different terms. > > If there were no longer any code incompatible with Apache License 2.0 in > Python, then contributors would not need to give PSF that special power. > Right? No; see above :-) >> To be clear: We currently have no motivation to change the Python >> license terms to Apache 2.0 (or rather add the Apache 2.0 license to >> the stack). > > I'm presenting such a motivation: the ability to accept contributions > licensed under Apache License 2.0, without needing to obtain a CLA from > the contributor. Why would you not want to sign a CLA if your code is under the Apache 2.0 license already ? The only two extra things we ask constibutors in the CLA is to a) identify themselves as authorized to enter the agreement, and b) allow the PSF to relicense their code under an open source license. Note that the contributor does not lose the copyright to the code. The CLA is not a copyright transfer. >>> If some persons were to do the work of replacing code licensed under >>> such incompatible terms (such as the CNRI terms) with code licensed >>> to everyone under Apache 2.0 terms, would that be sufficient to then >>> drop the PSF's requirement for a CLA? >> >> No, because we don't want to be stuck with this single license choice >> forever and we don't want to have to contact each an every contributor >> when changing the license. > > The Apache License 2.0 is compatible with a wide range of free-software > license conditions, including the conditions of many licenses in works > already in Python (such as ?http.cookie? and others). > > If all the code in Python were under such licenses, the PSF could choose > to license Python as a whole under any license conditions compatible > with that set, without needing to contact any contributor. Right, but that way we'd lose the possibility to defend the IP in court, since all the Apache license does is mention that each individual contributor gives a copyright license. As a result, we'd have to get the contributors to defend the IP, which would greatly weaken the position in court. >> Also note that the CLAs make sure that the contributor is actually >> licensing code that he or she owns to the PSF. This is different from >> just adding a license to a code repository. > > That is different, yes. The PSF does not need any special powers for > that; the contributor can be asked merely for some certification they > have the authority to grant Apache License 2.0 in their contribution. > > So that's a separate need from the CLA, and no CLA is needed for that. Well, it's an agreement which a contributor would have to sign before having the contribution accepted in the code base, so it's a CLA as well :-) >> I don't see how this could happen, simply because the Apache 2.0 >> license does not give us the right to relicense the code under a >> different license. > > Yes, it does: Apache License 2.0 ?2 explicitly grants the recipient > (PSF, in this case) the freedom to sublicnese the work. Sublicense yes, but not relicense under different terms. A sublicense always has to be at least as restrictive as the original license, so e.g. we could not remove the requirement to include a NOTICE file (if the contribution contains such a file). We could, for example, not relicense such code under the PSF license v2, because it doesn't have any such requirements or the patent license. The latter is one of the reasons why the CLA does not include the PSF license as initial license. > So, subject to the other terms in Apache License 2.0, PSF is free to > grant some other license compatible with Apache License 2.0, such as > GPLv3 or Expat or BSD 2-clause, etc. See above. >> The PSF needs to be able to defend the IP rights in Python and >> without proper legal setups, we cannot fulfill this role. > > Given that contributions under Apache License 2.0 explicitly grant PSF > the freedom to choose a different, compatible license for > redistribution, I think this is already addressed. > > If I understand correctly, the only barrier to actually doing this is > some existing components in Python that are under license conditions > incompatible with Apache License 2.0. This is true for all the code that was not contributed under the CLA. All code submitted under CLA can be freely relicensed under e.g. the Apache 2.0 license, should the PSF decide to do so. However, even with Python completely under the Apache 2.0 license, we'd most likely still want to keep the CLA process, because it gives us more flexibility for the future. By being able to relicense the code, we can change the license to a more modern one without having to reach out to all contributors, so a major pain in open source relicensing is solved by the CLAs. Nowadays, signing a CLA can be done electronically, so it's not much of a burden on the contributors anymore. In the early days, you had to wet sign it, fax and/or postal mail it :-) -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ From ben+python at benfinney.id.au Wed Dec 10 00:20:08 2014 From: ben+python at benfinney.id.au (Ben Finney) Date: Wed, 10 Dec 2014 10:20:08 +1100 Subject: [Python-legal-sig] Making it possible to accept contributions without CLA References: <85sigpiub8.fsf@benfinney.id.au> <5486C0BD.3020903@python.org> <85bnncind3.fsf@benfinney.id.au> <187ECF65-85DB-4158-B3D9-2B4529A41BD3@stufft.io> Message-ID: <857fy0if6f.fsf@benfinney.id.au> Donald Stufft writes: > I don?t have an opinion on CLAs, and I quite like the ALv2 license, > however I do want to point out that it is the opinion of the FSF that > the ALV2 is not compatible with GPLv2 (though it is with GPLv3). That is correct (by the FSF's opinion too), which is why I specified the Apache License 2.0 is compatible with the GPLv3. Note too that this was just one example of a free-software license which the PSF could choose for distributing Python, which would be compatible with Apache License 2.0 contributions; it was not an advocation of any particular license. -- \ ?[F]reedom of speech does not entail freedom to have your ideas | `\ accepted by governments and incorporated into law and policy.? | _o__) ?Russell Blackford, 2010-03-06 | Ben Finney From ben+python at benfinney.id.au Wed Dec 10 00:38:55 2014 From: ben+python at benfinney.id.au (Ben Finney) Date: Wed, 10 Dec 2014 10:38:55 +1100 Subject: [Python-legal-sig] Certifying provenance of contributions (was: Making it possible to accept contributions without CLA) References: <85sigpiub8.fsf@benfinney.id.au> <5486C0BD.3020903@python.org> <85bnncind3.fsf@benfinney.id.au> <548761C9.5080508@python.org> Message-ID: <85388oieb4.fsf_-_@benfinney.id.au> "M.-A. Lemburg" writes: > On 09.12.2014 21:23, Ben Finney wrote: > > The PSF does not need any special powers for [knowing the > > contributor has the legal right to grant the PSF license in the > > contribution]; the contributor can be asked merely for some > > certification they have the authority to grant Apache License 2.0 in > > their contribution. > > > > So that's a separate need from the CLA, and no CLA is needed for > > that. > > Well, it's an agreement which a contributor would have to sign > before having the contribution accepted in the code base, so > it's a CLA as well :-) I meant by the above that such a certification would not be an agreement at all. It would be a one-party declaration that the contributor holds copyright in the contribution; there is no other party so it is not an agreement of any kind. There is no need to enter some special unilateral transfer of power to the PSF. The PSF can merely require that the contributor present such a declaration, without forming any special agreement or transfer of power. Such a declaration is sometimes called a ?Developer's Certificate of Origin?, and is used by the Linux projects and the Samba project, among many others. For example, Samba's requirements for accepting contributions is at , and does not require any special powers granted to the Samba project, while still requiring positive declaration of copyright provenance. Is this sufficient to demonstrate that there is no need for a CLA to have the PSF know the copyright provenance of contributions? -- \ ?Working out the social politics of who you can trust and why | `\ is, quite literally, what a very large part of our brain has | _o__) evolved to do.? ?Douglas Adams | Ben Finney From ben+python at benfinney.id.au Mon Dec 15 06:18:29 2014 From: ben+python at benfinney.id.au (Ben Finney) Date: Mon, 15 Dec 2014 16:18:29 +1100 Subject: [Python-legal-sig] Portable code: __import__ demands different string types between 2 and 3 Message-ID: <85lhm9cwyi.fsf@benfinney.id.au> Howdy all, What should I do, in a world where all text literals are Unicode by default, to make ?__import__? work in both Python 2 and 3? I'm slowly learning about making Python code that will run under both Python 2 (version 2.6 or above) and Python 3 (version 3.2 or above). This entails, I believe, the admonition to ensure text literals are Unicode by default:: from __future__ import unicode_literals and to specify bytes literals explicitly with ?b'wibble'? if needed. The ?__import__? built-in function, though, is tripping up. A contrived, trivial project layout:: $ mkdir fooproject/ $ cd fooproject/ $ mkdir foo/ $ printf "" > foo/__init__.py $ mkdir foo/bar/ $ printf "" > foo/bar/__init__.py Here's a simple ?fooproject/setup.py?:: from __future__ import unicode_literals main_module_name = 'foo' main_module = __import__(main_module_name, fromlist=['bar']) That fails under Python 2, but runs fine under Python 3:: $ python2 ./setup.py Traceback (most recent call last): File "./setup.py", line 4, in main_module = __import__(main_module_name, fromlist=['bar']) TypeError: Item in ``from list'' not a string $ python3 ./setup.py We've deliberately made unadorned strings Unicode by default. By ?not a string?, I presume Python 2 means ?not a ?bytes? object?. Okay, so we'll explicitly set that to a ?bytes? literal:: from __future__ import unicode_literals main_module_name = 'foo' main_module = __import__(main_module_name, fromlist=[b'bar']) Now Python 2 is satisfied, but Python 3 complains:: $ python2 ./setup.py $ python3 ./setup.py Traceback (most recent call last): File "./setup.py", line 4, in main_module = __import__(main_module_name, fromlist=[b'bar']) File "", line 2281, in _handle_fromlist TypeError: hasattr(): attribute name must be string How can I get that ?__import__? call, complete with its ?fromlist? parameter, working correctly under both Python 2 and Python 3, keeping the ?unicode_literals? setting? -- \ ?I do not believe in immortality of the individual, and I | `\ consider ethics to be an exclusively human concern with no | _o__) superhuman authority behind it.? ?Albert Einstein, letter, 1953 | Ben Finney From alex.gaynor at gmail.com Mon Dec 15 07:36:37 2014 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Mon, 15 Dec 2014 06:36:37 +0000 Subject: [Python-legal-sig] Portable code: __import__ demands different string types between 2 and 3 References: <85lhm9cwyi.fsf@benfinney.id.au> Message-ID: Was sending this to legal-sig a mistake? Alex On Sun Dec 14 2014 at 9:18:37 PM Ben Finney wrote: > Howdy all, > > What should I do, in a world where all text literals are Unicode by > default, to make ?__import__? work in both Python 2 and 3? > > I'm slowly learning about making Python code that will run under both > Python 2 (version 2.6 or above) and Python 3 (version 3.2 or above). > > This entails, I believe, the admonition to ensure text literals are > Unicode by default:: > > from __future__ import unicode_literals > > and to specify bytes literals explicitly with ?b'wibble'? if needed. > > > The ?__import__? built-in function, though, is tripping up. > > A contrived, trivial project layout:: > > $ mkdir fooproject/ > $ cd fooproject/ > > $ mkdir foo/ > $ printf "" > foo/__init__.py > $ mkdir foo/bar/ > $ printf "" > foo/bar/__init__.py > > Here's a simple ?fooproject/setup.py?:: > > from __future__ import unicode_literals > > main_module_name = 'foo' > main_module = __import__(main_module_name, fromlist=['bar']) > > That fails under Python 2, but runs fine under Python 3:: > > $ python2 ./setup.py > Traceback (most recent call last): > File "./setup.py", line 4, in > main_module = __import__(main_module_name, fromlist=['bar']) > TypeError: Item in ``from list'' not a string > > $ python3 ./setup.py > > We've deliberately made unadorned strings Unicode by default. By ?not a > string?, I presume Python 2 means ?not a ?bytes? object?. > > > Okay, so we'll explicitly set that to a ?bytes? literal:: > > from __future__ import unicode_literals > > main_module_name = 'foo' > main_module = __import__(main_module_name, fromlist=[b'bar']) > > Now Python 2 is satisfied, but Python 3 complains:: > > $ python2 ./setup.py > > $ python3 ./setup.py > Traceback (most recent call last): > File "./setup.py", line 4, in > main_module = __import__(main_module_name, fromlist=[b'bar']) > File "", line 2281, in > _handle_fromlist > TypeError: hasattr(): attribute name must be string > > > How can I get that ?__import__? call, complete with its ?fromlist? > parameter, working correctly under both Python 2 and Python 3, keeping > the ?unicode_literals? setting? > > -- > \ ?I do not believe in immortality of the individual, and I | > `\ consider ethics to be an exclusively human concern with no | > _o__) superhuman authority behind it.? ?Albert Einstein, letter, 1953 | > Ben Finney > > _______________________________________________ > Python-legal-sig mailing list > Python-legal-sig at python.org > https://mail.python.org/mailman/listinfo/python-legal-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben+python at benfinney.id.au Mon Dec 15 08:02:05 2014 From: ben+python at benfinney.id.au (Ben Finney) Date: Mon, 15 Dec 2014 18:02:05 +1100 Subject: [Python-legal-sig] Portable code: __import__ demands different string types between 2 and 3 References: <85lhm9cwyi.fsf@benfinney.id.au> Message-ID: <858ui9cs5u.fsf@benfinney.id.au> Alex Gaynor writes: > Was sending this to legal-sig a mistake? Yes, I apologise. Thanks for asking :-) -- \ ?What you have become is the price you paid to get what you | `\ used to want.? ?Mignon McLaughlin | _o__) | Ben Finney