From regebro at gmail.com Sun Jan 4 12:21:36 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 4 Jan 2009 12:21:36 +0100
Subject: [Python-porting] Some suggested 2to3 patches
Message-ID: <319e029f0901040321q7f016fc6l75af4e61aa7c3a87@mail.gmail.com>
When trying to port setuptools, I found some things I think are bugs,
missing library reorganisation fixes more specifically.
Firstly, there are a lot of things missing from the urllib fixer, most
significantly all the split* methods. Secondly, htmlentitydefs has
moved, and this doesn't seem to be handled.
Am I correct that these are bugs, or should something else be done? A
suggested patch is included, although I haven't made any tests for it,
I wanted to check here first.
--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2to3.diff
Type: text/x-patch
Size: 1834 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-porting/attachments/20090104/36c17d6f/attachment.bin>
From benjamin at python.org Sun Jan 4 19:29:21 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 4 Jan 2009 12:29:21 -0600
Subject: [Python-porting] Some suggested 2to3 patches
In-Reply-To: <319e029f0901040321q7f016fc6l75af4e61aa7c3a87@mail.gmail.com>
References: <319e029f0901040321q7f016fc6l75af4e61aa7c3a87@mail.gmail.com>
Message-ID: <1afaf6160901041029y23a3e762md94379a2ddd0c88a@mail.gmail.com>
On Sun, Jan 4, 2009 at 5:21 AM, Lennart Regebro <regebro at gmail.com> wrote:
> When trying to port setuptools, I found some things I think are bugs,
> missing library reorganisation fixes more specifically.
Thanks for your report!
>
> Firstly, there are a lot of things missing from the urllib fixer, most
> significantly all the split* methods. Secondly, htmlentitydefs has
> moved, and this doesn't seem to be handled.
>
> Am I correct that these are bugs, or should something else be done? A
> suggested patch is included, although I haven't made any tests for it,
> I wanted to check here first.
Yes, those are bugs. The htmlentitydefs problem is already fixed in
the trunk. I fixed the url parsing functions bug in r68306.
--
Regards,
Benjamin
From regebro at gmail.com Mon Jan 5 01:20:32 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 5 Jan 2009 01:20:32 +0100
Subject: [Python-porting] Some suggested 2to3 patches
In-Reply-To: <1afaf6160901041029y23a3e762md94379a2ddd0c88a@mail.gmail.com>
References: <319e029f0901040321q7f016fc6l75af4e61aa7c3a87@mail.gmail.com>
<1afaf6160901041029y23a3e762md94379a2ddd0c88a@mail.gmail.com>
Message-ID: <319e029f0901041620x2388acend19f2c283e0b8108@mail.gmail.com>
Cool, thanks!
On Sun, Jan 4, 2009 at 19:29, Benjamin Peterson <benjamin at python.org> wrote:
> On Sun, Jan 4, 2009 at 5:21 AM, Lennart Regebro <regebro at gmail.com> wrote:
>> When trying to port setuptools, I found some things I think are bugs,
>> missing library reorganisation fixes more specifically.
>
> Thanks for your report!
>
>>
>> Firstly, there are a lot of things missing from the urllib fixer, most
>> significantly all the split* methods. Secondly, htmlentitydefs has
>> moved, and this doesn't seem to be handled.
>>
>> Am I correct that these are bugs, or should something else be done? A
>> suggested patch is included, although I haven't made any tests for it,
>> I wanted to check here first.
>
> Yes, those are bugs. The htmlentitydefs problem is already fixed in
> the trunk. I fixed the url parsing functions bug in r68306.
>
>
>
> --
> Regards,
> Benjamin
>
--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
From regebro at gmail.com Mon Jan 5 14:27:13 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 5 Jan 2009 14:27:13 +0100
Subject: [Python-porting] Porting and doctests
Message-ID: <319e029f0901050527k433cbdecr6596565a1bbb4abf@mail.gmail.com>
I've encountered two problems concerning doctests, which I nowadays
therefore like even less than before. ;-)
Problem number one:
When raising exceptions under 2.x, the last line of the error message
will look something like this:
ExceptionClass: The message
But under 3.0 it will look thusly:
module.ExceptionClass: The message
This means that the typical doctest pattern of:
Traceback (most recent call last):
...
ExceptionClass: The message
will fail. And I haven't been able to make a pattern that will work.
Sticking ... in front of ExceptionClass doesn't. What is the best way
to get around this? I could to a try/except in the doc test code and
raise an assertion error of the exception is not raised, but that's
UGLY.
Problem number two:
When porting iCalendar, the UTF-8 encoded data that should be returned
for interchange will be a string in Python2, but bytes in Python3.
Hence,
>>> foo()
"bar"
Will fail becuase in Python 3 it should be:
>>> foo()
b"bar"
I haven't found any reasonable way around that, making support for 2.5
and 3.0 from the same code base (even with 2to3) impossible.
Any ideas?
--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
From ajaksu at gmail.com Mon Jan 5 18:41:19 2009
From: ajaksu at gmail.com (Daniel (ajax) Diniz)
Date: Mon, 5 Jan 2009 15:41:19 -0200
Subject: [Python-porting] Porting and doctests
In-Reply-To: <319e029f0901050527k433cbdecr6596565a1bbb4abf@mail.gmail.com>
References: <319e029f0901050527k433cbdecr6596565a1bbb4abf@mail.gmail.com>
Message-ID: <2d75d7660901050941h6828e390we532c635a01afbc5@mail.gmail.com>
(forgot to Cc the list, and tested with 3.0)
Hi Lennart :)
Lennart Regebro wrote:
> When raising exceptions under 2.x, the last line of the error message
> will look something like this:
>
> ExceptionClass: The message
>
> But under 3.0 it will look thusly:
>
> module.ExceptionClass: The message
I've used "from module import ExceptionClass" in a similar case (for
matching in a except clause, perhaps?).
> When porting iCalendar, the UTF-8 encoded data that should be returned
> for interchange will be a string in Python2, but bytes in Python3.
> Hence,
>
>>>> foo()
> "bar"
>
> Will fail becuase in Python 3 it should be:
>>>> foo()
> b"bar"
I don't have 3.0 installed in this machine yet, but I believe
foo().encode('utf-8') should work. -> Doesn't work :)
But str(foo().decode('utf-8')) seems to work.
HTH,
Daniel
From regebro at gmail.com Mon Jan 5 19:27:54 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 5 Jan 2009 19:27:54 +0100
Subject: [Python-porting] Porting and doctests
In-Reply-To: <2d75d7660901050916n41e633a1i3c0e57423490c4c8@mail.gmail.com>
References: <319e029f0901050527k433cbdecr6596565a1bbb4abf@mail.gmail.com>
<2d75d7660901050916n41e633a1i3c0e57423490c4c8@mail.gmail.com>
Message-ID: <319e029f0901051027i54c367bh950abe1bdb7d5670@mail.gmail.com>
On Mon, Jan 5, 2009 at 18:16, Daniel (ajax) Diniz <ajaksu at gmail.com> wrote:
> Hi Lennart :)
>
> Lennart Regebro wrote:
>> When raising exceptions under 2.x, the last line of the error message
>> will look something like this:
>>
>> ExceptionClass: The message
>>
>> But under 3.0 it will look thusly:
>>
>> module.ExceptionClass: The message
>
> I've used "from module import ExceptionClass" in a similar case (for
> matching in a except clause, perhaps?).
>
>> When porting iCalendar, the UTF-8 encoded data that should be returned
>> for interchange will be a string in Python2, but bytes in Python3.
>> Hence,
>>
>>>>> foo()
>> "bar"
>>
>> Will fail becuase in Python 3 it should be:
>>>>> foo()
>> b"bar"
>
> I don't have 3.0 installed in this machine yet, but I believe
> foo().encode('utf-8') should work.
I seem to have explained my problems badly, as none of this answers
the questions.
My problem is that I can't write doctests that will run both under
Python 2 and Python3, because of the above mentioned changes in
behaviour, and I wonder if somebody has any hints on how to help with
that.
--
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64
From stargaming at gmail.com Tue Jan 6 19:24:24 2009
From: stargaming at gmail.com (Robert Lehmann)
Date: Tue, 6 Jan 2009 18:24:24 +0000 (UTC)
Subject: [Python-porting] Some suggested 2to3 patches
References: <319e029f0901040321q7f016fc6l75af4e61aa7c3a87@mail.gmail.com>
Message-ID: <gk07ko$3bb$1@ger.gmane.org>
On Sun, 04 Jan 2009 12:21:36 +0100, Lennart Regebro wrote:
> - 'urlencode', 'pahtname2url', 'url2pathname']),
> + 'urlencode', 'pahtname2url', 'url2pathname', 'splitattr',
I suspect the second member is supposed to be pa*th*name2url (not *paht*).
It ended up that way in fixes/fix_urllib.py:18.
--
Robert "Stargaming" Lehmann
From benjamin at python.org Wed Jan 7 00:56:35 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Tue, 6 Jan 2009 17:56:35 -0600
Subject: [Python-porting] Some suggested 2to3 patches
In-Reply-To: <gk07ko$3bb$1@ger.gmane.org>
References: <319e029f0901040321q7f016fc6l75af4e61aa7c3a87@mail.gmail.com>
<gk07ko$3bb$1@ger.gmane.org>
Message-ID: <1afaf6160901061556na56329ck4df84346b27fa290@mail.gmail.com>
On Tue, Jan 6, 2009 at 12:24 PM, Robert Lehmann <stargaming at gmail.com> wrote:
> On Sun, 04 Jan 2009 12:21:36 +0100, Lennart Regebro wrote:
>
>> - 'urlencode', 'pahtname2url', 'url2pathname']),
>> + 'urlencode', 'pahtname2url', 'url2pathname', 'splitattr',
>
> I suspect the second member is supposed to be pa*th*name2url (not *paht*).
> It ended up that way in fixes/fix_urllib.py:18.
Good catch! Fixed in r68368.
--
Regards,
Benjamin
From mailinglists.bleiner at gmail.com Tue Jan 20 00:50:43 2009
From: mailinglists.bleiner at gmail.com (Bernhard Leiner)
Date: Tue, 20 Jan 2009 00:50:43 +0100
Subject: [Python-porting] porting builtin file type to python3
Message-ID: <545b18da0901191550v4a47d25diab286760746b0b77@mail.gmail.com>
Hi,
I have a custom file type that looks more or less like this:
class myfile(file):
def __init__(self, name, mode):
super(myfile, self).__init__(name, mode)
self.write('file header...\n')
And I'm pretty sure that porting this class to python3 will result in
something like:
import io
class myfile(io.FileIO):
def __init__(self, name, mode):
super(myfile, self).__init__(name, mode)
self.write('file header...\n')
The problem that I'm facing now is that the 2to3 script does not find
anything to convert. (I'm also surprised, that running the original
code with "python2.6 -3" does not result in a warning.)
What is the best way to alter my original script to keep it compatible
with python 2.x and get an equivalent python3 script after running
2to3?
thanks a lot,
bernhard
--
Bernhard Leiner http://bernh.net
From sjmachin at lexicon.net Tue Jan 20 01:38:16 2009
From: sjmachin at lexicon.net (John Machin)
Date: Tue, 20 Jan 2009 11:38:16 +1100
Subject: [Python-porting] porting builtin file type to python3
In-Reply-To: <545b18da0901191550v4a47d25diab286760746b0b77@mail.gmail.com>
References: <545b18da0901191550v4a47d25diab286760746b0b77@mail.gmail.com>
Message-ID: <49751CF8.8040805@lexicon.net>
On 20/01/2009 10:50 AM, Bernhard Leiner wrote:
> Hi,
>
> I have a custom file type that looks more or less like this:
>
> class myfile(file):
>
> def __init__(self, name, mode):
> super(myfile, self).__init__(name, mode)
> self.write('file header...\n')
>
> And I'm pretty sure that porting this class to python3 will result in
> something like:
>
> import io
>
> class myfile(io.FileIO):
>
> def __init__(self, name, mode):
> super(myfile, self).__init__(name, mode)
> self.write('file header...\n')
>
> The problem that I'm facing now is that the 2to3 script does not find
> anything to convert. (I'm also surprised, that running the original
> code with "python2.6 -3" does not result in a warning.)
>
> What is the best way to alter my original script to keep it compatible
> with python 2.x and get an equivalent python3 script after running
> 2to3?
>
2to3 and "python2.6 -3" can't handle everything. You'll need something
like the following, which seems to work with
2.5, 2.6, and 3.0 (win32 platform).
8<---
import sys
python_version = sys.version_info[:2]
if python_version >= (3, 0):
from io import FileIO as BUILTIN_FILE_TYPE
else:
BUILTIN_FILE_TYPE = file
class MyFile(BUILTIN_FILE_TYPE):
def __init__(self, name, mode):
super(MyFile, self).__init__(name, mode)
# maybe should test mode before writing :-)
self.write('file header...\n')
fname = "Bernhard%d%d.txt" % python_version
f = MyFile(fname, 'w')
f.write('foo bar zot\n')
f.close()
8<---
Cheers,
John
From benjamin at python.org Tue Jan 20 02:14:21 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 19 Jan 2009 19:14:21 -0600
Subject: [Python-porting] porting builtin file type to python3
In-Reply-To: <545b18da0901191550v4a47d25diab286760746b0b77@mail.gmail.com>
References: <545b18da0901191550v4a47d25diab286760746b0b77@mail.gmail.com>
Message-ID: <1afaf6160901191714k1c689743l211bc7b1500049e5@mail.gmail.com>
On Mon, Jan 19, 2009 at 5:50 PM, Bernhard Leiner
<mailinglists.bleiner at gmail.com> wrote:
> Hi,
>
> I have a custom file type that looks more or less like this:
>
> class myfile(file):
>
> def __init__(self, name, mode):
> super(myfile, self).__init__(name, mode)
> self.write('file header...\n')
>
> And I'm pretty sure that porting this class to python3 will result in
> something like:
>
> import io
>
> class myfile(io.FileIO):
>
> def __init__(self, name, mode):
> super(myfile, self).__init__(name, mode)
> self.write('file header...\n')
2to3 would be quite happy to convert use of the file class to
io.FileIO if this was the right thing to do in 99.8% of all cases.
However, in 3.0, IO has been restructured quite a bit, and FileIO is
just a bare bones binary reading and writing class. Therefore you will
have to do something like John suggested.
--
Regards,
Benjamin
From noctis.skytower at gmail.com Thu Jan 29 17:57:49 2009
From: noctis.skytower at gmail.com (Stephen Chappell)
Date: Thu, 29 Jan 2009 12:57:49 -0400
Subject: [Python-porting] 3rd Party Packages in Python 3.0
Message-ID: <1c5fc70b0901290857h4faddc5dr1699a01f3d8262b6@mail.gmail.com>
This looked like the best "forum" to ask this on, so here it goes.
Is there a list of third-party software/packages/modules that are
compatible with Python 3.0? Version 2.6 might be supported
better right now, but it would be nice to start developing and
porting over to 3.0. Without some needed dependencies external
to the main Python distribution, that can be rather difficult (others
are probably running into similar problems). Any help or list of
compatible packages would be greatly appreciated!
--
Consider, friend, as you pass by, as you are now, so once was I.
As I am now, you too shall be. Prepare, therefore, to follow me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-porting/attachments/20090129/0d44845f/attachment.htm>
From python at mikewatkins.ca Fri Jan 30 17:42:35 2009
From: python at mikewatkins.ca (Michael Watkins)
Date: Fri, 30 Jan 2009 08:42:35 -0800 (PST)
Subject: [Python-porting] 3rd Party Packages in Python 3.0
In-Reply-To: <1c5fc70b0901290857h4faddc5dr1699a01f3d8262b6@mail.gmail.com>
References: <1c5fc70b0901290857h4faddc5dr1699a01f3d8262b6@mail.gmail.com>
Message-ID: <1490.24.83.53.93.1233333755.squirrel@webmail.solutionroute.ca>
On Thu, January 29, 2009 8:57 am, Stephen Chappell wrote:
> This looked like the best "forum" to ask this on, so here it goes.
> Is there a list of third-party software/packages/modules that are
> compatible with Python 3.0?
Just browse the Python Package Index:
http://pypi.python.org/pypi?:action=browse&c=533&show=all
From noctis.skytower at gmail.com Sat Jan 31 19:46:33 2009
From: noctis.skytower at gmail.com (Stephen Chappell)
Date: Sat, 31 Jan 2009 14:46:33 -0400
Subject: [Python-porting] 3rd Party Packages in Python 3.0
In-Reply-To: <1490.24.83.53.93.1233333755.squirrel@webmail.solutionroute.ca>
References: <1c5fc70b0901290857h4faddc5dr1699a01f3d8262b6@mail.gmail.com>
<1490.24.83.53.93.1233333755.squirrel@webmail.solutionroute.ca>
Message-ID: <1c5fc70b0901311046m5a8921e9oeb8f901941510d91@mail.gmail.com>
Thanks a lot! I did not know that there were subcategories there. [?]
On Fri, Jan 30, 2009 at 12:42 PM, Michael Watkins <python at mikewatkins.ca>wrote:
> On Thu, January 29, 2009 8:57 am, Stephen Chappell wrote:
> > This looked like the best "forum" to ask this on, so here it goes.
> > Is there a list of third-party software/packages/modules that are
> > compatible with Python 3.0?
>
> Just browse the Python Package Index:
>
> http://pypi.python.org/pypi?:action=browse&c=533&show=all
>
>
>
--
Consider, friend, as you pass by, as you are now, so once was I.
As I am now, you too shall be. Prepare, therefore, to follow me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-porting/attachments/20090131/1c546373/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 104 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-porting/attachments/20090131/1c546373/attachment.gif>