Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Python Programming Upgrades

Python Family Gets a Triplet Of Updates 196

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.
This discussion has been archived. No new comments can be posted.

Python Family Gets a Triplet Of Updates

Comments Filter:
  • The Python Launcher (Score:2, Informative)

    by Anonymous Coward on Sunday April 07, 2013 @02:38AM (#43382829)

    So, say i want to make myself a python 3 program in the form of an exe file.

    How could i use the "PEP 397: Python Launcher for Windows" in an easy way then?
    i would need to make sure python+ the python launcher were installed as well as my program files.

    or would it be easier to go with the py2exe solution?

  • by Anonymous Coward on Sunday April 07, 2013 @04:30AM (#43383019)

    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:2.7.4 (Score:4, Informative)

    by mrvan ( 973822 ) on Sunday April 07, 2013 @05:22AM (#43383149)

    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...)

  • by mrvan ( 973822 ) on Sunday April 07, 2013 @07:37AM (#43383425)

    [...]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?

  • by Half-pint HAL ( 718102 ) on Sunday April 07, 2013 @06:26PM (#43386529)

    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.)

UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn

Working...