Mailman 3 December 2005 - Python-Dev

Re: [Python-Dev] [Doc-SIG] status of development documentation
by Laura Creighton Dec. 21, 2005

Dec. 21, 2005

Whenever people have demanded that I write documentation in html I have always done this: <pre> all my documentation, as output from a text editor. All subsequent formatting to be done by somebody else who doesn't find dealing with html as excruciatingly painful as I do. </pre> I suspect there are lots of people who have concluded that this is all the html that you really need. The question is, are you willing to put up with documentation like this from people? Laura

2 1

hashlib - faster md5/sha, adds sha256/512 support
by Ronald L. Rivest Dec. 21, 2005

Dec. 21, 2005

Hi -- I'm curious as to the status of upgrading cryptographic hash function support in Python, now that md5 and sha1 are both clearly broken (in terms of collision-resistance). The consensus of researchers in this area (at least as expressed at the NIST Hash Function Workshop 10/31/05), is that SHA-256 is a good choice for the time being, but that research should continue, and other alternatives may arise from this research. The larger SHA's also seem OK, but I think will have less demand... … [View More]

5 5

os.startfile with optional second parameter
by Thomas Heller Dec. 21, 2005

Dec. 21, 2005

Would a patch be accepted that implemented an optional second parameter for the os.startfile function on Windows? Sometimes I missed the possibility to write os.startfile("mydocs.pdf", "print") Thomas

1 1

Re: [Python-Dev] Sets are mappings?
by Michael Chermside Dec. 21, 2005

Dec. 21, 2005

Nick Coghlan writes: > Sorry - I meant to indicate that I didn't think the base classes were > necessary because the relevant checks already existed in a "does it behave > like one" sense: > > def is_container(x): [...] > def is_mapping(x): [...] > def is_sequence(x): [...] > def is_multiarray(x): [...] That sounds much more reasonable to me, although I'd also mention that it is unusual to need to test for the "protocol … [View More]

1 0

Keep default comparisons - or add a second set?
by Jim Jewett Dec. 21, 2005

Dec. 21, 2005

PEP 3000 now suggests that dropping default comparison has become more than an idle what-if. Unfortunately, one very common use case of comparisons is to get a canonical order. If the order is sensible, all the better, but that is not strictly required. One of Python's selling points (especially compared to Java) is that getting a canonical order "just works", even if the objects being sorted are not carefully homogenized by hand. Python itself relies on this when comparing same-length … [View More]dictionaries. There are times when a specific comparison doesn't make sense (date vs a datetime that it includes), but these are corner cases best handled by the specific class that understands the specific requirements -- classes that already have to override the comparison operators anyhow. Even the recently posted "get rid of default comparisons" use case is really just an argument to make the canonical ordering work better. The problem Jim Fulton describes is that the (current default) canonical order will change if objects are saved to a database and then imported to a different session. Removing default comparisons wouldn't really help much; the errors would (sometimes) show up at saving instead of (maybe) at loading, but the solution would still be to handcode a default comparison for every single class individually. I don't think anyone wants a smorgasbord of inconsistent error-prone boilerplate code. (X<Y but also Y<X, because they used different default comparisons, so it matters which one gets asked.) Even careful coders will sometimes get burned by whether to sort based on id(obj) or (obj.__class__, id(obj)) Guido has already rejected a standard mixin class. Today's solution is to write the default comparison once and let everything "inherit" it. The persistence layers need an improved default comparison -- but they can provide their own via wrapper objects, since they control the save mechanism. To be honest, this may be the only reasonable solution; if objects are saved with their original id and they use that for comparison, then you can continue a session, but you still have to worry about having the id reused in a later session. If ids are timestamped, you need to worry about importing objects from multiple original processes, or different machines, or ... and the comparison gets slow, for something that won't provide any benefit to smaller applications. Go ahead and tweak the default comparisons; there is room to argue about whether (1,2) < [3,4] < (5,6) should evaluate as true. Go ahead and include more information, if it doesn't slow down the common case; it might help the simpler databases. But please don't make that expression throw an exception. (Or, at the very least, promote a *standard* way to say "just get me a canonical ordering of some sort" -- which we can write today with "sorted()".) --------------------- References: Guido agrees to removing the default comparisons: http://www.python.org/peps/pep-3000.html """ Comparisons other than == and != between disparate types will raise an exception unless explicitly supported by the type [6] """ and the more recent reference at http://mail.python.org/pipermail/python-dev/2005-November/057938.html. Jim Fulton says that the _current_ default breaks for persistence. http://mail.python.org/pipermail/python-dev/2005-November/057924.html Guido rejects a comparison mixin http://mail.python.org/pipermail/python-dev/2005-November/057925.html [View Less]

9 11

[OT] Fwd: a new python port: iPod
by Neal Norwitz Dec. 20, 2005

Dec. 20, 2005

I know this is OT, but I thought y'all might find this interesting. -- n ---------- Forwarded message ---------- From: jack <jack(a)gulcas.org> To: webmaster(a)python.org Hi, I saw in http://www.python.org/download/download_other.html that people notify python ports to other platforms/devices. I ported python to iPod, and would be great that this port will appear in this section too. For more info about python port to Apple iPod see: http://www.ciberjacobo.com/en/linux_on_ipod.… [View More]

1 0

(no subject)
by RASHMI TANK Dec. 20, 2005

Dec. 20, 2005

sir i have taken softwer from icashline.com that is mass mailing softwere is worldcast that is not running it is showing that I/O PROBLEM OR MEDIA PRO BLEM. PLEASE HELP ME. Send instant messages to your online friends http://in.messenger.yahoo.com

1 0

Re: [Python-Dev] Expose Subversion revision number to Python
by Phillip J. Eby Dec. 20, 2005

Dec. 20, 2005

At 07:42 AM 12/16/2005 -0800, Michael Chermside wrote: >Phillip writes: > > FYI, this is not the true revision number; it's only the revision number in > > which the directory was last modified, not the latest revision number > > within the tree. > >Barry responds: > > I opted against that for several reasons. First, I wanted to keep the > > patch as simple as possible. Second, I didn't want to depend on Python > > already being built [...] Third, … [View More]

10 32

synchronized enumerate
by Chris or Leslie Smith Dec. 19, 2005

Dec. 19, 2005

I see that there is a thread of a similar topic that was posted recently ( enumerate with a start index ) but thought I would start a new thread since what I am suggesting is a little different. Whenever I use enumerate, I am doing so because I will use the index to access some other element in the list (the previous or next, usually) while also looking at the element that is returned from enumerate. Several times, however, in the development phase of the work, I end up sending a subset of … [View More]the list at hand and then get bitten by the fact that the indices returned by enumerate are not the indices of the original list, they are the indices of the slice that I sent. e.g. in the following, "0" is the first index but I wanted it to be 3 ### >>> start=3 >>> count=5 >>> for i, x in enumerate(range(10)[start:start+count]): ... print i, x ... 0 3 1 4 2 5 3 6 4 7 >>> ### What I would propose is an optional slice argument to the enumerate routine that would allow enumerate to return elements that are synchronized with the original list list/iterable elements. e.g. def enum(l, slc=None): if slc==None: for i, dat in enumerate(l): yield i, dat else: if type(slc)<>slice: raise TypeError, "slc must be a valid slice" start, step = slc.start, slc.step # we need actual values for start and step, so check for None # and supply defaults if step==None:step=1 if start==None: if step>0: start=0 else: start=-1 for i, dat in enumerate(l[slc]): j = i*step+start if j<0: j+=len(l) yield j, dat ### >>> for i, x in enum(range(10), slice(start, start+count)): ... print i, x ... 3 3 4 4 5 5 6 6 7 7 >>> for i, j in enum(range(10), slice(None,None,-3)): ... print i,j ... 9 9 6 6 3 3 0 0 >>> ### An advantage to processing the iteratable with a slice argument is that then the slice information is given only once and it can do 2 things: slice the original iterable and provide the synchronized indices. NOTE: the same thing that I am proposing could also be done with count and izip if count had a step argument, but it's more ackward and you have to supply the same information in two places: >>> def count(start, step=1): ... for i in itertools.count(start): ... yield start+(i-start)*step ... >>> >>> start=3; stop=None; step=2 >>> for i,j in itertools.izip(count(start, step), itertools.islice(range(10), start, stop, step)): ... print i,j ... 3 3 5 5 7 7 9 9 A "P.S." question for this email is, was there a reason to leave step out of itertools.count? /c [View Less]

4 3

Re: [Python-Dev] Expose Subversion revision number to Python
by John Pinner Dec. 19, 2005

Dec. 19, 2005

> > Barry Warsaw wrote: > >>On Sun, 2005-12-18 at 19:19 +0100, "Martin v. L?wis" wrote: >> >> >> >>>It stopped counting builds on Windows quite some time ago; perhaps it >>>is best to drop the build number entirely? >> >> >>I think so, because it doesn't really convey anything useful. >> > > I thought it was more succinct than the build-date when rebuilding > continuously during testing, but I guess I'm only … [View More]

2 1