Re: How to define a bytes literal in Python 2.x for porting to Python3.x using 2to3?

Discussion in 'Python' started by Terry Reedy, Jan 1, 2011.

  1. Terry Reedy

    Terry Reedy Guest

    On 1/1/2011 5:57 AM, Stefan Behnel wrote:
    > 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
     
    Terry Reedy, Jan 1, 2011
    #1
    1. Advertising

  2. >> 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+.


    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
     
    Martin v. Loewis, Jan 1, 2011
    #2
    1. Advertising

  3. Terry Reedy

    Terry Reedy Guest

    On 1/1/2011 5:07 PM, Martin v. Loewis wrote:

    >> 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
     
    Terry Reedy, Jan 1, 2011
    #3
  4. > 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.


    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
     
    Martin v. Loewis, Jan 1, 2011
    #4
  5. Terry Reedy, 01.01.2011 23:47:
    > 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
     
    Stefan Behnel, Jan 2, 2011
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nick Buchholz

    Problem porting class to python3.2

    Nick Buchholz, Jun 2, 2011, in forum: Python
    Replies:
    0
    Views:
    191
    Nick Buchholz
    Jun 2, 2011
  2. John Ladasky
    Replies:
    9
    Views:
    171
    John Ladasky
    Jul 27, 2013
  3. Mark Heieis
    Replies:
    0
    Views:
    102
    Mark Heieis
    Jan 11, 2014
  4. Stefan Behnel
    Replies:
    0
    Views:
    82
    Stefan Behnel
    Jan 11, 2014
  5. Mark Heieis
    Replies:
    0
    Views:
    71
    Mark Heieis
    Jan 18, 2014
Loading...

Share This Page