Python Family Gets a Triplet Of Updates

The Python developers have been busy this weekend, releasing three new versions at different points on the Python continuum: 2.7.4 (a 2.7 series bugfix release), 3.2.4 (what's new), and production releases 3.3.1. Here's what's new in 3.3.1.

Comments

Where is the 64 bit dongle support

[PhamNguyen]

Python needs to support larger dongles.

2.7.4

[JanneM]

Happy to see another bugfix release for 2.7. Like it or not, 2.7 is going to remain the main or only version of Python for years to come at many installations. Which means tools that depend on Python at such places also only or mostly support the 2.7 series.

The developers for the tool I use have just only begun discussing the possibility of perhaps beginning support for Python 3 in addition to the 2.5-2.7 versions for unspecified later versions; but only if it is possible to do without too much code duplication and maintenance efort.

Re:2.7.4

[mrvan]

I think the current trend in the community is to write a single codebase that support both 2.7 and 3.x. In python 2.x you can "from __future__ import" a lot of the 3.x syntax changes, making it possible to have a shared codebase. For example, this is how django (a major python project) is handling 3.x compatability in its latest version.

(I guess this could be used as an argument that breaking backwards compatability was not really needed and the transition could have been more gradual, but I don't know enough of the specifics on this case...)

Re:2.7.4

[mrvan]

I think it is 'dependencies dependencies' more than laziness. Few real-world projects depend only on the stdlib, and for these projects it is necessary to wait for at least the majority of depencies to adopt 3.x before porting becomes feasible, even if the porting itself is relatively straightforward. Of course, you can fork any dependencies and port them yourself, but the whole point of not reinventing a wheel is avoiding the maintenance on said wheel...

Re:The Python Launcher

[Anonymous Coward]

PEP 397 doesn't do what you think it does. It's a program that gets installed when you install Python. It parses a .py file's shebang line and uses that to determine which installed version of Python gets called. It's not designed to bundle Python programs into standalone executables. For that, you'll want to download something like http://cx-freeze.sourceforge.net/ (which works on Python 3, unlike Py2EXE)

Re:Not that surprising

[lattyware]

That's how you end up being PHP. Python 3 fixes core mistakes made in earlier versions of the language, and makes it harder to write bad code. That's a good thing, and the last thing you want is a language full of 20 ways to do something, 18 of which are deprecated. Removing backwards compatibility for the 3.x line was a good idea.

Re:A feature still missing

[lattyware]

The documentation is great in general, you seem to have found one missing link in a relatively obscure class. As a whole, Python's docs are great. They generally explain well and give full examples.

Re:Add curly braces and you have C

[mrvan]

[...]And such stupendous stupidities such as isoweekday() returning a range of 1..7 [...]

Maybe, from a CS point of view, any index should always be zero-based. However, for weekday there are two compelling arguments why this should not be the case:

1) Authoritative: The ISO specs clearly state that weekday number should be 1..7 [from wikipedia: A date is specified by the ISO week-numbering year in the format YYYY, a week number in the format ww prefixed by the letter W, and the weekday number, a digit d from 1 through 7, beginning with Monday and ending with Sunday."]. So, any library that returns an "ISO week day number" of 0 is simply non-compliant

2) Customary: All human readable date components are 1-based (the first "CE" date is 0001-01-01, not 0000-00-00). So why should weekday (which is intended for human consumption) be different?

Re:Not that surprising

[dbrueck]

Try this: take a well-formatted C or Java program and remove all the curly braces, and try to objectively quantify how much this affects your ability to determine the program's structure. Now, take the same program and leave the curly braces but remove all the indentation and again make your best guess about how much this affects your ability to determine the program's structure.

Now ask yourself two questions:
1) Which of the two (indentation or curly braces) is the much stronger indicator of program structure to a human?
2) Which of the two is the much stronger indicator of program structure to the computer?

(hint: if you're completely honest, you'll almost certainly come up with different answers for #1 and #2 :) )

Doesn't it seem just a little weird that the primary indicator of program structure to the human isn't the one that actually matters from the computer's perspective? I'm not saying it's this massive problem, but at the same time it seems odd to fault a language like Python for taking the main block structure indicator from modern languages and have both the human and the computer rely on it. No redundancy, and no chance for two competing block structure indicators to ever be out of sync.

Again, if you want a language where curlies are required, that's fine, but hopefully you can at least see that what Python does is both sensical and pragmatic.

Re:Add curly braces and you have C

[Half-pint HAL]

The only real good argument for starting indexes at zero is that it's more efficient in some cases.

Or more specifically, it's more efficient in a low-level language with compile-time-fixed-length arrays. If your array isn't a fixed block of memory referenced by index+offset, there's no technical reason to have a zero-index. All you're left with is "we've always done it that way". (Which is a fair point considering the number of errors that would arise if people got confused switching from one to the other.)