Weekly Edition
Return to the Press page
| |||||||||||||
Python 3 primer, Part 1: What's new (developerWorks)
developerWorks begins
a series looking at Python 3. "This article - the first in a
series on Python 3 - covers the new print() function, input(), changes to
input/output (I/O), the new bytes data type, changes to strings and string
formatting, and finally, changes to the built-in dict type. This article is
meant for programmers who are already familiar with Python and are curious
about the changes but don't want to wade through the long list of Python
Enhancement Proposals (PEPs)."
(Log in to post comments)
Python 3 primer, Part 1: What's new (developerWorks) Posted Dec 20, 2008 21:29 UTC (Sat) by mikachu (guest, #5333) [Link]
Here's a list of errors i spotted:
in the first example, the print function prints log.txt rather than log text, which can be confusing.
in the bits on bytes section, the author seems to be confused about what a byte is:
Not an error but this sentence probably doesn't convey the intended meaning, "It certainly wasn't as drastic a change as moving from Python to the Java or Perl languages".
Python 3 primer, Part 1: What's new (developerWorks) Posted Dec 21, 2008 18:57 UTC (Sun) by sbergman27 (guest, #10767) [Link]
Of more concern to me is this bit of alarmism:
"""
This is the kind of thinking that will likely lead to a flurry of "Why did Python 3 fail?" articles this time next year. Python 3.x is not really that big a change from 2.x. A gradual phasing in over a couple of years has always been the plan. And it all reminds me a lot of the move from Apache 1.3 to 2.x. Apache 1.3.x was serving people's needs very well, indeed, as has Python 2.x. When Apache 2.0. was released, it cleaned up a lot of stuff, and was definitely a good move for the future. But there was little excitement about it in the community, and certainly no rush to migrate. So was Apache 2.0 a failure? Hardly. And yet I'm seeing the groundwork being laid, in various places, for all those future "What went wrong?" articles when Python 3.x popularity doesn't take off like a rocket. And it won't, because it was never supposed to. Expect a gradual shift, as the community becomes ready for it. And expect the conversion tools to become better, and migration path to become easier, over that time.
Python 3 primer, Part 1: What's new (developerWorks) Posted Dec 23, 2008 0:33 UTC (Tue) by copsewood (subscriber, #199) [Link]
As a Python developer and someone who also teaches occasional Python short courses this is something I'm watching closely. The main requirement for shifting the teaching courses to Python 3 is the availability of suitable books and tools which cover it. If I had to do a course starting in a fortnight it would probably have to be on version 2 with additional information covering the changes, but no-one learning a new language really wants to invest too much effort in the previous version of it if the new version is likely to be ready for prime time very soon.
In connection with porting existing code the main issue will be the availablity of libraries and whether or not these have been ported. I can see it taking between 3 and 12 months for the books and tools issue to be resolved and between 6 and 18 months for the libraries. Even in the worst possible case I don't think this is going to be anything like as big a jump as it will be changing from Perl 5 to Perl 6.
I'm very much looking forward to being able to learn, use and teach the new improved Python language.
Python 3 primer, Part 1: What's new (developerWorks) Posted Dec 22, 2008 19:46 UTC (Mon) by iabervon (subscriber, #722) [Link]
It is true that, in order to get bytes out of a string, you need to specify an encoding, but bytes has barely anything to do with strings or characters now. I assume that he was looking at the section on bytes literals, where you can write b'\xc3\x9feta' for his example (ASCII characters for byte values in the 0-127 range), but can't write b'Ùeta' (assuming a UTF-8 source file, that would be putting the desired byte sequence between in quotes in the file on disk, if I did UTF-8 in my head correctly) or b'Éeta' (using Unicode characters for byte values in the 128-255 range).
They'd probably have made it easier to understand if they'd made bytes literals only permit specifying the contents numerically, like: (not actually allowed): b'xc3 x9f x65 x74 x61' that is, only ignore whitespace, treat everything else except the matching quote like it had a \ in front of it, and disallow non-numeric escapes). It would make it slightly harder to type in binary data with lots of bytes which are (arbitrarily) in the ASCII range, like the GIF file magic number, but I doubt that's very important.
|
|||||||||||||