This seems to happen whenever we do a new release (we've had a couple of
emails to webmaster(a)python.org about it since 2.6.5 was released). The
main download page for Python has a broken link for the Mac installer
(because it hasn't been built yet I assume):
The link 404s, with no explanation or alternate link - so for the casual
user who wants to install Python 2.6 on Mac OS X they are
Not being able to provide a mac installer at the same time as other
platforms is one thing (and I accept that is unavoidable), breaking the
download links for Mac users for unspecified lengths of time is just bad
practise. If we create a new stable release without a Mac installer can
we at least provide a brief explanation and link to the *previous
version* until the new version is ready?
All the best,
-------- Original Message --------
Subject: Broken link to down
Date: Sun, 21 Mar 2010 13:40:36 +0000
From: Ben Hodgson <ben(a)benhodgson.com>
In case you don't know, the link on http://www.python.org/download/ to
the Python 2.6.5 Mac Installer Disk Image
May I have enhanced permissions on the bug tracker, so that I can perform
the following tasks?
- Assign issues to myself that I plan to write a patch for
- Update the Stage to "patch review" after writing a patch
- Occasional bug triage
My login name on the tracker is "stutzbach".
I only find the time to produce patches once in awhile, but when I have the
time I usually produce more than one. Assigning bugs to myself will
increase my motivation to write patches, as I will feel that I've made a
commitment to fixing them.
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
I am sorry if this is not the right list to post some questions. I have a simple question please and would appreciate some answers as I am new to Python.
I have 2 D array: test = [[A,1],[B,2],[A,3][B,4]]
I want to arrang this array in different arrays so each one will have what is attached to. For example I want the output:
A =[1,3] and B=[2,4]
Currently, the 'default' Priority for new tracker issues is '- no
selection -'. This is, I believe, widely understood to be equivalent to
'normal'. Consequently, almost no one bothers to make a selection. This
applies even to experienced people like (in the last hour) Jesus Crea
(#8536), Eric Smith (*8538), and Mark Dickenson (*8540).
If possible, I think 'normal' should be the default in the hox or else
there should be some sort of auto replacement.
Currently, there are tracker maintainers spending time doing the
replacement by hand. Sean R. has even requested privileges for someone
in part just so he can do so too. Such activily strikes me as silly. I
think it should be made unnecessary either by improving the tracker or
by being declared to be unneeded. The only time a person should set the
field to change it from normal (or to reverse such a change).
Terry Jan Reedy
Many Python module developers do not want their work to be distributed
by Debian (and probably by other Linux distributions), here's a list of
hints that will help you accomplish that goal:
* depend on unstable or unreleased software (even if you
use it only to generate docs or do unit tests),
* bundle local copies of 3rd party modules and do not send your changes
upstream, never document your changes in upstream code,
* break API in every release,
* break ABI in every second release,
* do not ship all files needed to build the extension/docs/etc. in the
* do not list required dependencies in install_requires or INSTALL/README
* if you list them, make sure you set the minimum required version to the
one released yesterday, even if module works fine with version released
2 years ago,
* create your own versioning schema (do not follow PEP-0386!), change it
from time to time,
* hardcode paths in the code and do it in as many places as you can
(add new ones every few releases, that will teach them to not patch
* ignore FHS (you're using Windows after all); use __file__ whenever
* make sure there's nothing about license in LICENSE file or in file
* if you have some free time, create your own license, avoid
* if you use GPL, do not include full content of the license in the
* release different tarballs with the same version number,
* use waf as build-system,
* release a new version without testing it with your own unit tests first
to ensure that it will fail when your favourite Debian Developer tries
to build it
Piotr Ożarowski Debian GNU/Linux Developer
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Python contains code specific to OS/2 (eg. see Modules/posixmodule.c). I read
in Wikipedia that IBM has discontinued OS/2 support in 2005. Do we still
support OS/2 or not?
I'm asking because I'm working on a patch modifying OS2 specific code, but I'm
unable to compile nor test my changes. And on IRC we told me that nobody
If we support OS/2, we need a buildbot.
My patch: http://bugs.python.org/issue8391 (os.execvpe() doesn't support
surrogates in env).
steven.bethard(a)gmail.com made a very nice module for me to enhance argparse
called argparse_bool.py, which contains ConfigureAction. This will allow a
boolean value to be set very like the gnu configure style:
I've been happily using it, and I think it would be of sufficient general
interest to include it with the standard library.
2010/4/22 P.J. Eby <pje(a)telecommunity.com>:
> At 10:54 AM 4/22/2010 +0200, Tarek Ziadé wrote:
>> I think I went through all the latest feedback regarding PEP 376.
>> There will be still some work of course, on the implementation side
>> (for instance the Zip issues described by PJE).
>> But I would like to go ahead and propose PEP 376 for acceptance.
> One final (optional) question/suggestion... should we change from this (in
> RECORD files):
> to this:
> In this way, reader code can be written as:
> for path, hash, size in csv.reader(...):
> It's not a high-priority thing, but if anybody is writing code to parse
> RECORD files outside the provided API implementation (eg. system packaging
> tool authors), they'll probably appreciate this. ;-)
Yes, of course. the RECORD file is supposed to be iterable using the csv reader,
so that's a mistake in the PEP.
Thanks for noticing, I'll fix it later today
Tarek Ziadé | http://ziade.org