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 2 of 2 — ← Prev page 1 [2]

#87670

On 18/03/2015 06:37, John Nagle wrote:
> 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
> 	
>

This is clearly where our thought processes differ. ssl is not a core 
Python module, it gets built into Python on Windows and OS X as an 
external module.  I assume you have to build it on the *nix variants or 
install via the appropriate package manager.  pymysql and 
bs4/html5parser are third party modules that core python has no control 
over.  You have a workaround to the cPickle issue.  So it's obvious to 
me that your complaints should be on the mailing lists for the third 
party modules that don't work for you, not here, and the cPickle issue 
should be on the bug tracker if it isn't already.

-- 
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]

#87671

In article <meb6ct$11j$1@dont-email.me>, John Nagle <nagle@animats.com> 
wrote:
>    If only that were true.  Look what I'm reporting bugs on:
> 
> 	ssl - a core Python module.

I assume you're referring to http://bugs.python.org/issue23476.
It seems to me that the issue there was not in Python but due to a 
shortcoming in OpenSSL itself.  When the shortcoming was addressed in 
the most recent major release of OpenSSL (1.0.2), both Python 2 and 3 
were modified to take advantage of the new OpenSSL API option when 
available.  Also you would have seen the same behavior if you upgraded 
to the current version of Python 2 (2.7.9), since 2.7.9 now has most of 
the same TLS/SSL support code and best practice defaults that 3.4.3 
does.  So let's not blame this one on Python 3. 
 
> 	cPickle - a core Python module.

http://bugs.python.org/issue23655

No question that this appears to be a serious problem and, while yet 
unresolved, does appear to be a bug in Python 3 itself.

> 	pymysql - the pure-Python recommended way to talk to MySQL.
> 	bs4/html5parser - a popular parser for HTML5

I'm not in a position to comment on those third-party projects. It's too 
bad that you ran into problems with them.  Any idea if you would have 
seen similar problems if you had used them with Python 2?

In any case, of the two problems noted with Python itself, there is only 
one that appears to be Python 3 related.  That's still not good but I 
think it would be fairer to ascribe a good chunk of the pain you've 
experienced to the more common pain of upgrading any major software 
system that depends on multiple third-party components.

-- 
 Ned Deily,
 nad@acm.org

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

#87675

On Wed, 18 Mar 2015 08:11 pm, Ned Deily wrote:

> In any case, of the two problems noted with Python itself, there is only
> one that appears to be Python 3 related.  That's still not good but I
> think it would be fairer to ascribe a good chunk of the pain you've
> experienced to the more common pain of upgrading any major software
> system that depends on multiple third-party components.


I think what often goes on is rather similar to this process:


"Jim ran a red light and side-swiped a police car. Jim's a bad driver."

"Fred nearly hit a pedestrian. Fred's a bad driver."

"George crashed into a tree because he was texting. George is a bad driver."

"Susan reversed into the fence and broke it. Women are lousy drivers!"


The precise details of every major upgrade differ, of course, and sometimes
things run more smoothly, or less smoothly, depending on the project.
John's earlier comment:

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

sounds about normal to me :-) Never mind two weeks late, IT projects running
*two years* late sometimes seems like par for the course.

But as soon as something "different" is involved, like Python 3, some people
(and I'm not pointing the finger at John here, just making a general
observation) make the same exaggerated over-generalisation as they do
with "lousy woman drivers". The two weeks we lost upgrading from Python 2.6
to 2.7 is just the normal upgrade pains you always have to expect from any
major project, but the two weeks we lost going from 2.7 to 3.3 is a sign
that Python 3 is a broken mistake!

Anyway, thanks John for persevering.


-- 
Steven

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

#87678

On Wednesday, March 18, 2015 at 4:23:37 PM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 18 Mar 2015 08:11 pm, Ned Deily wrote:
> 
> > In any case, of the two problems noted with Python itself, there is only
> > one that appears to be Python 3 related.  That's still not good but I
> > think it would be fairer to ascribe a good chunk of the pain you've
> > experienced to the more common pain of upgrading any major software
> > system that depends on multiple third-party components.
> 
> 
> I think what often goes on is rather similar to this process:
> 
> 
> "Jim ran a red light and side-swiped a police car. Jim's a bad driver."
> 
> "Fred nearly hit a pedestrian. Fred's a bad driver."
> 
> "George crashed into a tree because he was texting. George is a bad driver."
> 
> "Susan reversed into the fence and broke it. Women are lousy drivers!"
> 

And some of them may be simply facts
And some mistaken generalizations
[And some politically incorrect]

ie
P(x) ⇒ ∀x•P(x)
is not valid
does not mean
¬[P(x) ⇒ ∀x•P(x)]
is

> Anyway, thanks John for persevering.

Yes -- Thats a useful comment!

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

#87680

Le mercredi 18 mars 2015 14:43:44 UTC+1, Rustom Mody a écrit :
> > 
> 
> 
> ie
> P(x) ⇒ ∀x•P(x)
> is not valid
> does not mean
> ¬[P(x) ⇒ ∀x•P(x)]
> is
> 

eg. Flexible String Represenation.

(Do not even think to expect to explain it,
however it's doable with students with some math
background at academic level).

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

#87686

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> The two weeks we lost upgrading from Python 2.6 to 2.7 is just the
> normal upgrade pains you always have to expect from any major project,

Wait, what happened between 2.6 and 2.7 that took you two weeks of
upgrading?

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

#87748

On Thu, 19 Mar 2015 03:35 am, Paul Rubin wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>> The two weeks we lost upgrading from Python 2.6 to 2.7 is just the
>> normal upgrade pains you always have to expect from any major project,
> 
> Wait, what happened between 2.6 and 2.7 that took you two weeks of
> upgrading?

Read my comment in context. I'm talking about the perception (shared by
various people) that it is not uncommon to hit a two week delay when
upgrading a major project between *any* two Python versions, not just
between 2.7 and 3.4. I'm not relating a specific anecdote.

Unless a project is specifically written to be flexible about the versions
it works with[1], chances are good that any .x version change will break
something. If you're lucky, it will just break things in your own code,
which you can easily fix. If you're unlucky, it will break things in your
dependencies, which you can't. It's not hard to lose a few weeks in working
around bugs in third-party libraries.

People freak out about the syntax changes going from 2.x to 3.x, or the
changes to standard library module names. But let's look at the actual
issues John ran into:

- BeautifulSoup 4 has a known bug and crashes on some websites;

- PyMySQL gave an obscure error with one specific command unless 
  your MySQL database was configured with 16MB buffers;

- TLS/SSL support ran into a complex interaction between Python,
  Firefox's SSL certificates, OpenSSL and Verisign.

- A memory corruption bug in the C implementation of the Python
  3.4 pickle module.


You'll note that *none of these* issues are specific to the backwards
incompatibility between 2.x and 3.x. They all could have occurred between
any two versions of Python.




[1] And I'll admit that it's somewhat easier to cover (say) 2.6 + 2.7 rather
than 2.7 + 3.3. But it is doable: apart from trivial single use scripts,
all my code targets 2.4 through 3.3+ and beyond, and with a few exceptions,
it's not that painful. (I did try supporting 2.3 as well for a little
while, but that wasn't merely painful, it was agonising. 2.3 is seriously
lacking built-in functionality compared to what follows.) I'm looking
forward to retiring my Centos 5 machine, because then I can drop support
for 2.4 and 2.5. That will make me sooooo happppy!!!


-- 
Steven

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

#87528

[Multipart message — attachments visible in raw view] — view raw

I believe we push towards accepting new paradigms like python 3. If bugs
were found on libraries used in older context were probably because there
wasn't a need of particular feature. & that is how eventually a software
becomes a legacy. There are times when we might want to re-use this library
or legacy software, then it make sense to solve the bug as well as port it
to new version. Timeline for anything build on top-of-any-language doesn't
necessarily have to cope up with evolving language unless needed.

Warm Regards,

Kishan Thobhani
Jedi Master at Printajoy | Full Stack Engineer at Azoi Inc.
W: www.kishanthobhani.com
E: thobhanikishan@gmail.com
M: +91-972-594-0782

On Mon, Mar 16, 2015 at 4:53 AM, Mario Figueiredo <marfig@gmail.com> wrote:

> 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?
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

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

#87529

I believe we push towards accepting new paradigms like python 3. If bugs were found on libraries used in older context were probably because there wasn't a need of particular feature. & that is how eventually a software becomes a legacy. There are times when we might want to re-use this library or legacy software, then it make sense to solve the bug as well as port it to new version. Timeline for anything build on top-of-any-language doesn't necessarily have to cope up with evolving language unless needed.  


> On 16-Mar-2015, at 4:53 am, Mario Figueiredo <marfig@gmail.com> wrote:
> 
> 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?
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

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

#87415

On 13/03/2015 21:08, John Nagle 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.
>

One reason why you should 
https://speakerdeck.com/pyconslides/python-3-dot-3-trust-me-its-better-than-python-2-dot-7-by-dr-brett-cannon

Of course I understand the problems of time when it comes to porting 
code.  Taking this Tue Mar 21 06:19:36 CET 2006, the time of the first 
email on the Python 3000 development mailing list, as the start date for 
Python 3, developers have only had nine years to port their libraries. 
Rome wasn't destroyed in a day? :)

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

Mark Lawrence

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web