Re: How to define a bytes literal in Python 2.x for porting to Python 3.x using 2to3?
Terry Reedy
> Is there a way to mark string literals so that 2to3 automatically
> prefixes them with 'b'? Is there a simpler trick?
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> b=b'abc'
>>> b
'abc'
The b prefix does nothing in 2.7. It was specifically added for this
type of porting problem.
--
Terry Jan Reedy
Stefan Behnel
More precisely, it was added in Python 2.6, so older Python versions will
consider it a syntax error.
To support older Python versions, you need to write your own wrapper
functions for bytes literals that do nothing in Python 2 and convert the
literal back to a bytes literal in Python 3. That's ugly, but there's no
other way to do it.
Stefan
Terry Reedy
> Terry Reedy, 01.01.2011 11:08:
>> On 1/1/2011 4:08 AM, Baptiste Lepilleur wrote:
>>
>>> Is there a way to mark string literals so that 2to3 automatically
>>> prefixes them with 'b'? Is there a simpler trick?
>>
>> Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
>> (Intel)] on win32
>> Type "copyright", "credits" or "license()" for more information.
>> >>> b=b'abc'
>> >>> b
>> 'abc'
>>
>> The b prefix does nothing in 2.7. It was specifically added for this type
>> of porting problem.
>
> More precisely, it was added in Python 2.6, so older Python versions
> will consider it a syntax error.
'so' here means 'as a consequence' rather than 'with the intention' ;-).
> To support older Python versions, you need to write your own wrapper
> functions for bytes literals that do nothing in Python 2 and convert the
> literal back to a bytes literal in Python 3. That's ugly, but there's no
> other way to do it.
I think the developers expected that most maintained and updated 2.x
code, especially code targeted at 3.x also, would be migrated to 2.6+.
--
Terry Jan Reedy
Martin v. Loewis
>> functions for bytes literals that do nothing in Python 2 and convert the
>> literal back to a bytes literal in Python 3. That's ugly, but there's no
>> other way to do it.
>
> I think the developers expected that most maintained and updated 2.x
> code, especially code targeted at 3.x also, would be migrated to 2.6+.
Unfortunately, that assumption has hurt Python 3 migration
significantly. It gave the impression that, as long as you need to
support Python 2.5 and earlier, there is no way you could possibly
support Python 3 as well, and that, therefore, starting to support
Python 3 is pointless for many years to come.
I personally never shared that assumption, and encourage people to
ignore these gimmicks that had been added to 2.6 to ease porting.
Instead, people should first determine what Python versions their
users want to see supported, and then look for solutions that cover
all these versions.
In the case of byte literals, the solution is fairly straight-forward,
and only moderately ugly.
Regards,
Martin
Terry Reedy
>> I think the developers expected that most maintained and updated 2.x
>> code, especially code targeted at 3.x also, would be migrated to 2.6+.
>
> Unfortunately, that assumption has hurt Python 3 migration
> significantly. It gave the impression that, as long as you need to
> support Python 2.5 and earlier, there is no way you could possibly
> support Python 3 as well, and that, therefore, starting to support
> Python 3 is pointless for many years to come.
>
> I personally never shared that assumption, and encourage people to
> ignore these gimmicks that had been added to 2.6 to ease porting.
> Instead, people should first determine what Python versions their
> users want to see supported, and then look for solutions that cover
> all these versions.
You have shown that it is easier than some people thought. I think two
key ideas are these.
1. Code running in multiple versions has to be syntactically correct in
every detail all versions in order to be compiled without error.
However, version specific syntax *can* be used in modules that are
conditionally imported and therefore conditionally compiled and executed.
2. The syntax of function calls has hardly changed and using the common
subset is no limitation for the overwhelming majority of uses. Moreover,
function names can be conditionally bound to version-specific function
objects, whether builtin or imported.
--
Terry Jan Reedy
Martin v. Loewis
> every detail all versions in order to be compiled without error.
> However, version specific syntax *can* be used in modules that are
> conditionally imported and therefore conditionally compiled and executed.
I also encourage people to use 2to3. Then this requirement (must be
syntactically correct in all Python versions) goes away: it is ok to
write source that doesn't compile on Python 3, and still *run* it
on Python 3.
OTOH, writing code that only supports newer 2.x versions isn't helped
by 2to3, so compatibility within 2.x is more important to consider than
compatibility between 2.x and 3.x.
Regards,
Martin
Stefan Behnel
> 1. Code running in multiple versions has to be syntactically correct in
> every detail all versions in order to be compiled without error. However,
> version specific syntax *can* be used in modules that are conditionally
> imported and therefore conditionally compiled and executed.
This is something that might also be a suitable solution for the OP's
problem. The format strings can be by externalised into an importable
module, which can then be duplicated to use the 'b' bytes prefix for Python 3.
The obvious drawback is that this moves the strings out of the immediate
sight of someone reading the sources, and that it requires the two string
modules to be kept in sync. But at least for the synchronisation, a
simplistic conversion tool run during installation could do the trick.
Stefan