Python 3.3 port of zope.configuration
Hi, I'd like to merge 2 branches which get zope.configuration's tests running on Python 3.3. Here is an overview (with patches attached): zope.schema: * svn+ssh://svn.zope.org/repos/main/zope.schema/branches/jinty-native_string * This branch corrects a mistake I think I made in the zope.schema Python3 port. After my experience with the zope.configuration port I now think that the URI field should be a "native" string rather than bytes. Unfortunately this change is backwards incompatible for Python 3 users of zope.schema. But I think the number users of zope.schema under Python 3 are rather small at this point. * I make public NativeString and NativeStringLine classes. These are equivalent to the Bytes type under Python 2 and the Text type under Python 3. Please devote some bikeshedding energy to better names for these classes ;) zope.configuration: * svn+ssh://svn.zope.org/repos/main/zope.configuration/branches/jinty-python3 * Adds a dependency on six * Drops Python 2.4 and 2.5 compatibility To run the tests of the zope.configuration branch you currently need to use the zope.interface trunk. If there are no objections, I'll merge in a few weeks or so. -- Brian Sutherland
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/11/2012 03:57 AM, Brian Sutherland wrote:
Hi,
I'd like to merge 2 branches which get zope.configuration's tests running on Python 3.3. Here is an overview (with patches attached):
zope.schema:
* svn+ssh://svn.zope.org/repos/main/zope.schema/branches/jinty-native_string
* This branch corrects a mistake I think I made in the zope.schema Python3 port. After my experience with the zope.configuration port I now think that the URI field should be a "native" string rather than bytes.
Unfortunately this change is backwards incompatible for Python 3 users of zope.schema. But I think the number users of zope.schema under Python 3 are rather small at this point.
* I make public NativeString and NativeStringLine classes. These are equivalent to the Bytes type under Python 2 and the Text type under Python 3. Please devote some bikeshedding energy to better names for these classes ;)
zope.configuration:
* svn+ssh://svn.zope.org/repos/main/zope.configuration/branches/jinty-python3
* Adds a dependency on six
* Drops Python 2.4 and 2.5 compatibility
To run the tests of the zope.configuration branch you currently need to use the zope.interface trunk.
If there are no objections, I'll merge in a few weeks or so.
How deep is the six dependency? For every package I've ported to date, it has ended up being more sensible to implement a local '_compat' module which had only the needed straddles (sometimes inspired by six, sometimes very localized). Also, do your branches still pass tests on 3.2.x? I'm sort of keen to see both zope.schema and zope.configuration join the "2to3-free" camp with zope.event, zope.interface, zope.i18nmessageid, and zope.exceptions (yes, zope.configuration, I'm looking at you next). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+HZ0oACgkQ+gerLs4ltQ4X/QCgm42Ky292CooBModA8nrkdKI2 yhAAoMa69RUXaTKlF0lKMjDdhOmrik4j =E0P1 -----END PGP SIGNATURE-----
On Fri, Apr 13, 2012 at 01:37, Tres Seaver <tseaver@palladion.com> wrote:
How deep is the six dependency? For every package I've ported to date, it has ended up being more sensible to implement a local '_compat' module which had only the needed straddles (sometimes inspired by six, sometimes very localized).
You can also just copy six.py into the module and use it from there. That way it's not an external dependency any more. //Lennart
On Thu, Apr 12, 2012 at 7:37 PM, Tres Seaver <tseaver@palladion.com> wrote: ...
How deep is the six dependency? For every package I've ported to date, it has ended up being more sensible to implement a local '_compat' module which had only the needed straddles (sometimes inspired by six, sometimes very localized).
I can see why this might be sensible in the small, or for packages that really have to minimize dependencies (like buildout), but in the large, this sounds like a huge DRY violation. If we all adopt a 2&3 strategy, then six should be a given and not even count as a dependency. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://www.dublinstore.com/
On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/11/2012 03:57 AM, Brian Sutherland wrote:
Hi,
I'd like to merge 2 branches which get zope.configuration's tests running on Python 3.3. Here is an overview (with patches attached):
zope.schema:
* svn+ssh://svn.zope.org/repos/main/zope.schema/branches/jinty-native_string
* This branch corrects a mistake I think I made in the zope.schema Python3 port. After my experience with the zope.configuration port I now think that the URI field should be a "native" string rather than bytes.
Unfortunately this change is backwards incompatible for Python 3 users of zope.schema. But I think the number users of zope.schema under Python 3 are rather small at this point.
* I make public NativeString and NativeStringLine classes. These are equivalent to the Bytes type under Python 2 and the Text type under Python 3. Please devote some bikeshedding energy to better names for these classes ;)
zope.configuration:
* svn+ssh://svn.zope.org/repos/main/zope.configuration/branches/jinty-python3
* Adds a dependency on six
* Drops Python 2.4 and 2.5 compatibility
To run the tests of the zope.configuration branch you currently need to use the zope.interface trunk.
If there are no objections, I'll merge in a few weeks or so.
How deep is the six dependency? For every package I've ported to date, it has ended up being more sensible to implement a local '_compat' module which had only the needed straddles (sometimes inspired by six, sometimes very localized).
I'm sure you can get away without it. But having functions from six copied into huge numbers of zope.* packages made my skin crawl. As Jim said "a huge DRY violation".
Also, do your branches still pass tests on 3.2.x?
Yes for zope.schema No for zope.configuration, but that can be fixed by changing u'' to u('') in a lot of places.
I'm sort of keen to see both zope.schema and zope.configuration join the "2to3-free" camp
zope.schema's already there, my branch is only fixing what I consider to be a bug in the Python 3 port.
with zope.event, zope.interface, zope.i18nmessageid, and zope.exceptions (yes, zope.configuration, I'm looking at you next).
-- Brian Sutherland
On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote:
Also, do your branches still pass tests on 3.2.x? I'm sort of keen to see both zope.schema and zope.configuration join the "2to3-free" camp with zope.event, zope.interface, zope.i18nmessageid, and zope.exceptions (yes, zope.configuration, I'm looking at you next).
I see you've started doing this in a better and more rigorous way than I was. So I'm going to abandon my plans to merge in favour of your branches. I'd still urge you to have a look at my zope.schema branch, which I think solves a real problem with URI fields and Python 3. The patch is pretty small. -- Brian Sutherland
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/26/2012 04:39 AM, Brian Sutherland wrote:
On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote:
Also, do your branches still pass tests on 3.2.x? I'm sort of keen to see both zope.schema and zope.configuration join the "2to3-free" camp with zope.event, zope.interface, zope.i18nmessageid, and zope.exceptions (yes, zope.configuration, I'm looking at you next).
I see you've started doing this in a better and more rigorous way than I was. So I'm going to abandon my plans to merge in favour of your branches.
I'd still urge you to have a look at my zope.schema branch, which I think solves a real problem with URI fields and Python 3. The patch is pretty small.
My zope.schema branch is largely focused on improving the unittest coverage, while also making the package work with Python 3.2 (i.e., not relying on 3.3's restoration of unicode literals). I would be glad to look at your branch; I had already considered making the "native string" fields APIs. I'm not sure that I agree that the ASCII / URI / Id / DottedName fields should have native string as its type: can you help by elaborating there? (Also, looks like we should promote the 'INativeString' interface to an API). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ZcnUACgkQ+gerLs4ltQ4BWgCg0YOBWiGBJt8UIgBYG1F/sqsh qqoAoI6H77dS3EOOYFnOiQgEP6jddsNB =0Xwc -----END PGP SIGNATURE-----
On Thu, Apr 26, 2012 at 12:06:13PM -0400, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/26/2012 04:39 AM, Brian Sutherland wrote:
On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote:
Also, do your branches still pass tests on 3.2.x? I'm sort of keen to see both zope.schema and zope.configuration join the "2to3-free" camp with zope.event, zope.interface, zope.i18nmessageid, and zope.exceptions (yes, zope.configuration, I'm looking at you next).
I see you've started doing this in a better and more rigorous way than I was. So I'm going to abandon my plans to merge in favour of your branches.
I'd still urge you to have a look at my zope.schema branch, which I think solves a real problem with URI fields and Python 3. The patch is pretty small.
My zope.schema branch is largely focused on improving the unittest coverage, while also making the package work with Python 3.2 (i.e., not relying on 3.3's restoration of unicode literals).
I would be glad to look at your branch; I had already considered making the "native string" fields APIs. I'm not sure that I agree that the ASCII / URI / Id / DottedName fields should have native string as its type: can you help by elaborating there?
For DottedName we're basically forced to use native strings as you can import modules with unicode names on python 3: >>> from 漢語 import Español >>> print(Español) <class '漢語.Español'> Id is either a URI or a DottedName. So it must, like DottedName, also be a native string. As for URI, python 3 library functions seem to not care, so we can choose either: >>> from urllib.parse import urlparse >>> urlparse('http://www.example.com/unicode') ParseResult(scheme='http', netloc='www.example.com', path='/unicode', params='', query='', fragment='') >>> urlparse(b'http://www.example.com/bytes') ParseResultBytes(scheme=b'http', netloc=b'www.example.com', path=b'/bytes', params=b'', query=b'', fragment=b'') But, for consistency's sake, URI, Id and DottedName should be the same. That makes the best choice for URI a native string. Another more practical argument is that having URI be a "native string" made the porting of zope.configuration to python 3 much easier. There were a few nasty bugs when trying it with URI as bytes. I have no strong argument for ASCII. FWIW, here's the original discussion on porting zope.schema: https://mail.zope.org/pipermail/zope-dev/2011-October/043540.html
(Also, looks like we should promote the 'INativeString' interface to an API).
+1
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+ZcnUACgkQ+gerLs4ltQ4BWgCg0YOBWiGBJt8UIgBYG1F/sqsh qqoAoI6H77dS3EOOYFnOiQgEP6jddsNB =0Xwc -----END PGP SIGNATURE-----
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
-- Brian Sutherland
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/26/2012 01:50 PM, Brian Sutherland wrote:
On Thu, Apr 26, 2012 at 12:06:13PM -0400, Tres Seaver wrote: On 04/26/2012 04:39 AM, Brian Sutherland wrote:
On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote:
Also, do your branches still pass tests on 3.2.x? I'm sort of keen to see both zope.schema and zope.configuration join the "2to3-free" camp with zope.event, zope.interface, zope.i18nmessageid, and zope.exceptions (yes, zope.configuration, I'm looking at you next).
I see you've started doing this in a better and more rigorous way than I was. So I'm going to abandon my plans to merge in favour of your branches.
I'd still urge you to have a look at my zope.schema branch, which I think solves a real problem with URI fields and Python 3. The patch is pretty small.
My zope.schema branch is largely focused on improving the unittest coverage, while also making the package work with Python 3.2 (i.e., not relying on 3.3's restoration of unicode literals).
I would be glad to look at your branch; I had already considered making the "native string" fields APIs. I'm not sure that I agree that the ASCII / URI / Id / DottedName fields should have native string as its type: can you help by elaborating there?
For DottedName we're basically forced to use native strings as you can import modules with unicode names on python 3:
from 漢語 import Español print(Español) <class '漢語.Español'>
Id is either a URI or a DottedName. So it must, like DottedName, also be a native string.
As for URI, python 3 library functions seem to not care, so we can choose either:
from urllib.parse import urlparse urlparse('http://www.example.com/unicode') ParseResult(scheme='http', netloc='www.example.com', path='/unicode', params='', query='', fragment='') urlparse(b'http://www.example.com/bytes') ParseResultBytes(scheme=b'http', netloc=b'www.example.com', path=b'/bytes', params=b'', query=b'', fragment=b'')
But, for consistency's sake, URI, Id and DottedName should be the same. That makes the best choice for URI a native string.
Another more practical argument is that having URI be a "native string" made the porting of zope.configuration to python 3 much easier. There were a few nasty bugs when trying it with URI as bytes.
I have no strong argument for ASCII.
FWIW, here's the original discussion on porting zope.schema: https://mail.zope.org/pipermail/zope-dev/2011-October/043540.html
Thanks very much for the explanation. I will plan to merge in your changes in my branch ASAP. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ZlUoACgkQ+gerLs4ltQ7HkwCfetRH32lexokm3HcnBr1WqQNO UtIAn1IXq0GTF8BJw5xIm/F76qjZEuwn =QU44 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/26/2012 02:34 PM, Tres Seaver wrote:
On 04/26/2012 01:50 PM, Brian Sutherland wrote:
On Thu, Apr 26, 2012 at 12:06:13PM -0400, Tres Seaver wrote: On 04/26/2012 04:39 AM, Brian Sutherland wrote:
On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote:
Also, do your branches still pass tests on 3.2.x? I'm sort of keen to see both zope.schema and zope.configuration join the "2to3-free" camp with zope.event, zope.interface, zope.i18nmessageid, and zope.exceptions (yes, zope.configuration, I'm looking at you next).
I see you've started doing this in a better and more rigorous way than I was. So I'm going to abandon my plans to merge in favour of your branches.
I'd still urge you to have a look at my zope.schema branch, which I think solves a real problem with URI fields and Python 3. The patch is pretty small.
My zope.schema branch is largely focused on improving the unittest coverage, while also making the package work with Python 3.2 (i.e., not relying on 3.3's restoration of unicode literals).
I would be glad to look at your branch; I had already considered making the "native string" fields APIs. I'm not sure that I agree that the ASCII / URI / Id / DottedName fields should have native string as its type: can you help by elaborating there?
For DottedName we're basically forced to use native strings as you can import modules with unicode names on python 3:
from 漢語 import Español print(Español) <class '漢語.Español'>
Id is either a URI or a DottedName. So it must, like DottedName, also be a native string.
As for URI, python 3 library functions seem to not care, so we can choose either:
from urllib.parse import urlparse urlparse('http://www.example.com/unicode') ParseResult(scheme='http', netloc='www.example.com', path='/unicode', params='', query='', fragment='') urlparse(b'http://www.example.com/bytes') ParseResultBytes(scheme=b'http', netloc=b'www.example.com', path=b'/bytes', params=b'', query=b'', fragment=b'')
But, for consistency's sake, URI, Id and DottedName should be the same. That makes the best choice for URI a native string.
Another more practical argument is that having URI be a "native string" made the porting of zope.configuration to python 3 much easier. There were a few nasty bugs when trying it with URI as bytes.
I have no strong argument for ASCII.
FWIW, here's the original discussion on porting zope.schema: https://mail.zope.org/pipermail/zope-dev/2011-October/043540.html
Thanks very much for the explanation. I will plan to merge in your changes in my branch ASAP.
Done and merged to the trunk with my 'test_cleanup' branch. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+ka2EACgkQ+gerLs4ltQ4UjgCg2qs2NoRzM7jeqVC5NmrazM6H yE0AoMfp/F4CGS6n218E7a5Mheb1OaTB =fdQK -----END PGP SIGNATURE-----
On Fri, May 04, 2012 at 07:50:57PM -0400, Tres Seaver wrote:
On 04/26/2012 02:34 PM, Tres Seaver wrote:
On 04/26/2012 01:50 PM, Brian Sutherland wrote:
On Thu, Apr 26, 2012 at 12:06:13PM -0400, Tres Seaver wrote: On 04/26/2012 04:39 AM, Brian Sutherland wrote:
On Thu, Apr 12, 2012 at 07:37:46PM -0400, Tres Seaver wrote: > Also, do your branches still pass tests on 3.2.x? I'm sort > of keen to see both zope.schema and zope.configuration join > the "2to3-free" camp with zope.event, zope.interface, > zope.i18nmessageid, and zope.exceptions (yes, > zope.configuration, I'm looking at you next).
I see you've started doing this in a better and more rigorous way than I was. So I'm going to abandon my plans to merge in favour of your branches.
I'd still urge you to have a look at my zope.schema branch, which I think solves a real problem with URI fields and Python 3. The patch is pretty small.
My zope.schema branch is largely focused on improving the unittest coverage, while also making the package work with Python 3.2 (i.e., not relying on 3.3's restoration of unicode literals).
I would be glad to look at your branch; I had already considered making the "native string" fields APIs. I'm not sure that I agree that the ASCII / URI / Id / DottedName fields should have native string as its type: can you help by elaborating there?
For DottedName we're basically forced to use native strings as you can import modules with unicode names on python 3:
> from 漢語 import Español print(Español) <class '漢語.Español'>
Id is either a URI or a DottedName. So it must, like DottedName, also be a native string.
As for URI, python 3 library functions seem to not care, so we can choose either:
> from urllib.parse import urlparse > urlparse('http://www.example.com/unicode') ParseResult(scheme='http', netloc='www.example.com', path='/unicode', params='', query='', fragment='') > urlparse(b'http://www.example.com/bytes') ParseResultBytes(scheme=b'http', netloc=b'www.example.com', path=b'/bytes', params=b'', query=b'', fragment=b'')
But, for consistency's sake, URI, Id and DottedName should be the same. That makes the best choice for URI a native string.
Another more practical argument is that having URI be a "native string" made the porting of zope.configuration to python 3 much easier. There were a few nasty bugs when trying it with URI as bytes.
I have no strong argument for ASCII.
FWIW, here's the original discussion on porting zope.schema: https://mail.zope.org/pipermail/zope-dev/2011-October/043540.html
Thanks very much for the explanation. I will plan to merge in your changes in my branch ASAP.
Done and merged to the trunk with my 'test_cleanup' branch.
Looks great, thanks! -- Brian Sutherland
participants (4)
-
Brian Sutherland -
Jim Fulton -
Lennart Regebro -
Tres Seaver