Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?)

 

 

Python dev RSS feed   Index | Next | Previous | View Threaded


ncoghlan at gmail

Nov 4, 2009, 4:00 AM

Post #1 of 8 (153 views)
Permalink
Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?)

Lennart Regebro wrote:
> I also would really like to see a real port of the bytes class to 2.6,
> but I have a vague memory that there was some reason that wouldn't
> work.

Not so much that it wouldn't work, but that the interfaces to support
using it effectively really aren't there - lots of areas in the standard
library needed to be tweaked to cope with bytes objects in 3.x.

Generally speaking, the "bytes = str" trick represents a reasonable
compromise as the APIs that you would pass a bytes object to in 3.x
expect an 8-bit str instance in 2.x.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan[at]gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


mal at egenix

Nov 4, 2009, 4:21 AM

Post #2 of 8 (140 views)
Permalink
Re: Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?) [In reply to]

Nick Coghlan wrote:
> Lennart Regebro wrote:
>> I also would really like to see a real port of the bytes class to 2.6,
>> but I have a vague memory that there was some reason that wouldn't
>> work.
>
> Not so much that it wouldn't work, but that the interfaces to support
> using it effectively really aren't there - lots of areas in the standard
> library needed to be tweaked to cope with bytes objects in 3.x.
>
> Generally speaking, the "bytes = str" trick represents a reasonable
> compromise as the APIs that you would pass a bytes object to in 3.x
> expect an 8-bit str instance in 2.x.

Could you please add such hints, tricks and tips to the wiki
page:

http://wiki.python.org/moin/PortingToPy3k

Thanks,
--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Nov 04 2009)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

Nov 4, 2009, 5:20 AM

Post #3 of 8 (140 views)
Permalink
Re: Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?) [In reply to]

M.-A. Lemburg wrote:
> Nick Coghlan wrote:
>> Lennart Regebro wrote:
>>> I also would really like to see a real port of the bytes class to 2.6,
>>> but I have a vague memory that there was some reason that wouldn't
>>> work.
>> Not so much that it wouldn't work, but that the interfaces to support
>> using it effectively really aren't there - lots of areas in the standard
>> library needed to be tweaked to cope with bytes objects in 3.x.
>>
>> Generally speaking, the "bytes = str" trick represents a reasonable
>> compromise as the APIs that you would pass a bytes object to in 3.x
>> expect an 8-bit str instance in 2.x.
>
> Could you please add such hints, tricks and tips to the wiki
> page:
>
> http://wiki.python.org/moin/PortingToPy3k

Done (although the task of figuring out how to get the wiki to display
code properly defeated me... the normal Python documentation syntax for
it seemed to give the wiki's ReST interpreter fits).

I also mentioned the trick someone mentioned about "from __future__
import unicode_literals" not changing the meaning of 'str' since it only
alters the parser but not the builtins.

In writing it up, it occurred to me that having that kind of thing in a
"py3_compat" compatibility module (to be used as, e.g., "from py3_compat
import str, bytes") would not only make it easier to use in multiple
modules, but also easier for 2to3 to remove when forward porting.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan[at]gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


martin at v

Nov 4, 2009, 10:37 AM

Post #4 of 8 (133 views)
Permalink
Re: Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?) [In reply to]

Nick Coghlan wrote:
> Lennart Regebro wrote:
>> I also would really like to see a real port of the bytes class to 2.6,
>> but I have a vague memory that there was some reason that wouldn't
>> work.
>
> Not so much that it wouldn't work, but that the interfaces to support
> using it effectively really aren't there - lots of areas in the standard
> library needed to be tweaked to cope with bytes objects in 3.x.

I see the problem differently: if a bytes type was added, nothing would
use it. In particular, IO wouldn't start returning bytes (although it
could accept them); IO would continue to return str. Therefore, I'm
skeptical that adding a *third* string type to 3.x would do any good.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


mal at egenix

Nov 5, 2009, 2:56 AM

Post #5 of 8 (127 views)
Permalink
Re: Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?) [In reply to]

Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>> Nick Coghlan wrote:
>>> Lennart Regebro wrote:
>>>> I also would really like to see a real port of the bytes class to 2.6,
>>>> but I have a vague memory that there was some reason that wouldn't
>>>> work.
>>> Not so much that it wouldn't work, but that the interfaces to support
>>> using it effectively really aren't there - lots of areas in the standard
>>> library needed to be tweaked to cope with bytes objects in 3.x.
>>>
>>> Generally speaking, the "bytes = str" trick represents a reasonable
>>> compromise as the APIs that you would pass a bytes object to in 3.x
>>> expect an 8-bit str instance in 2.x.
>>
>> Could you please add such hints, tricks and tips to the wiki
>> page:
>>
>> http://wiki.python.org/moin/PortingToPy3k
>
> Done (although the task of figuring out how to get the wiki to display
> code properly defeated me... the normal Python documentation syntax for
> it seemed to give the wiki's ReST interpreter fits).

Thanks.

> I also mentioned the trick someone mentioned about "from __future__
> import unicode_literals" not changing the meaning of 'str' since it only
> alters the parser but not the builtins.
>
> In writing it up, it occurred to me that having that kind of thing in a
> "py3_compat" compatibility module (to be used as, e.g., "from py3_compat
> import str, bytes") would not only make it easier to use in multiple
> modules, but also easier for 2to3 to remove when forward porting.

That would certainly be useful to have, yes, since all
developers wanting to support both 2.7 and 3.2 using the same
code base will have a need for these things.

It would also help to have a package that contains proxy modules
using the Python 3.x module/package names which map the functionality
back to the Python 2.x modules.

This avoids problems with freezing tools that scan the source
code for imports as well as pickles which store the full
dotted path name to classes.

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Nov 05 2009)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

Nov 5, 2009, 4:19 AM

Post #6 of 8 (127 views)
Permalink
Re: Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?) [In reply to]

Martin v. Löwis wrote:
> Nick Coghlan wrote:
>> Lennart Regebro wrote:
>>> I also would really like to see a real port of the bytes class to 2.6,
>>> but I have a vague memory that there was some reason that wouldn't
>>> work.
>> Not so much that it wouldn't work, but that the interfaces to support
>> using it effectively really aren't there - lots of areas in the standard
>> library needed to be tweaked to cope with bytes objects in 3.x.
>
> I see the problem differently: if a bytes type was added, nothing would
> use it. In particular, IO wouldn't start returning bytes (although it
> could accept them); IO would continue to return str. Therefore, I'm
> skeptical that adding a *third* string type to 3.x would do any good.

I'm guessing you meant '2.x' in that last sentence, in which case we
agree (just emphasising different parts of the "binary data" ecosystem
that would be necessary to make a backported bytes type effective).

Although I think Guido did a better job than either of us in explaining
why backporting the full bytes type to 2.x really wouldn't help all that
much.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan[at]gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


regebro at gmail

Nov 5, 2009, 12:36 PM

Post #7 of 8 (119 views)
Permalink
Re: Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?) [In reply to]

2009/11/4 Nick Coghlan <ncoghlan[at]gmail.com>:
> In writing it up, it occurred to me that having that kind of thing in a
> "py3_compat" compatibility module (to be used as, e.g., "from py3_compat
> import str, bytes") would not only make it easier to use in multiple
> modules, but also easier for 2to3 to remove when forward porting.

Well, when using 2to3 it already handles that stuff. But a module like
that would be very handy if you want to support both 2.6 and 3.x
without 2to3. With such a module it would be quite simple.

In fact, I think the module should be called "timemachine". ;-)

--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


regebro at gmail

Nov 5, 2009, 12:38 PM

Post #8 of 8 (119 views)
Permalink
Re: Py3k bytes type in 2.x (Re: nonlocal keyword in 2.x?) [In reply to]

2009/11/4 Nick Coghlan <ncoghlan[at]gmail.com>:
> Lennart Regebro wrote:
>> I also would really like to see a real port of the bytes class to 2.6,
>> but I have a vague memory that there was some reason that wouldn't
>> work.
>
> Not so much that it wouldn't work, but that the interfaces to support
> using it effectively really aren't there - lots of areas in the standard
> library needed to be tweaked to cope with bytes objects in 3.x.

Ah, right, that was the problem, the standard library. I knew I heard
a good reason against it.

> Generally speaking, the "bytes = str" trick represents a reasonable
> compromise as the APIs that you would pass a bytes object to in 3.x
> expect an 8-bit str instance in 2.x.

Yeah, the problem being that bytes and str has quite different API's. Ah well.

--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
_______________________________________________
Python-Dev mailing list
Python-Dev[at]python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.