Re: [Python-Dev] fixing log messages
Fredrik Lundh wrote: > just noticed an embarrasing misspelling in one of my recent checkins, only That's "embarrassing", by the way. You're obviously having a bad spelling day :-) not-throwing-stones-ly y'rs - steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
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 -0 on dropping it. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] synchronized enumerate
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 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] synchronized enumerate
On Sun, Dec 18, 2005, Chris or Leslie Smith wrote: > > 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. python-dev is the wrong place to start discussions like this; please use comp.lang.python. Thanks! -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck." --USENET schmuck (aka Robert Kern) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
> > 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 -0 on dropping it. It's also the only thing that identifes the revision/build precisely, allowing reversion to a known state. John -- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Keep default comparisons - or add a second set?
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 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. (Xhttp://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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Keep default comparisons - or add a second set?
On 12/19/05, Jim Jewett <[EMAIL PROTECTED]> wrote: > 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 dictionaries. While I agree that this is a useful property, and I'd like it to be true, it isn't even today: >>> import Numeric >>> a = Numeric.array((1,2,3)) >>> a array([1, 2, 3]) >>> sorted([a, (1,2,3), 1, 2, '123']) Traceback (most recent call last): File "", line 1, in ? TypeError: function not supported for these types, and can't coerce to supported types >>> a < '123' Traceback (most recent call last): File "", line 1, in ? TypeError: function not supported for these types, and can't coerce to supported types >>> Numeric arrays are the canonical example of an "awkward case" when discussing comparisons... OTOH, I'm not sure I want to see more "awkward cases" added. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] synchronized enumerate
Chris or Leslie Smith wrote: > 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 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 a. What Aahz said (this is more a c.l.p./python-list question than a python-dev one) b. It may be worth finding a way to use itertools.islice on the output of enumerate rather than slicing before the enumeration operation if you want the indices to line up with the original sequence rather than with the slice. Cheers, Nick. P.S. I don't personally track c.l.p. (other than some of the threads that make it to python-url) so cc' my email address if you want to follow up on point b :) -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
John Pinner wrote: > It's also the only thing that identifes the revision/build precisely, > allowing reversion to a known state. How so? - It doesn't identify a build precisely: you may have dynamically-loaded modules that get rebuild even though the build number doesn't change. So a single build number may refer to different sets of code. - it doesn't allow reversion to a known state: I can't even find a meaningful interpretation of such a claim. How would the build allow to revert anything? And what is that anything that it would allow to revert? Reverting doesn't work for source changes, nor for configure options (svn revert allows to do the former, in a limited way; svk allows that in a broader way). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] synchronized enumerate
[Chris or Leslie Smith] > 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. Try rolling your own with izip() and count(): izip(count(start), someslice) Raymond Hettinger ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Keep default comparisons - or add a second set?
Jim Jewett wrote: > Or, at the very least, promote a > *standard* way to say "just get me a canonical ordering of some sort" That would be my preference. Comparison for canonical ordering should be a distinct operation with its own spelling. Then Guido's > Comparisons other than == and != between disparate types will raise an > exception unless explicitly supported by the type can be true without precluding the existence of a canonical ordering. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Keep default comparisons - or add a second set?
On 12/19/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > That would be my preference. Comparison for canonical > ordering should be a distinct operation with its > own spelling. Such as sorted(stuff, key=id)? Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Keep default comparisons - or add a second set?
Michael Urman <[EMAIL PROTECTED]> wrote: > > On 12/19/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > > That would be my preference. Comparison for canonical > > ordering should be a distinct operation with its > > own spelling. > > Such as sorted(stuff, key=id)? I believe that ideally, canonical orderings would be persistant across sessions. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
