py3k s***s

[Gabriel Genellina]

On 16 abr, 09:56, Aaron Watters <aaron.watt... at gmail.com> wrote:

> In my opinion python's adherence to backwards compatibility
> has been a bit mythological anyway -- many new python versions
> have broken my old code for no good reason.  This is an irritant
> when you have thousands of users out there who suddenly drop
> your code, blame you and python, and move on to use something else.
> Honestly, how hard would it have been to provide standard backwards
> support for the old regex module as a standard module which simply
> translated one regex string format to another, for example?

Do you mean this?

py> import reconvert
py> help(reconvert)
Help on module reconvert:

NAME
    reconvert - Convert old ("regex") regular expressions to new
syntax ("re").

FILE
    c:\apps\python24\lib\reconvert.py

DESCRIPTION
    When imported as a module, there are two functions, with their own
    strings:

      convert(s, syntax=None) -- convert a regex regular expression to
re syntax

      quote(s) -- return a quoted string literal

    When used as a script, read a Python string literal (or any other
    expression evaluating to a string) from stdin, and write the
    translated expression to stdout as a string literal.  Unless
stdout is
    a tty, no trailing \n is written to stdout.  This is done so that
it
    can be used with Emacs C-U M-| (shell-command-on-region with
argument
    which filters the region through the shell command).

> What I'm saying is that, for example, there are a lot
> of cool tools out there for using Python to manipulate
> postscript and latex and such.  Most of those tools
> require no maintenance, and the authors are not paying
> any attention to them, and they aren't interested in
> messing with them anymore.

And they will continue to work using the Python version for which they
were designed, or even a later one; probably up to the last 2.x. Some
scripts designed for Python 1.x still work.
Really I don't feel the 3.0 incompatibilities are so big.

> My guess is that there are few
> such tools for Ruby.  However, I wouldn't be too
> surprised if porting them to Ruby and testing them
> properly is not much more difficult than porting them
> to py3k and testing them properly...

If you have to convert the code to 3.x, 2to3 does most of the dirty
work. Of course you have to test properly - the same as with any new
version. And you can't say seriously than porting to Ruby is easier
than fixing the incompatibilities with 3.0

> Especially
> since the basic treatment of strings is totally
> different in py3k, it seems.

No. The new str type is the (renamed) old unicode type. Old strings
are called bytes now. Both are immutable and mostly support the same
old methods. Comparing (2.5) dir(u"") with (3.0) dir(""): decode() is
not supported anymore; new: isidentifier(), maketrans(). Comparing
(old) str with (new) bytes: encode() is not supported, nor format();
fromhex() added. So they look basically the same to me.
Ok, when in 2.x you write u"abc", it's spelled "abc" in 3.0; and when
you write "abc" it will be spelled b"abc". But that change is easily
done with the 2to3 tool, or using "from __future__ import
unicode_literals" in Python 2.6. Again, not so terrible.

It seems to me that the fear of the upcoming 3.0 is caused mostly by
lack of information.

--
Gabriel Genellina