Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #87383 > unrolled thread

Python 2 to 3 conversion - embrace the pain

Back to article view | Back to comp.lang.python

Contents

  Python 2 to 3 conversion - embrace the pain John Nagle <nagle@animats.com> - 2015-03-13 14:08 -0700
    Re: Python 2 to 3 conversion - embrace the pain INADA Naoki <songofacandy@gmail.com> - 2015-03-14 07:27 +0900
      Re: Python 2 to 3 conversion - embrace the pain John Nagle <nagle@animats.com> - 2015-03-13 16:01 -0700
        Re: Python 2 to 3 conversion - embrace the pain Ned Deily <nad@acm.org> - 2015-03-13 16:14 -0700
        Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-14 12:40 +1100
        Re: Python 2 to 3 conversion - embrace the pain INADA Naoki <songofacandy@gmail.com> - 2015-03-15 16:01 +0900
          Re: Python 2 to 3 conversion - embrace the pain wxjmfauth@gmail.com - 2015-03-15 01:11 -0700
    Re: Python 2 to 3 conversion - embrace the pain Marko Rauhamaa <marko@pacujo.net> - 2015-03-14 10:00 +0200
      Re: Python 2 to 3 conversion - embrace the pain John Nagle <nagle@animats.com> - 2015-03-15 12:05 -0700
        Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-15 19:16 +0000
        Re: Python 2 to 3 conversion - embrace the pain "Fetchinson ." <fetchinson@googlemail.com> - 2015-03-15 21:59 +0100
        Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-15 21:05 +0000
          Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-16 11:25 +1100
            Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-16 11:38 +1100
            Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-16 01:07 +0000
        Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-16 00:23 +0100
          Re: Python 2 to 3 conversion - embrace the pain Roy Smith <roy@panix.com> - 2015-03-15 19:43 -0400
            Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-16 11:00 +1100
            Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-16 01:19 +0100
            Re: Python 2 to 3 conversion - embrace the pain John Nagle <nagle@animats.com> - 2015-03-17 23:37 -0700
              Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-18 08:41 +0000
              Re: Python 2 to 3 conversion - embrace the pain Ned Deily <nad@acm.org> - 2015-03-18 02:11 -0700
                Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-18 21:53 +1100
                  Re: Python 2 to 3 conversion - embrace the pain Rustom Mody <rustompmody@gmail.com> - 2015-03-18 06:42 -0700
                    Re: Python 2 to 3 conversion - embrace the pain wxjmfauth@gmail.com - 2015-03-18 07:23 -0700
                  Re: Python 2 to 3 conversion - embrace the pain Paul Rubin <no.email@nospam.invalid> - 2015-03-18 09:35 -0700
                    Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-20 09:48 +1100
          Re: Python 2 to 3 conversion - embrace the pain Kishan Thobhani <thobhanikishan@gmail.com> - 2015-03-16 05:05 +0530
          Re: Python 2 to 3 conversion - embrace the pain Kishan Thobhani <thobhanikishan@gmail.com> - 2015-03-16 05:23 +0530
    Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-14 09:05 +0000

Page 1 of 2  [1] 2  Next page →

#87383 — Python 2 to 3 conversion - embrace the pain

  I'm approaching the end of converting a large system from Python 2 to
Python 3.  Here's why you don't want to do this.

  The language changes aren't that bad, and they're known and
documented.  It's the package changes that are the problem.
Discovering and fixing all the new bugs takes a while.


BeautifulSoup:

BeautifulSoup 3 has been phased out. I had my own version of
BeautifulSoup 3, modified for greater robustness.  But that was
years ago.  So I converted to BeautifulSoup 4, as the documentation
says to do.

The HTML5parser module is claimed to parse as a browser does, with
all the error tolerance specified in the HTML5 spec. (The spec
actually specifies how to handle bad HTML consistently across
browsers in great detail, and HTML5parser has code in it for that.)

It doesn't deliver on that promise, though. Some sites crash
BeautifulSoup 4/HTML5parser.  Try "kroger.com", which has HTML with
<head><head>.  The parse tree constructed has a bad link,
and trying to use the parse tree results in exceptions.
Submitted bug report.  Appears to be another case of
a known bug.  No workaround at this time.

https://bugs.launchpad.net/beautifulsoup/+bug/1270611
https://bugs.launchpad.net/beautifulsoup/+bug/1430633


PyMySQL:

"Pymysql is a pure Python drop-in replacement for MySQLdb".
Sounds good.  Then I discover that LOAD DATA LOCAL wasn't
implemented in the version on PyPi.  It's on Github, though,
and I got the authors to push that out to PyPi.  It
works on test cases.  But it doesn't work on a big job,
because the default size of MySQL packets was set to 16MB.
This made the LOAD DATA LOCAL code try to send the entire
file being loaded as one giant MySQL packet.  Unless you
configure the MySQL server with 16MB buffers, this fails, with
an obscure "server has gone away" message.  Found the
problem, came up with a workaround, submitted a bug report,
and it's being fixed.

https://github.com/PyMySQL/PyMySQL/issues/317


SSL:

All the new TLS/SSL support is in Python 3. That's good.
Unfortunately, using Firefox's set of SSL certs, some
important sites (such as "verisign.com") don't validate.
This turned out to be a complex problem involving Verisign
cross-signing a certificate, which created a certificate
hierarchy that some versions of OpenSSL can't handle.
There's now a version of OpenSSL that can handle it, but
the Python library has to make a call to use it, and
that's going in but isn't deployed yet.  This bug
resulted in much finger-pointing between the Python
and OpenSSL developers, the Mozilla certificate store
maintainers, and Verisign.  It's now been sorted out,
but not all the fixes are deployed.  Because "ssl" is
a core Python module, this will remain broken until the
next Python release, on both the 2.7 and 3.4 lines.

Also, for no particularly good reason, the exception
"SSL.CertificateError" is not a subclass of "SSL.Error",
resulting in a routine exception not being recognized.

Bug reports submitted for both OpenSSL and Python SSL.
Much discussion.  Problem fixed, but fix is in next
version of Python.  No workaround at this time.

http://bugs.python.org/issue23476


Pickle:

As I just posted recently, CPickle on Python 3.4 seems to
have a memory corruption bug.  Pure-Python Pickle is fine.
So a workaround is possible.  Bug report submitted.

http://bugs.python.org/issue23655


Converting a large application program to Python 3
thus required diagnosing four library bugs and filing
bug reports on all of them.  Workarounds are known
for two of the problems.  I can't deploy the Python 3
version on the servers yet.

				John Nagle

[toc] | [next] | [standalone]

#87390

Hi, John.  I'm maintainer of PyMySQL.

I'm sorry about bug of PyMySQL.  But the bug is completely unrelated
to Python 3.
You may encounter the bug on Python 2 too.

I've already made mysqlclient, the fork of MySQLdb supporting Python 3.


On Sat, Mar 14, 2015 at 6:08 AM, John Nagle <nagle@animats.com> wrote:
>   I'm approaching the end of converting a large system from Python 2 to
> Python 3.  Here's why you don't want to do this.
>
>   The language changes aren't that bad, and they're known and
> documented.  It's the package changes that are the problem.
> Discovering and fixing all the new bugs takes a while.
>
>
> BeautifulSoup:
>
> BeautifulSoup 3 has been phased out. I had my own version of
> BeautifulSoup 3, modified for greater robustness.  But that was
> years ago.  So I converted to BeautifulSoup 4, as the documentation
> says to do.
>
> The HTML5parser module is claimed to parse as a browser does, with
> all the error tolerance specified in the HTML5 spec. (The spec
> actually specifies how to handle bad HTML consistently across
> browsers in great detail, and HTML5parser has code in it for that.)
>
> It doesn't deliver on that promise, though. Some sites crash
> BeautifulSoup 4/HTML5parser.  Try "kroger.com", which has HTML with
> <head><head>.  The parse tree constructed has a bad link,
> and trying to use the parse tree results in exceptions.
> Submitted bug report.  Appears to be another case of
> a known bug.  No workaround at this time.
>
> https://bugs.launchpad.net/beautifulsoup/+bug/1270611
> https://bugs.launchpad.net/beautifulsoup/+bug/1430633
>
>
> PyMySQL:
>
> "Pymysql is a pure Python drop-in replacement for MySQLdb".
> Sounds good.  Then I discover that LOAD DATA LOCAL wasn't
> implemented in the version on PyPi.  It's on Github, though,
> and I got the authors to push that out to PyPi.  It
> works on test cases.  But it doesn't work on a big job,
> because the default size of MySQL packets was set to 16MB.
> This made the LOAD DATA LOCAL code try to send the entire
> file being loaded as one giant MySQL packet.  Unless you
> configure the MySQL server with 16MB buffers, this fails, with
> an obscure "server has gone away" message.  Found the
> problem, came up with a workaround, submitted a bug report,
> and it's being fixed.
>
> https://github.com/PyMySQL/PyMySQL/issues/317
>
>
> SSL:
>
> All the new TLS/SSL support is in Python 3. That's good.
> Unfortunately, using Firefox's set of SSL certs, some
> important sites (such as "verisign.com") don't validate.
> This turned out to be a complex problem involving Verisign
> cross-signing a certificate, which created a certificate
> hierarchy that some versions of OpenSSL can't handle.
> There's now a version of OpenSSL that can handle it, but
> the Python library has to make a call to use it, and
> that's going in but isn't deployed yet.  This bug
> resulted in much finger-pointing between the Python
> and OpenSSL developers, the Mozilla certificate store
> maintainers, and Verisign.  It's now been sorted out,
> but not all the fixes are deployed.  Because "ssl" is
> a core Python module, this will remain broken until the
> next Python release, on both the 2.7 and 3.4 lines.
>
> Also, for no particularly good reason, the exception
> "SSL.CertificateError" is not a subclass of "SSL.Error",
> resulting in a routine exception not being recognized.
>
> Bug reports submitted for both OpenSSL and Python SSL.
> Much discussion.  Problem fixed, but fix is in next
> version of Python.  No workaround at this time.
>
> http://bugs.python.org/issue23476
>
>
> Pickle:
>
> As I just posted recently, CPickle on Python 3.4 seems to
> have a memory corruption bug.  Pure-Python Pickle is fine.
> So a workaround is possible.  Bug report submitted.
>
> http://bugs.python.org/issue23655
>
>
> Converting a large application program to Python 3
> thus required diagnosing four library bugs and filing
> bug reports on all of them.  Workarounds are known
> for two of the problems.  I can't deploy the Python 3
> version on the servers yet.
>
>                                 John Nagle
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
INADA Naoki  <songofacandy@gmail.com>

[toc] | [prev] | [next] | [standalone]

#87394

On 3/13/2015 3:27 PM, INADA Naoki wrote:
> Hi, John.  I'm maintainer of PyMySQL.
> 
> I'm sorry about bug of PyMySQL.  But the bug is completely unrelated
> to Python 3.
> You may encounter the bug on Python 2 too.

   True.  But much of the pain of converting to Python 3
comes from having to switch packages because the Python 2
package didn't make it to Python 3.

   All the bugs I'm discussing reflect forced package
changes or upgrades.  None were voluntary on my part.

			John Nagle

[toc] | [prev] | [next] | [standalone]

#87395

In article <mdvq76$rit$1@dont-email.me>, John Nagle <nagle@animats.com> 
wrote:
>    All the bugs I'm discussing reflect forced package
> changes or upgrades.  None were voluntary on my part.

You would have run into the SSL certificate issue if you upgraded your 
Python 2 instance to the current Python 2.7.9.

-- 
 Ned Deily,
 nad@acm.org

[toc] | [prev] | [next] | [standalone]

#87401

On Sat, Mar 14, 2015 at 10:14 AM, Ned Deily <nad@acm.org> wrote:
> In article <mdvq76$rit$1@dont-email.me>, John Nagle <nagle@animats.com>
> wrote:
>>    All the bugs I'm discussing reflect forced package
>> changes or upgrades.  None were voluntary on my part.
>
> You would have run into the SSL certificate issue if you upgraded your
> Python 2 instance to the current Python 2.7.9.

And the same applies to many MANY other upgrades. I was trying to
delve into a VLC issue by compiling the latest version from source
control, but it wouldn't build with the version of
libsomething-or-other that shipped with Debian Wheezy, so I had to
upgrade that... and then it needed a newer Linux kernel as well, I
think, but at that point I accepted building from a couple dozen
commits ago.

If you upgrade your Python from 2.3 to 2.7, you'll find some breakage,
too. Any upgrade can do that. That's why stable OS releases don't just
randomly upgrade you... which is a bit of a pain for people who want
to distribute Python code that will "just work", but it sure is better
than something unexpectedly going belly-up on a live server!

ChrisA

[toc] | [prev] | [next] | [standalone]

#87465

What I want to say is, MySQLdb -> PyMySQL conversion is not required
for porting from Python 2 to Python 3.
mysqlclient is straight upgrade path from MySQLdb.


On Sat, Mar 14, 2015 at 8:01 AM, John Nagle <nagle@animats.com> wrote:
> On 3/13/2015 3:27 PM, INADA Naoki wrote:
>> Hi, John.  I'm maintainer of PyMySQL.
>>
>> I'm sorry about bug of PyMySQL.  But the bug is completely unrelated
>> to Python 3.
>> You may encounter the bug on Python 2 too.
>
>    True.  But much of the pain of converting to Python 3
> comes from having to switch packages because the Python 2
> package didn't make it to Python 3.
>
>    All the bugs I'm discussing reflect forced package
> changes or upgrades.  None were voluntary on my part.
>
>                         John Nagle
>
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
INADA Naoki  <songofacandy@gmail.com>

[toc] | [prev] | [next] | [standalone]

#87467

==============

Python 3 and its "Character Encoding Model" is
a (buggy ) joke.

jmf

[toc] | [prev] | [next] | [standalone]

#87412

John Nagle <nagle@animats.com>:

>   I'm approaching the end of converting a large system from Python 2
> to Python 3. Here's why you don't want to do this.

A nice report, thanks. Shows that the slowness of Python 3 adoption is
not only social inertia.


Marko

[toc] | [prev] | [next] | [standalone]

#87487

On 3/14/2015 1:00 AM, Marko Rauhamaa wrote:
> John Nagle <nagle@animats.com>:
>>   I'm approaching the end of converting a large system from Python 2
>> to Python 3. Here's why you don't want to do this.
> 
> A nice report, thanks. Shows that the slowness of Python 3 adoption is
> not only social inertia.
> Marko

    Thanks.

    Some of the bugs I listed are so easy to hit that I suspect those
packages aren't used much.  Those bugs should have been found years
ago.  Fixed, even.  I shouldn't be discovering them in 2015.

    I appreciate all the effort put in by developers in fixing these
problems.  Python 3 is still a long way from being ready for prime
time, though.

				John Nagle

[toc] | [prev] | [next] | [standalone]

#87490

On 15/03/2015 19:05, John Nagle wrote:
> On 3/14/2015 1:00 AM, Marko Rauhamaa wrote:
>> John Nagle <nagle@animats.com>:
>>>    I'm approaching the end of converting a large system from Python 2
>>> to Python 3. Here's why you don't want to do this.
>>
>> A nice report, thanks. Shows that the slowness of Python 3 adoption is
>> not only social inertia.
>> Marko
>
>      Thanks.
>
>      Some of the bugs I listed are so easy to hit that I suspect those
> packages aren't used much.  Those bugs should have been found years
> ago.  Fixed, even.  I shouldn't be discovering them in 2015.
>
>      I appreciate all the effort put in by developers in fixing these
> problems.  Python 3 is still a long way from being ready for prime
> time, though.
>
> 				John Nagle
>

This https://python3wos.appspot.com/ says differently.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#87491

On 3/15/15, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 15/03/2015 19:05, John Nagle wrote:
>> On 3/14/2015 1:00 AM, Marko Rauhamaa wrote:
>>> John Nagle <nagle@animats.com>:
>>>>    I'm approaching the end of converting a large system from Python 2
>>>> to Python 3. Here's why you don't want to do this.
>>>
>>> A nice report, thanks. Shows that the slowness of Python 3 adoption is
>>> not only social inertia.
>>> Marko
>>
>>      Thanks.
>>
>>      Some of the bugs I listed are so easy to hit that I suspect those
>> packages aren't used much.  Those bugs should have been found years
>> ago.  Fixed, even.  I shouldn't be discovering them in 2015.
>>
>>      I appreciate all the effort put in by developers in fixing these
>> problems.  Python 3 is still a long way from being ready for prime
>> time, though.
>>
>> 				John Nagle
>>
>
> This https://python3wos.appspot.com/ says differently.

A "package supporting python 3" is not equivalent to a "package not
introducing new bugs in its python 3 version relative to python 2" and
is also not equivalent to a "package working without issues on python
3".

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

[toc] | [prev] | [next] | [standalone]

#87492

On 15/03/2015 20:59, Fetchinson . wrote:
> On 3/15/15, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>> On 15/03/2015 19:05, John Nagle wrote:
>>> On 3/14/2015 1:00 AM, Marko Rauhamaa wrote:
>>>> John Nagle <nagle@animats.com>:
>>>>>     I'm approaching the end of converting a large system from Python 2
>>>>> to Python 3. Here's why you don't want to do this.
>>>>
>>>> A nice report, thanks. Shows that the slowness of Python 3 adoption is
>>>> not only social inertia.
>>>> Marko
>>>
>>>       Thanks.
>>>
>>>       Some of the bugs I listed are so easy to hit that I suspect those
>>> packages aren't used much.  Those bugs should have been found years
>>> ago.  Fixed, even.  I shouldn't be discovering them in 2015.
>>>
>>>       I appreciate all the effort put in by developers in fixing these
>>> problems.  Python 3 is still a long way from being ready for prime
>>> time, though.
>>>
>>> 				John Nagle
>>>
>>
>> This https://python3wos.appspot.com/ says differently.
>
> A "package supporting python 3" is not equivalent to a "package not
> introducing new bugs in its python 3 version relative to python 2" and
> is also not equivalent to a "package working without issues on python
> 3".
>
> Cheers,
> Daniel
>
>

So the packages increase their test coverage as the bugs get discovered 
and fixed.  Or are you saying that a mere nine years isn't a long enough 
time period to do an exercise like this?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#87498

Mark Lawrence wrote:

> On 15/03/2015 20:59, Fetchinson . wrote:
>> On 3/15/15, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>>> On 15/03/2015 19:05, John Nagle wrote:
>>>> On 3/14/2015 1:00 AM, Marko Rauhamaa wrote:
>>>>> John Nagle <nagle@animats.com>:
>>>>>>     I'm approaching the end of converting a large system from Python
>>>>>>     2
>>>>>> to Python 3. Here's why you don't want to do this.
>>>>>
>>>>> A nice report, thanks. Shows that the slowness of Python 3 adoption is
>>>>> not only social inertia.
>>>>> Marko
>>>>
>>>>       Thanks.
>>>>
>>>>       Some of the bugs I listed are so easy to hit that I suspect those
>>>> packages aren't used much.  Those bugs should have been found years
>>>> ago.  Fixed, even.  I shouldn't be discovering them in 2015.
>>>>
>>>>       I appreciate all the effort put in by developers in fixing these
>>>> problems.  Python 3 is still a long way from being ready for prime
>>>> time, though.
>>>>
>>>> John Nagle
>>>>
>>>
>>> This https://python3wos.appspot.com/ says differently.
>>
>> A "package supporting python 3" is not equivalent to a "package not
>> introducing new bugs in its python 3 version relative to python 2" and
>> is also not equivalent to a "package working without issues on python
>> 3".
>>
>> Cheers,
>> Daniel
>>
>>
> 
> So the packages increase their test coverage as the bugs get discovered
> and fixed.  Or are you saying that a mere nine years isn't a long enough
> time period to do an exercise like this?


Mark, did you read John's post or just respond with a knee-jerk defence of
Python 3? I quote:

"Some of the bugs I listed are so easy to hit that I suspect those
packages aren't used much.  Those bugs should have been found years
ago.  Fixed, even.  I shouldn't be discovering them in 2015."

Clearly a mere nine years is NOT long enough. Which is probably why the
Python core developers are supporting Python 2 until 2020. Library authors
will presumably be offering Python 2 compatibility for even longer.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#87499

On Mon, Mar 16, 2015 at 11:25 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> "Some of the bugs I listed are so easy to hit that I suspect those
> packages aren't used much.  Those bugs should have been found years
> ago.  Fixed, even.  I shouldn't be discovering them in 2015."
>
> Clearly a mere nine years is NOT long enough. Which is probably why the
> Python core developers are supporting Python 2 until 2020. Library authors
> will presumably be offering Python 2 compatibility for even longer.

I would say that time clearly isn't the issue. Nine years IS enough...
if it's a matter of time. But since the bugs are still there, it means
that the problem is a lack of usage. Solution: Use it! Do the port to
Python 3, and file those upstream bug reports.

ChrisA

[toc] | [prev] | [next] | [standalone]

#87501

On 16/03/2015 00:25, Steven D'Aprano wrote:
> Mark Lawrence wrote:
>
>> On 15/03/2015 20:59, Fetchinson . wrote:
>>> On 3/15/15, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>>>> On 15/03/2015 19:05, John Nagle wrote:
>>>>> On 3/14/2015 1:00 AM, Marko Rauhamaa wrote:
>>>>>> John Nagle <nagle@animats.com>:
>>>>>>>      I'm approaching the end of converting a large system from Python
>>>>>>>      2
>>>>>>> to Python 3. Here's why you don't want to do this.
>>>>>>
>>>>>> A nice report, thanks. Shows that the slowness of Python 3 adoption is
>>>>>> not only social inertia.
>>>>>> Marko
>>>>>
>>>>>        Thanks.
>>>>>
>>>>>        Some of the bugs I listed are so easy to hit that I suspect those
>>>>> packages aren't used much.  Those bugs should have been found years
>>>>> ago.  Fixed, even.  I shouldn't be discovering them in 2015.
>>>>>
>>>>>        I appreciate all the effort put in by developers in fixing these
>>>>> problems.  Python 3 is still a long way from being ready for prime
>>>>> time, though.
>>>>>
>>>>> John Nagle
>>>>>
>>>>
>>>> This https://python3wos.appspot.com/ says differently.
>>>
>>> A "package supporting python 3" is not equivalent to a "package not
>>> introducing new bugs in its python 3 version relative to python 2" and
>>> is also not equivalent to a "package working without issues on python
>>> 3".
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>
>> So the packages increase their test coverage as the bugs get discovered
>> and fixed.  Or are you saying that a mere nine years isn't a long enough
>> time period to do an exercise like this?
>
>
> Mark, did you read John's post or just respond with a knee-jerk defence of
> Python 3? I quote:

To damn right it's a knee jerk reaction to defend Python 3, in response 
to the pathetic "Python 3 is still a long way from being ready for prime 
time, though".  Schumachers!!!

>
> "Some of the bugs I listed are so easy to hit that I suspect those
> packages aren't used much.  Those bugs should have been found years
> ago.  Fixed, even.  I shouldn't be discovering them in 2015."

So I suggest that either the Python 3 core devs stop any development 
work and concentrate on fixing bugs in abandonware, or help out in the 
fork to Python 2.8.  Which is the preferred option?

>
> Clearly a mere nine years is NOT long enough. Which is probably why the
> Python core developers are supporting Python 2 until 2020. Library authors
> will presumably be offering Python 2 compatibility for even longer.
>

Nine years is far too long a time period to claim that people are stuck. 
  If people spent more time writing and testing code and less time 
bleating, they'd probably be looking forward to Python 4 by now. 
Further many core developers are refusing to do any work on 2.7.  As far 
as they're concerned it's dead.  If you also consider that much code was 
backported from 3.x to 2.6/7 I think anybody having the audacity to 
complain should be taken out at dawn and shot.  After their fair trial 
that is.

The one area where I do have much sympathy is with the people sending 
data down the wire.  This is being addressed (I'm too lazy right now to 
look up the PEP) but with that out of the way as far as I see it the 
final excuse has gone, port your code or simply shut up.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#87493

On Sun, 15 Mar 2015 12:05:21 -0700, John Nagle <nagle@animats.com>
wrote:

>On 3/14/2015 1:00 AM, Marko Rauhamaa wrote:
>
>    Some of the bugs I listed are so easy to hit that I suspect those
>packages aren't used much.  Those bugs should have been found years
>ago.  Fixed, even.  I shouldn't be discovering them in 2015.
>
>    I appreciate all the effort put in by developers in fixing these
>problems.  Python 3 is still a long way from being ready for prime
>time, though.
>

What do you mean a long way? Is this a scaremongering tactic? Some
little FUD to poison the minds of anyone thinking moving to Python 3?
Or you just chose your words poorly?

Because 3rd-party packages don't define whether the language is ready
for production or not and the bugs you found on the standard library
shouldn't be much different from other bugs found onPython 2 during
Python 2 prime time.

What makes you think your anedoctal bugs constitute any sort of
evidence this programming language isn't ready to be used by the
public?

[toc] | [prev] | [next] | [standalone]

#87494

In article <am4cga9sn16m74v1952gnfq5u443mkk9l1@4ax.com>,
 Mario Figueiredo <marfig@gmail.com> wrote:

> What makes you think your anedoctal bugs constitute any sort of
> evidence this programming language isn't ready to be used by the
> public?

There's several levels of "ready".

I'm sure the core language is more than ready for production use for a 
project starting from scratch which doesn't rely on any third party 
libraries.

The next step up on the "ready" ladder would be a new project which will 
require third-party libraries.  And that pretty much means any 
non-trivial project.  I'm reasonably confident that most common use 
cases can now be covered by p3-ready third party modules.  Perhaps there 
will be fewer choices of which implementation to go with for some 
things, but at this point, I'd be surprised if you'd get stuck because 
all the third party modules out there which do something you want are p2 
only.

The big problem continues to be the legacy projects.  People made 
decisions years ago about what packages to use, and those decisions are 
hard to get away from.  There is a lot of production code out there 
which still uses third-party packages that are effectively abandonware 
by now.  But the code still runs, and there's little incentive to mess 
with it.  Rather than migrate to p3, it's more likely those systems will 
continue to run for years to run on p2, until eventually somebody turns 
out the lights.

[toc] | [prev] | [next] | [standalone]

#87496

On Mon, Mar 16, 2015 at 10:43 AM, Roy Smith <roy@panix.com> wrote:
> The big problem continues to be the legacy projects.  People made
> decisions years ago about what packages to use, and those decisions are
> hard to get away from.  There is a lot of production code out there
> which still uses third-party packages that are effectively abandonware
> by now.  But the code still runs, and there's little incentive to mess
> with it.  Rather than migrate to p3, it's more likely those systems will
> continue to run for years to run on p2, until eventually somebody turns
> out the lights.

At some point, the fact that those third-party packages aren't being
maintained will _itself_ be a problem. To be sure, no individual one
is likely to be as big a target as to attract attention, but all it
takes is one good exploit and you're completely stuck. What do you do
once someone discovers that they can compromise your server, not
through Python itself, but through some library that nobody supports
*at all* any more? How much downtime will it take to re-secure your
system?

If compromises and outages aren't a concern to you, then there's no
problem, stick to the abandoned packages. But if they are - if your
code is internet-facing in any way - then you'll eventually need to
upgrade to a newer bugfix version of everything you're using, and that
means switching out those abandonware packages for some that are
actively maintained.

Notice how nothing in the above two paragraphs mentions Python 2 vs 3
at all? The problem you're looking at is abandoned modules, not Python
3. Py3 just helps you to notice it sooner. It's entirely possible that
you have a Red Hat system running Python 2.3/2.4 and you can't even
upgrade as far as 2.7 because you have a dep that's incompatible with
2.7. This problem will _always_ come up. Either you depend on
something that gets upgraded periodically, or you carry the
maintenance burden yourself (fix the code yourself, or stick with the
old versions).

ChrisA

[toc] | [prev] | [next] | [standalone]

#87497

On Sun, 15 Mar 2015 19:43:38 -0400, Roy Smith <roy@panix.com> wrote:

>
>The big problem continues to be the legacy projects.  People made 
>decisions years ago about what packages to use, and those decisions are 
>hard to get away from.  There is a lot of production code out there 
>which still uses third-party packages that are effectively abandonware 
>by now.  But the code still runs, and there's little incentive to mess 
>with it.  Rather than migrate to p3, it's more likely those systems will 
>continue to run for years to run on p2, until eventually somebody turns 
>out the lights.

If it isn't broken, don't fix it. I can certainly agree with that. But
even if a fix is required there are associated costs to a language
upgrade that rarely justify it. And for this reason Python 2 should
remain well and alive for the lifetime of any legacy code.

The OP however is hinting at the idea that Python 3 isn't ready to
create its own production code, because either the standard library or
the 3rd-party library real estate isn't giving the language enough
working tools. This is false, of course. Python 3 has been producing
working applications for years.

I'm not much of an apologist of Python 3. I don't defend for instance
that people should upgrade *old code* to Python 3 code. (I'm not even
qualified to do so, since I'm a relative newcomer to the language
whose only experience with python 2 has been to understand how to
create backwards compatible versions of my Python 3 code).

But I do really defend the idea that we should stop looking for
justifications to keep creating *new code* in Python 2. Everytime we
do so we are extending the transition period and perpetuating all the
backward compatible issues we have been facing. I mean, I would love
to one day stop worrying about creating backward compatible code in
Python 3. It's one royal PITA.

So, when I see someone crying over Twisted lack of support, or some
obscure bug in some library, I just wonder if these people started
programming today. There was a time when people had to do without
Twisted. And there was a time when people had to do with bugs in the
standard library. If these programmers can't abide by those things
what were they doing back then?

[toc] | [prev] | [next] | [standalone]

#87667

On 3/15/2015 4:43 PM, Roy Smith wrote:
> In article <am4cga9sn16m74v1952gnfq5u443mkk9l1@4ax.com>,
>  Mario Figueiredo <marfig@gmail.com> wrote:
> 
>> What makes you think your anecdotal bugs constitute any sort of
>> evidence this programming language isn't ready to be used by the
>> public?
> 
> There's several levels of "ready".
> 
> I'm sure the core language is more than ready for production use for a 
> project starting from scratch which doesn't rely on any third party 
> libraries.
> 
> The next step up on the "ready" ladder would be a new project which will 
> require third-party libraries.  And that pretty much means any 
> non-trivial project.  I'm reasonably confident that most common use 
> cases can now be covered by p3-ready third party modules. 

   If only that were true.  Look what I'm reporting bugs on:

	ssl - a core Python module.
	cPickle - a core Python module.
	pymysql - the pure-Python recommended way to talk to MySQL.
	bs4/html5parser - a popular parser for HTML5

We're not in exotic territory here.  I've done lots of exotic
projects, but this isn't one of them.

There's progress.  The fix to "ssl" has been made and committed.
I have a workaround for the cPickle bug - use pure-Python Pickle.
I have a workaround for the pymysql problem, and a permanent fix
is going into the next release of pymysql. I have a tiny test case
for bs4/html5parser that reproduces the bug on a tiny snippet of
HTML, and that's been uploaded to the BS4 issues tracker.
I don't have a workaround for that.

All this has cost me about two weeks of work so far.

The "everything is just fine" comments are not helpful.
Denial is not a river in Egypt.

				John Nagle
	

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web