Moving from Python 2 to Python 3: A 4 page "cheat sheet"
Mark Summerfield
of Python 2<->3 differences plus the most commonly used new Python 3
features. It is aimed at existing Python 2 programmers who want to
start writing Python 3 programs and want to use Python 3 idioms rather
than those from Python 2 where the idioms differ.
It uses Python 3.1 syntax since that looks like being the standard for
a few years in view of the language moratorium.
The document is U.S. Letter size but will also print fine on A4
printers.
It is available as a free PDF download (no registration or anything)
from InformIT's website. Here's the direct link:
http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/promotions/python/python2python3.pdf
And of course, if you want more on Python 3, there's always the
documentation---or my book:-)
"Programming in Python 3 (Second Edition)" ISBN-10: 0321680561.
Daniel Fetchinson
> of Python 2<->3 differences plus the most commonly used new Python 3
> features. It is aimed at existing Python 2 programmers who want to
> start writing Python 3 programs and want to use Python 3 idioms rather
> than those from Python 2 where the idioms differ.
>
> It uses Python 3.1 syntax since that looks like being the standard for
> a few years in view of the language moratorium.
This really looks very useful, thanks a lot!
I've been wishing something like this existed for a while, really handy.
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Gnarlodious
> "Programming in Python 3 (Second Edition)" ISBN-10: 0321680561.
I ordered it...
-- Gnarlie
http://Gnarlodious.com
Mark Dickinson
> I've produced a 4 page document that provides a very concise summary
> of Python 2<->3 differences plus the most commonly used new Python 3
> features.
Very nice indeed!
My only quibble is with the statement on the first page that
the 'String % operator is deprecated'. I'm not sure that's
true, for all values of 'deprecated'. There don't appear
to be any definite plans for getting rid of it just yet.
Mark
Lie Ryan
Nice.
I suggest changing the lambda example a bit, the current example says:
Python 2 Python 3
lambda (a,b): a + b lambda t: t[0] + t[1]
lambda a, b: a + b
into something like:
Python 2 Python 3
lambda (a,b),c: a + b + c lambda t, c: t[0] + t[1] + c
lambda a, b, c: a + b + c
it is unclear at first sight that it refers to tuple argument unpacking.
There should also some mention that tuple argument unpacking for regular
function (def) is also gone.
Also, I'm not sure what this change is referring to:
Python 2 Python 3
L = list(seq) L = sorted(seq)
L.sort()
L.sort is still available in python, and sorted() have been available
since python 2. Both list.sort() and sorted() are for different purpose,
and neither will be deprecated. What's the change here?
Terry Reedy
What might be even *more* helpful, with contributions from others
perhaps, would be an indication of which changes are handled
automatically by 2to3.py and which must be done by hand.
tjr
John Bokma
> It is available as a free PDF download (no registration or anything)
> from InformIT's website. Here's the direct link:
> http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/promotions/python/python2python3.pdf
Thanks!
> And of course, if you want more on Python 3, there's always the
> documentation---or my book:-)
> "Programming in Python 3 (Second Edition)" ISBN-10: 0321680561.
Meh, second edition already? Haven't read the entire first edition
yet. Which is IMO a good book (I also gave it to my brother as a
present).
Only negative point (to me) so far is that in the beginning (p8-9) the
book mentions placing Python programs in C:\py3eg which gives me the
unpleasant feeling that someone is coding on Windows XP with
Administrator rights...
Anyway, will add the 2nd edition to my wish list and donate the current
one to the library in Xalapa (USBI) if they want it :-)
John
Mark Summerfield
I didn't make this up:-)
According to http://docs.python.org/dev/3.0/whatsnew/3.0.html
"The plan is to eventually make this the only API for string
formatting, and to start deprecating the % operator in Python 3.1."
Mark Summerfield
> On 12/2/2009 1:03 AM, Mark Summerfield wrote:
>
>
>
> > I've produced a 4 page document that provides a very concise summary
> > of Python 2<->3 differences plus the most commonly used new Python 3
> > features. It is aimed at existing Python 2 programmers who want to
> > start writing Python 3 programs and want to use Python 3 idioms rather
> > than those from Python 2 where the idioms differ.
>
> > It uses Python 3.1 syntax since that looks like being the standard for
> > a few years in view of the language moratorium.
>
> > The document is U.S. Letter size but will also print fine on A4
> > printers.
>
> > It is available as a free PDF download (no registration or anything)
> > from InformIT's website. Here's the direct link:
>
> > And of course, if you want more on Python 3, there's always the
> > documentation---or my book:-)
> > "Programming in Python 3 (Second Edition)" ISBN-10: 0321680561.
>
> Nice.
Thanks!
> I suggest changing the lambda example a bit, the current example says:
> Python 2 Python 3
> lambda (a,b): a + b lambda t: t[0] + t[1]
> lambda a, b: a + b
>
> into something like:
>
> Python 2 Python 3
> lambda (a,b),c: a + b + c lambda t, c: t[0] + t[1] + c
> lambda a, b, c: a + b + c
>
> it is unclear at first sight that it refers to tuple argument unpacking.
Your proposed example is clearer in some respects, but mine is more
minimal. And I think that anyone who _thinks_ about mine will get the
point. (The document is short, but I never claimed it was a quick
read;-)
> There should also some mention that tuple argument unpacking for regular
> function (def) is also gone.
I probably should have, but it is hard to fit any more in... esp.
since I don't want to take anything out.
> Also, I'm not sure what this change is referring to:
> Python 2 Python 3
> L = list(seq) L = sorted(seq)
> L.sort()
>
> L.sort is still available in python, and sorted() have been available
> since python 2. Both list.sort() and sorted() are for different purpose,
> and neither will be deprecated. What's the change here?
The document is about idioms as well as changes. In this case both
approaches work in both versions, but it seems that there are still a
lot of people who don't know about sorted(), so I put it in to show it
as an idiom.
Mark Summerfield
> Mark Summerfield wrote:
> > I've produced a 4 page document that provides a very concise summary
> > of Python 2<->3 differences plus the most commonly used new Python 3
> > features. It is aimed at existing Python 2 programmers who want to
> > start writing Python 3 programs and want to use Python 3 idioms rather
> > than those from Python 2 where the idioms differ.
>
> > It uses Python 3.1 syntax since that looks like being the standard for
> > a few years in view of the language moratorium.
>
> > The document is U.S. Letter size but will also print fine on A4
> > printers.
>
> > It is available as a free PDF download (no registration or anything)
> > from InformIT's website. Here's the direct link:
>
> > And of course, if you want more on Python 3, there's always the
> > documentation---or my book:-)
> > "Programming in Python 3 (Second Edition)" ISBN-10: 0321680561.
>
> What might be even *more* helpful, with contributions from others
> perhaps, would be an indication of which changes are handled
> automatically by 2to3.py and which must be done by hand.
>
> tjr
No, that's exactly what I did not want to cover and the document says
so up front. It is aimed at people who want Python 3 to come from
their own brains and fingers!
Also, the kind of info you're talking about is covered elsewhere, for
example:
http://diveintopython3.org/porting-code-to-python-3-with-2to3.html
Mark Summerfield
> Mark Summerfield <l...@qtrac.plus.com> writes:
> > It is available as a free PDF download (no registration or anything)
> > from InformIT's website. Here's the direct link:
>
> Thanks!
>
> > And of course, if you want more on Python 3, there's always the
> > documentation---or my book:-)
> > "Programming in Python 3 (Second Edition)" ISBN-10: 0321680561.
>
> Meh, second edition already? Haven't read the entire first edition
> yet. Which is IMO a good book (I also gave it to my brother as a
> present).
If it is any consolation, the second edition should have a much longer
life, now that we have the language moratorium. (I _really_ wanted to
cover 3.1.)
> Only negative point (to me) so far is that in the beginning (p8-9) the
> book mentions placing Python programs in C:\py3eg which gives me the
> unpleasant feeling that someone is coding on Windows XP with
> Administrator rights...
OK, you got me there, I only use Windows for testing purposes and my
personal logon account does have Administrator rights, which I assumed
was standard for personal machines? Also, the path is short. It is
only a suggestion, it really doesn't matter where you unpack the
examples.
Mark Dickinson
> On 1 Dec, 17:50, Mark Dickinson <dicki...@gmail.com> wrote:
> > My only quibble is with the statement on the first page that
> > the 'String % operator is deprecated'. I'm not sure that's
> > true, for all values of 'deprecated'. There don't appear
> > to be any definite plans for getting rid of it just yet.
>
No, I didn't imagine for a second that you had!
> According to http://docs.python.org/dev/3.0/whatsnew/3.0.html
> "The plan is to eventually make this the only API for string
> formatting, and to start deprecating the % operator in Python 3.1."
I think that's a doc bug. "The plan is to ..." should read: "The plan
was
originally to ...". (Well, at least in the 3.1 version of the
"what's new in 3.0" documentation; the 3.0 version that you linked to
isn't even autogenerated any more, AFAIK, so fixes to the ReST source
for that file never make it to the web site.)
I'm a little confused myself about what's actually happening with
% formatting, but here's a fairly recent python-dev posting from
the BDFL:
http://mail.python.org/pipermail/python-dev/2009-September/092399.html
Mark
Wolodja Wentland
It would be quite nice if you could mark all the Python 3 idioms that
work in Python 2.X as well. This would allow readers that are still using
Python 2.X and are used to the 'old way' to adapt their coding style
accordingly. You could just add a little (2.X) after the idiom for
example.
And thanks for the nice cheat sheet! :-D
--
.''`. Wolodja Wentland <went...@cl.uni-heidelberg.de>
: :' :
`. `'` 4096R/CAF14EFC
`- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
Martin P. Hellwig
<cut>
> It is available as a free PDF download (no registration or anything)
> from InformIT's website. Here's the direct link:
> http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/promotions/python/python2python3.pdf
Very handy! Am I wrong in assuming that you forgot to include that
file() is gone in favour of open()?
--
MPH
http://blog.dcuktec.com
'If consumed, best digested with added seasoning to own preference.'
Mark Summerfield
> of Python 2<->3 differences plus the most commonly used new Python 3
> features. It is aimed at existing Python 2 programmers who want to
> start writing Python 3 programs and want to use Python 3 idioms rather
> than those from Python 2 where the idioms differ.
>
> It uses Python 3.1 syntax since that looks like being the standard for
> a few years in view of the language moratorium.
>
> The document is U.S. Letter size but will also print fine on A4
> printers.
>
> It is available as a free PDF download (no registration or anything)
>
> And of course, if you want more on Python 3, there's always the
> documentation---or my book:-)
> "Programming in Python 3 (Second Edition)" ISBN-10: 0321680561.
I only just found out that I was supposed to give a different URL:
http://www.informit.com/promotions/promotion.aspx?promo=137519
This leads to a web page where you can download the document (just by
clicking the "Download Now" button), but if you _choose_ you can also
enter your name and email to win some sort of prize.
Mark Summerfield
> On Dec 2, 8:01 am, MarkSummerfield<l...@qtrac.plus.com> wrote:
>
> > On 1 Dec, 17:50, Mark Dickinson <dicki...@gmail.com> wrote:
> > > My only quibble is with the statement on the first page that
> > > the 'String % operator is deprecated'. I'm not sure that's
> > > true, for all values of 'deprecated'. There don't appear
> > > to be any definite plans for getting rid of it just yet.
>
> > I didn't make this up:-)
>
> No, I didn't imagine for a second that you had!
>
> > "The plan is to eventually make this the only API for string
> > formatting, and to start deprecating the % operator in Python 3.1."
>
> I think that's a doc bug. "The plan is to ..." should read: "The plan
> was
> originally to ...". (Well, at least in the 3.1 version of the
> "what's new in 3.0" documentation; the 3.0 version that you linked to
> isn't even autogenerated any more, AFAIK, so fixes to the ReST source
> for that file never make it to the web site.)
>
> I'm a little confused myself about what's actually happening with
> % formatting, but here's a fairly recent python-dev posting from
> the BDFL:
>
> http://mail.python.org/pipermail/python-dev/2009-September/092399.html
Well it seems clear to me that the BDFL wants to kill of % formatting,
but wasn't able to for Python 3... So I still think it is reasonable
(1) to describe it as deprecated and (2) to only teach and use
str.format().
Mark Summerfield
wrote:
> On Wed, Dec 02, 2009 at 00:10 -0800, Mark Summerfield wrote:
> > On 1 Dec, 18:30, Lie Ryan <lie.1...@gmail.com> wrote:
> > > Also, I'm not sure what this change is referring to:
> > > Python 2 Python 3
> > > L = list(seq) L = sorted(seq)
> > > L.sort()
>
> > > L.sort is still available in python, and sorted() have been available
> > > since python 2. Both list.sort() and sorted() are for different purpose,
> > > and neither will be deprecated. What's the change here?
>
> > The document is about idioms as well as changes. In this case both
> > approaches work in both versions, but it seems that there are still a
> > lot of people who don't know about sorted(), so I put it in to show it
> > as an idiom.
>
> It would be quite nice if you could mark all the Python 3 idioms that
> work in Python 2.X as well. This would allow readers that are still using
> Python 2.X and are used to the 'old way' to adapt their coding style
> accordingly. You could just add a little (2.X) after the idiom for
> example.
Yes it would be nice, but it isn't quite so simple. To take sorted()
as just one example, it was introduced in 2.4 so arguably using it
isn't valid/idiomatic for Python 2.x programs where you care about
backwards compatibility for the Python 2.x series... But my main
reason for not wanting to do this is that the document is aimed at
people who want to write Python 3, not to encourage people to stick
with 2:-)
>
> And thanks for the nice cheat sheet! :-D
Thanks!
> --
> .''`. Wolodja Wentland <wentl...@cl.uni-heidelberg.de>
> : :' :
> `. `'` 4096R/CAF14EFC
> `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
>
> signature.asc
> < 1KViewDownload
Mark Summerfield
wrote:
> MarkSummerfieldwrote:
>
> <cut>> It is available as a free PDF download (no registration or anything)
> > from InformIT's website. Here's the direct link:
>
> <cut>
> Very handy! Am I wrong in assuming that you forgot to include that
> file() is gone in favour of open()?
No you are not wrong in assuming that I forgot that:-(
My lame excuse is that file() was introduced for isinstance() testing
and similar, and never really as a replacement for open().
Anyway, I have now added:
fh = file(fname, mode) | fh = open(fname, mode)
I've sent a new PDF with this change to InformIT, so hopefully it'll
become available soon from
http://www.informit.com/promotions/promotion.aspx?promo=13751
Mark Summerfield
Oops wrong URL again, should have been:
http://www.informit.com/promotions/promotion.aspx?promo=137519
... time to go offline and sleep ...
John Posner
wrote:
> On Dec 1, 2:03 pm, Mark Summerfield <l...@qtrac.plus.com> wrote:
>> I've produced a 4 page document that provides a very concise summary
>> of Python 2<->3 differences plus the most commonly used new Python 3
>> features. It is aimed at existing Python 2 programmers who want to
>> start writing Python 3 programs and want to use Python 3 idioms rather
>> than those from Python 2 where the idioms differ.
Mark, I add my thanks to those of the other responders. If you find space,
you might consider adding another str.format() feature:
Goal: place integer 456 flush-right in a field of width 8
Py2: "%%%dd" % 8 % 456
Py3: "{0:{1}d}".format(456, 8)
With str.format(), you don't need to nest one formatting operation within
another. A little less mind-bending, and every little bit helps!
-John
Mark Dickinson
> Goal: place integer 456 flush-right in a field of width 8
>
> Py2: "%%%dd" % 8 % 456
> Py3: "{0:{1}d}".format(456, 8)
>
> With str.format(), you don't need to nest one formatting operation within
> another. A little less mind-bending, and every little bit helps!
Or even "{:{}d}".format(456, 8), in 3.1 and 2.7 (when it appears).
But you can do this with % formatting, too. In either 2.x or 3.x:
>>> "%*d" % (8, 456)
' 456'
--
Mark
Carsten Haese
> Goal: place integer 456 flush-right in a field of width 8
>
> Py2: "%%%dd" % 8 % 456
> Py3: "{0:{1}d}".format(456, 8)
>
> With str.format(), you don't need to nest one formatting operation
> within another.
With string interpolation, you don't need to do that, either.
>>> '%*d' % (8,456)
' 456'
--
Carsten Haese
http://informixdb.sourceforge.net
David H Wild
<351fcb4c-4e88-41b0...@e23g2000yqd.googlegroups.com>,
Mark Summerfield <li...@qtrac.plus.com> wrote:
> I only just found out that I was supposed to give a different URL:
> http://www.informit.com/promotions/promotion.aspx?promo=137519
> This leads to a web page where you can download the document (just by
> clicking the "Download Now" button), but if you _choose_ you can also
> enter your name and email to win some sort of prize.
There is a typographical fault on page 4 of this pdf file. The letter "P"
is missing from the word "Python" at the head of the comparison columns.
--
David Wild using RISC OS on broadband
www.davidhwild.me.uk
John Bokma
> On 1 Dec, 23:52, John Bokma <j...@castleamber.com> wrote:
>> Mark Summerfield <l...@qtrac.plus.com> writes:
>> > It is available as a free PDF download (no registration or anything)
>> > from InformIT's website. Here's the direct link:
>> >http://ptgmedia.pearsoncmg.com/imprint_downloads/informit/promotions/...
>>
>> Thanks!
>>
>> > And of course, if you want more on Python 3, there's always the
>> > documentation---or my book:-)
>> > "Programming in Python 3 (Second Edition)" ISBN-10: 0321680561.
>>
>> Meh, second edition already? Haven't read the entire first edition
>> yet. Which is IMO a good book (I also gave it to my brother as a
>> present).
>
> If it is any consolation, the second edition should have a much longer
> life, now that we have the language moratorium. (I _really_ wanted to
> cover 3.1.)
Nah, I wasn't really complaining. Moreover, I am glad I didn't finish
the first edition, so I have less of a problem starting in the 2nd
edition from the beginning. From what I've read in the 1st edition it's
an excellent book.
>> Only negative point (to me) so far is that in the beginning (p8-9) the
>> book mentions placing Python programs in C:\py3eg which gives me the
>> unpleasant feeling that someone is coding on Windows XP with
>> Administrator rights...
>
> OK, you got me there,
I knew it ;-) Should've emailed you months ago and maybe it would have
changed in the 2nd edition :-(
> I only use Windows for testing purposes and my
> personal logon account does have Administrator rights, which I assumed
> was standard for personal machines?
I use XP Professional and the first thing I do after installation is
creating a limited user account for my day to day work. As far as I know
this can also be done in XP Home, but I've no experience with home.
> Also, the path is short. It is
> only a suggestion, it really doesn't matter where you unpack the
> examples.
My issue with it is that it somewhat promotes working with Administrator
rights, which is as dangerous as working with root rights on other OSes
if the machine is not connected to the Internet. If it's connected to
the Internet it's way more dangerous, sadly.
Anyway, thanks for writing IMO a very good book, and I *am* happy with a
second edition.
--
John Bokma
Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/
Mark Summerfield
> In article
> <351fcb4c-4e88-41b0-a0aa-b3d63832d...@e23g2000yqd.googlegroups.com>,
> Mark Summerfield <l...@qtrac.plus.com> wrote:
>
> > I only just found out that I was supposed to give a different URL:
> >http://www.informit.com/promotions/promotion.aspx?promo=137519
> > This leads to a web page where you can download the document (just by
> > clicking the "Download Now" button), but if you _choose_ you can also
> > enter your name and email to win some sort of prize.
>
> There is a typographical fault on page 4 of this pdf file. The letter "P"
> is missing from the word "Python" at the head of the comparison columns.
I can't see that problem---I've tried the PDF with evince, gv,
acroread, and okular, and no missing "P" on page 4. I don't have a
machine with RISC OS on it so I can't test on that environment!
MRAB
> On 2 Dec, 19:28, David H Wild <dhw...@talktalk.net> wrote:
>> In article
>> <351fcb4c-4e88-41b0-a0aa-b3d63832d...@e23g2000yqd.googlegroups.com>,
>> Mark Summerfield <l...@qtrac.plus.com> wrote:
>>
>>> I only just found out that I was supposed to give a different URL:
>>> http://www.informit.com/promotions/promotion.aspx?promo=137519
>>> This leads to a web page where you can download the document (just by
>>> clicking the "Download Now" button), but if you _choose_ you can also
>>> enter your name and email to win some sort of prize.
>> There is a typographical fault on page 4 of this pdf file. The letter "P"
>> is missing from the word "Python" at the head of the comparison columns.
>
look OK.) :-)
John Posner
<carste...@gmail.com> wrote:
>
> With string interpolation, you don't need to do that, either.
>>>> '%*d' % (8,456)
> ' 456'
>
Thanks, Carsten and Mark D. -- I'd forgotten about the use of "*" in
minimum-field-width specs and precision specs (doh). How about this:
"pi={1:.{0}f} e={2:.{0}f}".format(5, math.pi, math.e)
(result: 'pi=3.14159 e=2.71828')
Can the Python2 %-formating facility handle this without repeating the "5"
argument?
Even if it can, I stand by my original suggestion: include an example to
show that the arguments to str.format() can be used on both the left and
the right of a ":" in a replacement field.
-John
Terry Reedy
> Well it seems clear to me that the BDFL wants to kill of % formatting,
> but wasn't able to for Python 3...
Definitely. I thought of adding autonumbering of fields (in 3.1) in
response to his inquiry about the barriers to moving to .format. That
solved 'simplicity of defaults'. The other, 'Autoconversion of installed
base' still awaits.
> So I still think it is reasonable
> (1) to describe it as deprecated and (2) to only teach and use
> str.format().
At the moment (3.1) there are, unfortunately, library packages that
require % for formatting (logging, I believe, for one). There has been
discussion on adding a new option for 3.2, but I do not know what will
happen. Depends on whether you want to be absolutely complete. I
strictly use .format when I can, which so far is always.
Terry Jan Reedy
Antoine Pitrou
Le Tue, 01 Dec 2009 06:03:36 -0800, Mark Summerfield a écrit :
> I've produced a 4 page document that provides a very concise summary of
> Python 2<->3 differences plus the most commonly used new Python 3
> features. It is aimed at existing Python 2 programmers who want to start
> writing Python 3 programs and want to use Python 3 idioms rather than
> those from Python 2 where the idioms differ.
>
> It is available as a free PDF download (no registration or anything)
> from InformIT's website. Here's the direct link:
This is great!
Just one thing:
« Copyright © Qtrac Ltd. 2009. All rights reserved »
Might I suggest that you release it under a free license instead?
(such as the CC by, CC by-sa, or the Free Art License)
Regards
Antoine.
Mark Summerfield
> On Wed, 02 Dec 2009 13:34:11 -0500, Carsten Haese
>
I can't squeeze another line into the last column of the last page (I
already tried).
However, a natural place to put this would be in the first section on
the first page. But I want _common_ not _clever_, i.e., an example
that shows a common use of * in % that I can then show using a nested
replacement field. The idea is that people can look at the left hand
column, recognize an idiom they use, and then be able to figure out
from the right hand column how to do the same in Python 3.
Anyway, I've come up with a tiny example and managed to squeeze it in,
so hopefully it'll appear on InformIT's web site in a day or so.
Mark Summerfield
> Mark Summerfield wrote:
> > On 2 Dec, 19:28, David H Wild <dhw...@talktalk.net> wrote:
> >> In article
> >> <351fcb4c-4e88-41b0-a0aa-b3d63832d...@e23g2000yqd.googlegroups.com>,
> >> Mark Summerfield <l...@qtrac.plus.com> wrote:
>
> >>> I only just found out that I was supposed to give a different URL:
> >>>http://www.informit.com/promotions/promotion.aspx?promo=137519
> >>> This leads to a web page where you can download the document (just by
> >>> clicking the "Download Now" button), but if you _choose_ you can also
> >>> enter your name and email to win some sort of prize.
> >> There is a typographical fault on page 4 of this pdf file. The letter "P"
> >> is missing from the word "Python" at the head of the comparison columns.
>
> Which is page 4? The page numbers are missing! (But the column titles
> look OK.) :-)
I didn't put page numbers or headers or footers on it---seemed
redundant for such a short document.
Mark Summerfield
Good idea---I'll try.
Wolodja Wentland
> On Dec 2, 11:20 am, Wolodja Wentland <wentl...@cl.uni-heidelberg.de>
> > It would be quite nice if you could mark all the Python 3 idioms that
> > work in Python 2.X as well. This would allow readers that are still using
> > Python 2.X and are used to the 'old way' to adapt their coding style
> > accordingly. You could just add a little (2.X) after the idiom for
> > example.
> Yes it would be nice, but it isn't quite so simple.
> To take sorted() as just one example, it was introduced in 2.4 so
> arguably using it isn't valid/idiomatic for Python 2.x programs where
> you care about backwards compatibility for the Python 2.x series...
Yes, which is why you could include a 2.X and people who target, say
current +/- 0.1 can choose their poison.
> But my main reason for not wanting to do this is that the document is
> aimed at people who want to write Python 3, not to encourage people to
> stick with 2:-)
I actually think that it is the other way round. People should get
familiar with py3 features even if they are not yet ready to
"abandon" py2 (yet). I also think that using some of the backported/supported
features might spur interest in features that are 'py3 only' and therefore
encourage the adoption of py3.
It would also be nice to have a summary of things people can do *now* if
they want to keep the changes from 2to3 to a minimum, which will be with
us for some time. But that is not something *you* have to write .. :-)
--
.''`. Wolodja Wentland <went...@cl.uni-heidelberg.de>
David H Wild
<9d290ad6-e0b8-4bfa...@a21g2000yqc.googlegroups.com>,
Mark Summerfield <li...@qtrac.plus.com> wrote:
> > There is a typographical fault on page 4 of this pdf file. The letter
> > "P" is missing from the word "Python" at the head of the comparison
> > columns.
> I can't see that problem---I've tried the PDF with evince, gv,
> acroread, and okular, and no missing "P" on page 4. I don't have a
> machine with RISC OS on it so I can't test on that environment!
Using a different pdf reader, on the same machine, the letters are there.
It's an odd thing, because it's only that one page that has the problem.
Thanks, anyway.
Mark Summerfield
> Mark Summerfield <l...@qtrac.plus.com> wrote:
>
> > > There is a typographical fault on page 4 of this pdf file. The letter
> > > "P" is missing from the word "Python" at the head of the comparison
> > > columns.
> > I can't see that problem---I've tried the PDF with evince, gv,
> > acroread, and okular, and no missing "P" on page 4. I don't have a
> > machine with RISC OS on it so I can't test on that environment!
>
> Using a different pdf reader, on the same machine, the letters are there.
> It's an odd thing, because it's only that one page that has the problem.
I've never had a problem with my PDFs before. However I use the lout
typesetting system and I suspect that it has some bugs relating to
external links (which normally I don't use but which I've put in this
particular document). Anyway, glad you found something that could read
it:-)
BTW issue #2 is now up. This has the file() vs. open() line. Hopefully
issue #3 will follow tomorrow or early next week with a line about
%*d.
Mark Summerfield
OK, issue#3 of the document is now available:
http://www.informit.com/promotions/promotion.aspx?promo=137519
In the light of feedback from [these people] it now has:
- an entry for file() vs. open() [Martin P. Hellwig]
- an entry for %* vs. {:{}} syntax [John Posner, Mark Dickinson, &
Carsten Haese]
- creative commons license "CC by-sa" [Antoine Pitrou]
So I hope it will prove even more useful now:-)
Vinay Sajip
> At the moment (3.1) there are, unfortunately, library packages that
> require % for formatting (logging, I believe, for one). There has been
> discussion on adding a new option for 3.2, but I do not know what will
> happen. Depends on whether you want to be absolutely complete. I
> strictly use .format when I can, which so far is always.
Logging uses %-style formatting because that was all that was
available at the time it was written. A frequent complaint from some
quarters is about the overhead of logging, and so I'm not sure it's a
good idea to switch over from %-formatting to str.format just for the
sake of it, unless a way can be found which avoids the problems of
lower performance and backwards compatibility (e.g. a foolproof %-
string to {} converter, which I've had a stab at, but which cannot be
achieved without changes to the {} code, e.g. to allow old-style octal
constants). As far as logging is concerned I'll be periodically
looking to see if moving over to the new format without performance/
backwards compatibility compromises is feasible, and when it is I'll
adopt the new format.
For now, AFAIK, people who are determined to use the {}-format can do
so by subclassing logging.Formatter and by passing in message classes
which convert format-string and args to final message. It's a one-time
cost they'd incur (to write the relevant subclasses) which could be
used on multiple projects.
Regards,
Vinay Sajip