tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Rewriting pkglint in a portable language



On Thu, 24 Mar 2016 10:45:50 -0500
"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> wrote:
> Python is a *completely* different story.  The change from Python 2 to
> 3 is huge and significantly breaks lots of code.  I experienced this

Yes, and they are very clear about this.

> personally when trying to migrate some code from 2 to 3 and spending a
> lot of time dealing with the string representation change in Python 3.

If you coded as if the whole world was "ASCII English" (AE) then yes,
you have a long road ahead of you.  The whole point of Python3 string
handling is that strings are sequences of code points and bytes are a
different type of object.  An example of a problem with that is opening
files. If you are on Unix you could be lazy and not worry if a file was
text or binary since they were treated the same for AE.  If your code
opened text files with "r" or "rt" and binary files as "rb" then they
work properly under both Python2 and Python3.

I had a lot of legacy code to convert and I admit that I could be lazy
sometimes (what programmer isn't?) but once I ran 2to3 over the code
and worked on the input and output, strings just worked and with a few
"from __future__" statements worked under both.

> As another example, Mercurial requires Python 2 and, according to [1],
> it will take a significant effort to port it to Python 3.

I read that and find it hard to believe but I don't know their code
well enough.  I do find the statement "Mercurial will never support
Python 3.0 to 3.4 because of missing support for the % operator on str
types" to be misleading.  Using the format method is considered better
but '%' still exists.  I still use it all the time.

$ python3.4 -c "print('%05d' % 42)"
00042

> When Python 3 came out, the impression I got from the Python
> developers was that Python 2 would be supported for a while but then
> support would end.  It seems that this position has softened now
> because it has become clear that the effort to convert the large base
> of existing code from Python 2 to 3 is so massive.  I was of the

Actually, the biggest stumbling block is the availability of third
party packages but that is slowly being fixed.  Porting C modules is
more work than porting Python code.  I just ported PyGreSQL over and it
was a big job.  Now it works with both versions of Python.

> opinion that if the Python developers really did drop support for
> Python 2, we would see a fork of Python 2.  Thankfully, though, now
> it seems that Python 2 is still supported.

Even after support is dropped, legacy code will continue to run under
the older version.  New projects and actively maintained projects are
the only ones that should be worrying about Python3.

-- 
D'Arcy J.M. Cain <darcy%NetBSD.org@localhost>
http://www.NetBSD.org/ IM:darcy%Vex.Net@localhost


Home | Main Index | Thread Index | Old Index