Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Those two controversial 2nd & 3rd paragraphs of my ch 1

Reply
Thread Tools

Those two controversial 2nd & 3rd paragraphs of my ch 1

 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      01-13-2010
Referring to <url: http://tinyurl.com/programmingbookP3>

Due to especially Steven D'Aprano's comments I've replaced "hopeless" with "very
hard" in paragraph 1 of section 1.1 -- I know he'll disagree with that also
but I think any more downplaying of the difficulties would be misleading.

According to Mensanator's comments I've changed paragraph 2 in section 1.1 to
point out that the latest version of Python is typically not bundled with an OS.

The two paragraphs now read:


<quote>
As of this writing two main variants of the Python language are in use, namely
Python 2.x and Python 3.x (versions 3.0 and greater). Mostly they’re the same
but the effect of e.g. the / division operator changed in 3.0, so in practice
it’s very hard to create programs that work the same – or even just work –
with both variants. The examples and discussion in this book assume Python
version 3.1.1 or later.

Python implementations, the tools etc. that you need to create and run Python
programs – at least for some earlier version of Python! – are bundled with
many operating systems such as Linux and Mac OS X, but unfortunately not with
Windows.
</quote>


It's said that the hardest part of a book is the opening sentence -- "It was a
dark and stormy night; the rain fell in torrents, except at occasional
intervals, when it was checked by a violent gust of wind which swept up the
streets (for it is in London that our scene lies), rattling along the housetops,
and fiercely agitating the scanty flame of the lamps that struggled against the
darkness" -- but in my case, not 1st sentence but the 2nd and 3rd paragraphs!

Comments welcome.


Cheers,

- Alf

PS: Now more stuff added to ch 3 but I've not updated the separate TOC since
that's a bit of work.
 
Reply With Quote
 
 
 
 
Peter Otten
Guest
Posts: n/a
 
      01-13-2010
Alf P. Steinbach wrote:

> As of this writing two main variants of the Python language are in use,
> namely Python 2.x and Python 3.x (versions 3.0 and greater). Mostly
> they’re the same but the effect of e.g. the / division operator changed in
> 3.0, so in practice it’s very hard to create programs that work the same
> – or even just work – with both variants. The examples and discussion in
> this book assume Python version 3.1.1 or later.


It may be hard to support Python 2 and 3 with the same script, but the
division operator is not a good example to support that statement because
you can get the 3.x behaviour in 2.x with a simple

from __future__ import division

at the top of the module.

Peter

 
Reply With Quote
 
 
 
 
Daniel Fetchinson
Guest
Posts: n/a
 
      01-13-2010
>> As of this writing two main variants of the Python language are in use,
>> namely Python 2.x and Python 3.x (versions 3.0 and greater). Mostly
>> they’re the same but the effect of e.g. the / division operator changed in
>> 3.0, so in practice it’s very hard to create programs that work the same
>> – or even just work – with both variants. The examples and discussion in
>> this book assume Python version 3.1.1 or later.

>
> It may be hard to support Python 2 and 3 with the same script, but the
> division operator is not a good example to support that statement because
> you can get the 3.x behaviour in 2.x with a simple
>
> from __future__ import division
>
> at the top of the module.


I was about to write the same!

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 2/3

0
>>> from __future__ import division
>>> 2/3

0.66666666666666663
>>>


Also, I would replace

"in practice it’s very hard to create programs"

with

"in practice it’s very hard to create complex programs"

because for small programs it's very possible to write code that will
work with both python 2 and 3. The question is of course what program
is simple/small and what program is large/complex, but without
qualifications your sentence is misleading, I think.

Cheers,
Daniel

HTH,
Daniel


--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
 
Reply With Quote
 
Stefan Behnel
Guest
Posts: n/a
 
      01-13-2010
Daniel Fetchinson, 13.01.2010 16:23:
> Also, I would replace
>
> "in practice it’s very hard to create programs"
>
> with
>
> "in practice it’s very hard to create complex programs"
>
> because for small programs it's very possible to write code that will
> work with both python 2 and 3. The question is of course what program
> is simple/small and what program is large/complex, but without
> qualifications your sentence is misleading, I think.


We had the example of Cheetah over in the other thread. Would you say that
Cheetah doesn't qualify as "complex" program? There are also other
examples, like Django. Often enough it's just a couple of cleanups and tiny
try-except blocks in the program header that enables running the program in
both Py2 and Py3, If it's more, it can usually be done using 2to3. So I
would change the above statement into something more like "for some
programs, especially large existing code bases, it can be hard to get the
code to work in both Python 2 and Python 3". Nevertheless, it has been
done, more than once.

Personally, I don't see much value in deliberately trying to keep people
from porting their code to Py3 by producing underqualified statements like
the above.

Stefan
 
Reply With Quote
 
Daniel Fetchinson
Guest
Posts: n/a
 
      01-13-2010
>> Also, I would replace
>>
>> "in practice it’s very hard to create programs"
>>
>> with
>>
>> "in practice it’s very hard to create complex programs"
>>
>> because for small programs it's very possible to write code that will
>> work with both python 2 and 3. The question is of course what program
>> is simple/small and what program is large/complex, but without
>> qualifications your sentence is misleading, I think.

>
> We had the example of Cheetah over in the other thread. Would you say that
> Cheetah doesn't qualify as "complex" program?


One code base of cheetah works under python 2 and 3? I doubt it, but I
could be wrong. What I can easily imagine is that somebody ported
cheetah to python 3. In this case there are two code bases, one for
python 2 and another for python 3. So it's not the same program that
runs under python 2 and 3.

What the sentence in Alf's book is about is having the same code base
working for both python 2 and 3.

> There are also other
> examples, like Django.


Again, django has been ported to python 3, that's fine, everybody
acknowledges that, but it's not the case that one code base works with
both python versions.

> Often enough it's just a couple of cleanups and tiny
> try-except blocks in the program header that enables running the program in
> both Py2 and Py3.


Yes, this is true. But I'd say it's fair to say that with complex
programs this is usually not the case, but I definitely not want to
enter into a discussion into whether any given program is complex or
simple. It's a matter of judgement and gut feeling it's pointless to
argue about this too much.

> If it's more, it can usually be done using 2to3.


Again, 2to3 helps with porting, but does not help with having a single
code base that will run unmodified on python 2 and 3, which is what
Alf was writing about.

> So I
> would change the above statement into something more like "for some
> programs, especially large existing code bases, it can be hard to get the
> code to work in both Python 2 and Python 3".


I actually agree with this sentence

> Nevertheless, it has been done, more than once.


Example? Just to be clear I'm looking for an example where one given
code runs on python 2 and 3 unmodified. I think django and cheetah
doesn't count because they simply take their python 2 code, run it
through 2to3 which gives them a python 3 code (I could be wrong
though). Two codes for the two python versions.

> Personally, I don't see much value in deliberately trying to keep people
> from porting their code to Py3 by producing underqualified statements like
> the above.


Nobody is deliberately trying to keep people from porting! I think you
misunderstand what is being said, these two statements are very
different: (1) single code base working on both python versions (2)
creating a second code from a code so that the second code works with
python 3 and the first one with python 2. Statement (2) is about
porting, statement (1) is about something else.

Having said all that I actually seriously doubt (probably in agreement
with you) that Alf is able to write good and helpful material on the
relationship between python 2 and 3, porting, migrating, etc, based on
his emails

Cheers,
Daniel




--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
 
Reply With Quote
 
André
Guest
Posts: n/a
 
      01-13-2010
On Jan 13, 12:30*pm, Daniel Fetchinson <(E-Mail Removed)>
wrote:

>
> One code base of cheetah works under python 2 and 3? I doubt it, but I
> could be wrong. What I can easily imagine is that somebody ported
> cheetah to python 3. In this case there are two code bases, one for
> python 2 and another for python 3. So it's not the same program that
> runs under python 2 and 3.
>


I don't know about Cheetah, but I have read about other programs with
one code base that run under both Python 2 and Python 3. And I can
guarantee that it is the case for Crunchy.

It *is* possible to have one program working correctly under both
Python 2 *and* 3 with a single code base. It might not be the
officially recommended way... but that does not make it impossible.

André

 
Reply With Quote
 
Stefan Behnel
Guest
Posts: n/a
 
      01-13-2010
Daniel Fetchinson, 13.01.2010 17:30:
> Again, django has been ported to python 3, that's fine, everybody
> acknowledges that, but it's not the case that one code base works with
> both python versions.


Well, if the port is done via 2to3, you can install the same code base in
Python 2 and Python 3, and the distutils install mechanism will run an
automated transformation over the code during the installation. If there is
no manual interaction required to run the code on both platforms, I would
say that qualifies as "one code base works with both Python versions". It's
not different from generating code or specialised config files during the
installation or similar things.


> I think django and cheetah
> doesn't count because they simply take their python 2 code, run it
> through 2to3 which gives them a python 3 code (I could be wrong
> though). Two codes for the two python versions.


But just one code base that has to be maintained. And I think the
maintenance is the main aspect here.


> Just to be clear I'm looking for an example where one given
> code runs on python 2 and 3 unmodified.


lxml for example. Not only the Cython compiled part (which is automatically
portable anyway), also all of its Python code base and its entire test
suite. It runs on all Python versions from 2.3 through 3.1, and it doesn't
use 2to3 or any other kind of code modification.

The regular Python code base was almost trivial to port, but porting the
test suite was actually quite involved. The main reasons for that were a)
doctests and b) the requirement to test exactly string input/output and
exactly unicode input/output on both platforms. Most code simply doesn't
have that requirement, but lxml does.

Stefan
 
Reply With Quote
 
Steve Holden
Guest
Posts: n/a
 
      01-13-2010
Daniel Fetchinson wrote:
>>> Also, I would replace
>>>
>>> "in practice it’s very hard to create programs"
>>>
>>> with
>>>
>>> "in practice it’s very hard to create complex programs"
>>>
>>> because for small programs it's very possible to write code that will
>>> work with both python 2 and 3. The question is of course what program
>>> is simple/small and what program is large/complex, but without
>>> qualifications your sentence is misleading, I think.

>> We had the example of Cheetah over in the other thread. Would you say that
>> Cheetah doesn't qualify as "complex" program?

>
> One code base of cheetah works under python 2 and 3? I doubt it, but I
> could be wrong. What I can easily imagine is that somebody ported
> cheetah to python 3. In this case there are two code bases, one for
> python 2 and another for python 3. So it's not the same program that
> runs under python 2 and 3.
>
> What the sentence in Alf's book is about is having the same code base
> working for both python 2 and 3.
>
>> There are also other
>> examples, like Django.

>
> Again, django has been ported to python 3, that's fine, everybody
> acknowledges that, but it's not the case that one code base works with
> both python versions.
>
>> Often enough it's just a couple of cleanups and tiny
>> try-except blocks in the program header that enables running the program in
>> both Py2 and Py3.

>
> Yes, this is true. But I'd say it's fair to say that with complex
> programs this is usually not the case, but I definitely not want to
> enter into a discussion into whether any given program is complex or
> simple. It's a matter of judgement and gut feeling it's pointless to
> argue about this too much.
>
>> If it's more, it can usually be done using 2to3.

>
> Again, 2to3 helps with porting, but does not help with having a single
> code base that will run unmodified on python 2 and 3, which is what
> Alf was writing about.
>
>> So I
>> would change the above statement into something more like "for some
>> programs, especially large existing code bases, it can be hard to get the
>> code to work in both Python 2 and Python 3".

>
> I actually agree with this sentence
>
>> Nevertheless, it has been done, more than once.

>
> Example? Just to be clear I'm looking for an example where one given
> code runs on python 2 and 3 unmodified. I think django and cheetah
> doesn't count because they simply take their python 2 code, run it
> through 2to3 which gives them a python 3 code (I could be wrong
> though). Two codes for the two python versions.
>
>> Personally, I don't see much value in deliberately trying to keep people
>> from porting their code to Py3 by producing underqualified statements like
>> the above.

>
> Nobody is deliberately trying to keep people from porting! I think you
> misunderstand what is being said, these two statements are very
> different: (1) single code base working on both python versions (2)
> creating a second code from a code so that the second code works with
> python 3 and the first one with python 2. Statement (2) is about
> porting, statement (1) is about something else.
>
> Having said all that I actually seriously doubt (probably in agreement
> with you) that Alf is able to write good and helpful material on the
> relationship between python 2 and 3, porting, migrating, etc, based on
> his emails
>

[sigh]

OK, let's review the approved strategy for porting to 3.x from 2.x.

1. Ensure you have an acceptable test suite that verifies all major
functionality.

2. Port your code to the most recent version of 2.x (retaining backward
compatibility with older versions where necessary and practical)

3. Enable Python 3 warnings with the -3 argument and fix all
incompatibilities

4. Run 2to3 on your 2.x code and observe the errors obtained when
running the result under 3.x

5. Fix by paraphrasing your 2.x code to remove translation errors and
return to step 4, repeating until there are no more errors.

In other words, you are not recommended to aim for source compatibility,
you instead aim for a 2.x source which produces a correct 3.x source
when run through the 2to3 translator.

In this way you can continue to produce both 2.x and 3.x versions of
your projects form a single source tree until you no longer care about
2.x, at which point you simply use the output of the final 2to3
conversion as your onward source.

Of course this only works for pure Python code, but that's the majority
of Python code produced.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

 
Reply With Quote
 
Daniel Fetchinson
Guest
Posts: n/a
 
      01-13-2010
>> One code base of cheetah works under python 2 and 3? I doubt it, but I
>> could be wrong. What I can easily imagine is that somebody ported
>> cheetah to python 3. In this case there are two code bases, one for
>> python 2 and another for python 3. So it's not the same program that
>> runs under python 2 and 3.
>>

>
> I don't know about Cheetah, but I have read about other programs with
> one code base that run under both Python 2 and Python 3. And I can
> guarantee that it is the case for Crunchy.
>
> It *is* possible to have one program working correctly under both
> Python 2 *and* 3 with a single code base. It might not be the
> officially recommended way... but that does not make it impossible.


Cool, thanks, I didn't know about crunchy having this property, good to know.

Cheers,
Daniel


--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
 
Reply With Quote
 
Daniel Fetchinson
Guest
Posts: n/a
 
      01-13-2010
>> Again, django has been ported to python 3, that's fine, everybody
>> acknowledges that, but it's not the case that one code base works with
>> both python versions.

>
> Well, if the port is done via 2to3, you can install the same code base in
> Python 2 and Python 3, and the distutils install mechanism will run an
> automated transformation over the code during the installation. If there is
> no manual interaction required to run the code on both platforms, I would
> say that qualifies as "one code base works with both Python versions". It's
> not different from generating code or specialised config files during the
> installation or similar things.


This is all true, but what we were talking about is not exactly this,
but rather having a single code base running unmodified on python 2
and 3. Another poster actually supplied an example: crunchy.


> > I think django and cheetah
> > doesn't count because they simply take their python 2 code, run it
> > through 2to3 which gives them a python 3 code (I could be wrong
> > though). Two codes for the two python versions.

>
> But just one code base that has to be maintained. And I think the
> maintenance is the main aspect here.


This is true again. But where it all started is Alf's sentence in his
book. And I think he has a point there, it might be possible to do
this (single code base for both versions), but it's not easy.

>> Just to be clear I'm looking for an example where one given
>> code runs on python 2 and 3 unmodified.

>
> lxml for example. Not only the Cython compiled part (which is automatically
> portable anyway), also all of its Python code base and its entire test
> suite. It runs on all Python versions from 2.3 through 3.1, and it doesn't
> use 2to3 or any other kind of code modification.
>
> The regular Python code base was almost trivial to port, but porting the
> test suite was actually quite involved. The main reasons for that were a)
> doctests and b) the requirement to test exactly string input/output and
> exactly unicode input/output on both platforms. Most code simply doesn't
> have that requirement, but lxml does.


Cool, that's another example I was unaware of, thanks!

Cheers,
Daniel


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

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Wonder why old 4/3rd lenses are slow on m4/3rd bodies? RichA Digital Photography 8 03-02-2012 11:40 PM
A Controversial Report debianna HTML 0 03-12-2009 05:02 PM
Re: Request: A+ Complete 3rd edition (PDF) [1/1] - A+ Complete 3rd edition.txt (1/1) Spammy Sammy A+ Certification 0 03-04-2005 12:55 PM
Re: The controversial $5 setup fee Tina - AffordableHOST, Inc., the dealer in ferrets Computer Support 0 06-27-2004 07:58 AM
Canon A60 controversial timings Rado bladteth Rzeznicki Digital Photography 0 01-21-2004 02:54 PM



Advertisments