[RELEASE] Python 2.7 released

[Benjamin Peterson]

On behalf of the Python development team, I'm jocund to announce the second
release candidate of Python 2.7.

Python 2.7 will be the last major version in the 2.x series. However, it will
also have an extended period of bugfix maintenance.

2.7 includes many features that were first released in Python 3.1. The faster io
module, the new nested with statement syntax, improved float repr, set literals,
dictionary views, and the memoryview object have been backported from 3.1. Other
features include an ordered dictionary implementation, unittests improvements, a
new sysconfig module, auto-numbering of fields in the str/unicode format method,
and support for ttk Tile in Tkinter. For a more extensive list of changes in
2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python
distribution.

To download Python 2.7 visit:

http://www.python.org/download/releases/2.7/

2.7 documentation can be found at:

http://docs.python.org/2.7/

This is a production release and should be suitable for all libraries and
applications. Please report any bugs you find, so they can be fixed in the next
maintenance releases. The bug tracker is at:

http://bugs.python.org/


Enjoy!

 

[Martineau]

On behalf of the Python development team, I'm jocund to announce the second
release candidate of Python 2.7.

Python 2.7 will be the last major version in the 2.x series. However, it will
also have an extended period of bugfix maintenance.

2.7 includes many features that were first released in Python 3.1. The faster io
module, the new nested with statement syntax, improved float repr, set literals,
dictionary views, and the memoryview object have been backported from 3.1.. Other
features include an ordered dictionary implementation, unittests improvements, a
new sysconfig module, auto-numbering of fields in the str/unicode format method,
and support for ttk Tile in Tkinter.  For a more extensive list of changes in
2.7, seehttp://doc.python.org/dev/whatsnew/2.7.htmlor Misc/NEWS in the Python
distribution.

To download Python 2.7 visit:

     http://www.python.org/download/releases/2.7/

2.7 documentation can be found at:

     http://docs.python.org/2.7/

This is a production release and should be suitable for all libraries and
applications.  Please report any bugs you find, so they can be fixed in the next
maintenance releases.  The bug tracker is at:

     http://bugs.python.org/

Enjoy!

--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 2.7's contributors)

Benjamin (or anyone else), do you know where I can get the Compiled
Windows Help file -- python27.chm -- for this release? In the past
I've been able to download it from the Python web site, but have been
unable to locate it anywhere for this new release. I can't build it
myself because I don't have the Microsoft HTML help file compiler.

Thanks in advance.

 

[John Machin]

Benjamin (or anyone else), do you know where I can get the Compiled
Windows Help file -- python27.chm -- for this release? In the past
I've been able to download it from the Python web site, but have been
unable to locate it anywhere for this new release. I can't build it
myself because I don't have the Microsoft HTML help file compiler.

Thanks in advance.

If you have a Windows box, download the .msi installer for Python 2.7
and install it. The chm file will be in C:\Python27\Doc (if you choose
the default installation directory). Otherwise ask a friendly local
Windows user for a copy.

 

[Benjamin Kaplan]

If you have a Windows box, download the .msi installer for Python 2.7
and install it. The chm file will be in C:\Python27\Doc (if you choose
the default installation directory). Otherwise ask a friendly local
Windows user for a copy.
--

Or you can just use 7-zip or cabextract on the MSi. Saves you from
having to uninstall it later, and it works on non-Windows machines.

 

[Martineau]

Or you can just use 7-zip or cabextract on the MSi. Saves you from
having to uninstall it later, and it works on non-Windows machines.

Perhaps it's hidden somewhere, but I couldn't find the .chm help file
in the python-2.7.msi file using 7-zip, nor saw anything that looked
like a Doc folder embedded within it -- so I doubt installing it on a
Windows machine would work any better.

I'd like to view the contents of the help file without actually
installing the release which would wipe out any currently installed
version (I'm one of those rare people who actually reads manuals
*before* using or installing most things.)

So my original question stands -- where can one get the Windows Help
file for v2.7?

 

[Alexander Kapps]

Perhaps it's hidden somewhere, but I couldn't find the .chm help file
in the python-2.7.msi file using 7-zip, nor saw anything that looked
like a Doc folder embedded within it -- so I doubt installing it on a
Windows machine would work any better.

I don't know much about the .msi format or how 7-Zip handles it, but
on my XP box, 7-Zip lists a "python" sub-archive (a 7-Zip
"compound"). Within is the python27.chm

 

[Steven D'Aprano]

I'd like to view the contents of the help file without actually
installing the release which would wipe out any currently installed
version (I'm one of those rare people who actually reads manuals
*before* using or installing most things.)

When you say "wipe out any currently installed version", do you mean an
older version of 2.7, or an older version such as 2.6, 2.5, 2.4, ... ?

If the first, I don't know of any simple way to keep multiple
installations with the same major and minor version number (e.g. 2.7.0a
and 2.7.0.b). Sorry.

But if you mean the second, that you don't want to over-write 2.6, I'd be
shocked if the Python installer does that. Doesn't it install Python to
something like C:\Programs\Python<version> ?

Performing a source install under Linux, by default existing versions
remain in place, but there's a soft link "python" which points to the
most recent version. Doing a regular install over-writes the soft link.
But there's an "altinstall" option which leaves the link untouched, so
(for example) I have python -> python 2.5 while still having other
versions installed and accessible directly with python2.6, python2.4 etc.
I would be stunned if Windows didn't support an equivalent to altinstall.

Are there any Windows users out there who can confirm that the installer
does or doesn't leave existing versions in place?

 

[David Robinow]

....
Are there any Windows users out there who can confirm that the installer
does or doesn't leave existing versions in place?

The installer does leave existing versions in place. I have no idea
what the OP is referring to.

 

[Martineau]

I don't know much about the .msi format or how 7-Zip handles it, but
on my XP box, 7-Zip lists a "python" sub-archive (a 7-Zip
"compound"). Within is the python27.chm

My mistake -- you're quite right the .chm *is* in the .msi where you
indicated. FWIW I actually did look in that sub-section before posting
yet somehow missed it. Sorry about that and thanks to all involved for
your help.

 

[Martineau]

 The installer does leave existing versions in place. I have no idea
what the OP is referring to.

Some clarification. I meant installed 2.7 on top of 2.6.x. Doing so
would have interfered with the currently installed version because I
always install Python in the same directory, one named just "Python",
to minimize the number of changes I have to make to to other parts of
the system. Some trivial examples are desktop shortcuts I've set up
which point to the commandline version of the interpreter and another
for the help file. I also believe the Windows installer makes registry
changes that also involve paths to the currently installed version,
which again, is something I wanted to avoid until I'm actually ready
to commit to upgrading.

If there are better ways on Windows to accomplish this, I'd like to
hear about them. I suppose I could use hardlinks or junctions but
they're not well supported on most versions of Windows.

BTW, my original problem -- getting a copy of the Windows format
compiled help file fro v2/7 without installing it has been taken care
by suggestions from other, so this discussion is starting to way off-
topic...

Thanks,
Martin

 

[Martin v. Loewis]

Benjamin (or anyone else), do you know where I can get the Compiled

Windows Help file -- python27.chm -- for this release?

I have now put that file separately on the release page.

Regards,
Martin

 

[David Bolen]

Some clarification. I meant installed 2.7 on top of 2.6.x. Doing so
would have interfered with the currently installed version because I
always install Python in the same directory, one named just "Python",
to minimize the number of changes I have to make to to other parts of
the system.

That's fine, you're just making a conscious choice to only support
(yourself) a single version installed at a time.

I tend to need multiple versions around when developing, so I keep a
bunch of versions all installed in separate directories as \Python\x.y
(so I only have a single root directory). With 2.7, my current box
has 6 Python interpreters (2.4-3.1) installed at the moment.

I use Cygwin (wouldn't try to work on a Windows system without it), so
just use bash aliases to execute the right interpreter, but a batch
file could be used with the cmd interpreter, and you could link GUI
shortcuts to that batch file.

Not sure there's a good solution to your help file link, other than
the existing Start menu links installed per Python version. Even with
local links you'd probably want separate links per version anyway
since they're different documents.

Of course, since this started by just considering installing it to get
at a single file (which I know was since solved), it's probably an
acceptable use case for violating your standard policy and picking a
different directory name just in this case, and then blowing it away
later.

I also believe the Windows installer makes registry
changes that also involve paths to the currently installed version,
which again, is something I wanted to avoid until I'm actually ready
to commit to upgrading.

The path information installed in the registry
(Software\Python\PythonCore under HLKM or HKCU depending on
installation options) is structured according to major.minor release
(e.g., 2.6 vs. 2.7 are distinct), but you're right Windows only
supports one file extension mapping, so by default the last Python to
be installed gets associated with .py/.pyw etc... by default.

But you can optionally disable this during installation. On the
customize screen showing during installation. de-select the "Register
Extensions" option, and the active install won't change any existing
mappings and thus have no impact on your current default installation.

If there are better ways on Windows to accomplish this, I'd like to
hear about them. I suppose I could use hardlinks or junctions but
they're not well supported on most versions of Windows.

If you're still using the basic Windows command prompt or GUI links
then a batch file is the simplest way to go. With something like
Cygwin (which I personally would never do without), then you have a
variety of techniques available including links, shell aliases, etc...

-- David

 

[Tim Golden]

I tend to need multiple versions around when developing, so I keep a
bunch of versions all installed in separate directories as \Python\x.y
(so I only have a single root directory). With 2.7, my current box
has 6 Python interpreters (2.4-3.1) installed at the moment.

I use Cygwin (wouldn't try to work on a Windows system without it), so
just use bash aliases to execute the right interpreter, but a batch
file could be used with the cmd interpreter, and you could link GUI
shortcuts to that batch file.

I, too, have multiple versions installed -- newer ones for running code
I haven't upgraded; older ones for compatibility testing where needed.
I just install to the default c:\pythonxy directories (although I like
the idea of a common root) and I put NTFS hardlinks into my general
c:\tools directory which is on the path. The out-of-context hardlinks
work because of the registry settings which pick up the correct context
for each version.

(I've never quite clicked with cygwin or MingW despite giving them
several goes on the basis of others' enthusiasm...)

TJG

 

[imageguy]

I, too, have multiple versions installed -- newer ones for running code
I haven't upgraded; older ones for compatibility testing where needed.
I just install to the default c:\pythonxy directories (although I like
the idea of a common root) and I put NTFS hardlinks into my general
c:\tools directory which is on the path. The out-of-context hardlinks
work because of the registry settings which pick up the correct context
for each version.

Sorry to be daft here, but what do you mean by a "hardlink" ?
A windows "Shortcut" ?

I have just installed 2.7 and want to start upgrading some code, but
alas still want to maintain some 2.5 code too.

 

[Martin v. Loewis]

Am 08.07.2010 04:17, schrieb imageguy:

Sorry to be daft here, but what do you mean by a "hardlink" ?
A windows "Shortcut" ?

No, he means a hardlink (file system level directory entries pointing to
the same MFT record number), as created by "fsutil hardlink",
"mklink /H", or Cygwin "ln".

Regards,
Martin

 

[Tim Golden]

Sorry to be daft here, but what do you mean by a "hardlink" ?
A windows "Shortcut" ?

I have just installed 2.7 and want to start upgrading some code, but
alas still want to maintain some 2.5 code too.

Hardlinks have always been present on NTFS, just not very widely advertised.
They are a way of saying that *this* file and *that* file are actually the
*same* file. (They must be on the same volume as they underlying
implementation
relies on pointing to the volume's master index -- the MFT).

They're not copies: if one changes, the other changes.
They're not shortcuts, which are a Shell (ie Desktop) mechanism, not a
filesystem one

I have hardlinks called python26.exe, python31.exe, etc. which point to
c:\python26\python.exe, c:\python31\python.exe etc. and also
a python3.exe which is another link to c:\python31\python.exe but which will
move when python 3.2 is released.

However, this is simply a convenience I use. It's perfectly possible to have
and to use several versions of Python concurrently without this. How you do
it depends on your working practice: whether you use an IDE or
double-click on
..py files or run from a cmd window, etc.

TJG

 

[Aahz]

Sorry to be daft here, but what do you mean by a "hardlink" ?
A windows "Shortcut" ?

Just to be clear, a hardlink on NTFS functions almost exactly the same as
a hardlink on a Unix filesystem -- it's a pointer to the same underlying
file.

 

[Grant Edwards]

Just to be clear, a hardlink on NTFS functions almost exactly the same as
a hardlink on a Unix filesystem -- it's a pointer to the same underlying
file.

A windows shortcut is more like a Unix symlink (symbolic link), where
the real destination path is a string contained in the link/shortcut
file. That destination path is then evaluated and "dereferenced" when
the link/shortcut is accessed.

 

[Stephen Hansen]

A windows shortcut is more like a Unix symlink (symbolic link), where
the real destination path is a string contained in the link/shortcut
file. That destination path is then evaluated and "dereferenced" when
the link/shortcut is accessed.

This is true, but a windows shortcut is more limited: its a feature of
higher level code in the UI (I don't want to say just Explorer, as the
standard dialogs deal with it too), and not the filesystem. So it only
really works if there's a user specifically clicking through it -- or if
you have code made to look for the .lnk files, parse them (they're
really simple INI files) and deference it manually. At least, IIUC.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMNe7fAAoJEKcbwptVWx/lZDQIAI6i7xlGOZ4GFkr/LSypGv81
QtrdYhhKlSVQRSYkgPUB82/n0WDn6UtzbFVJU9Pb+Q9fcpzt5bMLKprDty9oinTQ
R5XSKRYU2LDMfSi+9u9S4iCR+7eGHujJbfoOkGFtMwQ2Waa82ypDrsAmDGw9rHzd
Z3mfdcuqAPUpDTgM8lgkaArsHMB+84SHQ+lXhrk2efrn26LuOBrbEpQ/GX5ewVW3
IYA0UsC3LmIcLj1TsMt1l7D/cPT8Vpid2CpPNKzigp65utdtJQ5vGFsGpAUVRzQS
+kSe54i9y2ZftOxXsM5dQs0GBggLjCpzYjGQv38dh2x9y5Wt5O6SVACFQH83WTo=
=+y5r
-----END PGP SIGNATURE-----

 

[Tim Golden]

A windows shortcut is more like a Unix symlink (symbolic link), where
the real destination path is a string contained in the link/shortcut
file. That destination path is then evaluated and "dereferenced" when
the link/shortcut is accessed.

Goodness knows I'm probably teaching my grandmother etc. etc. but I
would clarify that a Windows shortcut is a *shell* concept: from the
NTFS point of view, it's just a something.lnk with some opaque contents.

A (>= Vista) NTFS smbolic link is documented as designed "to function just
like Unix links".

TJG