Mailman 3 October 2003 - Python-Dev

RE: copysort patch, was RE: [Python-Dev] inline sort option
by Chih-Chung Chang 29 Oct '03

29 Oct '03

Hi, Raymond Hettinger wrote: > Okay, this is the last chance to come-up with a name other than > sorted(). > > Here are some alternatives: > > inlinesort() # immediately clear how it is different from sort() > sortedcopy() # clear that it makes a copy and does a sort > newsorted() # appropriate for a class method constructor > > > I especially like the last one and all of them provide a distinction > from list.sort(). > How about adding a builtin function sort() which returns the sorted version of the input list? L.sort() # sort in-place sort(L) # return sorted copy Regards, Chih-Chung Chang

1 0

RE: [Python-Dev] Decimal.py in sandbox
by Batista, Facundo 29 Oct '03

29 Oct '03

Aahz wrote: #- The first thing you should do is talk with Eric Price #- (eprice(a)tjhsst.edu), author of the code. You don't need to #- use SF for #- now; CVS should be fine, but you should find out whether #- Eric would like #- to approve changes first. Eric Price wrote: #- Not really-- since school started, I haven't had much time #- to spare. #- I'll probably look over the changes at some time, but I #- wouldn't want to #- keep them waiting. So, to who may I send the changes? Should I send the whole staff at the end of the work, or keep feeding small changes? Should I send by email the diff results? Thanks for the answers. . Facundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias.

3 3

Re: [Python-checkins] python/dist/src/Python bltinmodule.c, 2.292.10.1, 2.292.10.2
by Guido van Rossum 29 Oct '03

29 Oct '03

> Modified Files: > Tag: release23-maint > bltinmodule.c > Log Message: > changed builtin_sum to use PyNumber_InPlaceAdd -- unchanged semantics but > fixes performance bug with sum(lotsoflists, []). I think this ought to be reverted, both in 2.3 and 2.4. Consider this code: empty = [] for i in range(10): print sum([[x] for x in range(i)], empty) The output used to be: [] [0] [0, 1] [0, 1, 2] [0, 1, 2, 3] [0, 1, 2, 3, 4] [0, 1, 2, 3, 4, 5] [0, 1, 2, 3, 4, 5, 6] [0, 1, 2, 3, 4, 5, 6, 7] [0, 1, 2, 3, 4, 5, 6, 7, 8] But now it is: [] [0] [0, 0, 1] [0, 0, 1, 0, 1, 2] [0, 0, 1, 0, 1, 2, 0, 1, 2, 3] [0, 0, 1, 0, 1, 2, 0, 1, 2, 3, 0, 1, 2, 3, 4] [0, 0, 1, 0, 1, 2, 0, 1, 2, 3, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 5] [0, 0, 1, 0, 1, 2, 0, 1, 2, 3, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 6] [0, 0, 1, 0, 1, 2, 0, 1, 2, 3, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 6, 0, 1, 2, 3, 4, 5, 6, 7] [0, 0, 1, 0, 1, 2, 0, 1, 2, 3, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 6, 0, 1, 2, 3, 4, 5, 6, 7, 0, 1, 2, 3, 4, 5, 6, 7, 8] --Guido van Rossum (home page: http://www.python.org/~guido/)

5 22

RE: [Python-Dev] Decimal.py in sandbox
by Batista, Facundo 29 Oct '03

29 Oct '03

Aahz wrote: #- The first thing you should do is talk with Eric Price #- (eprice(a)tjhsst.edu), author of the code. You don't need to #- use SF for #- now; CVS should be fine, but you should find out whether #- Eric would like #- to approve changes first. OK, I'll mail him. #- There's no reason you can't start with a pre-PEP now; I'd focus on #- interface (i.e. the question of what ``Decimal(5)/3`` and #- ``5/Decimal(3)`` should do -- my personal take at this point is that #- both ought to fail). Well, there's wide discussion about this when I posted the pre-PEP of Money. The raisoning of majority is that when two operands are of different type, the less general must be converted to the more general one: >>> myint = 5 >>> myfloat = 3.0 >>> mywhat = myint + myfloat >>> type(mywhat) <type 'float'> With this in mind, the behaviour would be: >>> myDecimal = Decimal(5) >>> myfloat = 3.0 >>> mywhat = myDecimal + myfloat >>> isinstance(mywhat, float) True and >>> myDecimal = Decimal(5) >>> myint = 3 >>> mywhat = myint + myDecimal >>> isinstance(mywhat, Decimal) True but I really don't know if the first behaviour should be extended to the latter two. Anyway, I'll post the pre-PEP and we all should see, :) Thanks. . Facundo

2 1

RE: [Python-Dev] RE: [Python-checkins]python/nondist/pepspep-0323.txt, NONE, 1.1 pep-0000.txt, 1.254, 1.255
by Delaney, Timothy C (Timothy) 29 Oct '03

29 Oct '03

> From: Alex Martelli [mailto:aleaxit@yahoo.com] > > Come to think of this, there may be other use cases for this > general approach than "random iterators". Do you think that > an iterator on a callable *and args for it* would live well in > itertools? That module IS, after all, your baby... Hmm - I like the idea of this. import itertools d10 = itertools.icall(random.randint, (1, 10,)) for i in range(10): print d10.next() Tim Delaney

1 0

RE: Adaptation and typecasting (was Re: [Python-Dev] replacing 'global')
by Delaney, Timothy C (Timothy) 29 Oct '03

29 Oct '03

> From: Phillip J. Eby [mailto:pje@telecommunity.com] > > At 09:56 AM 10/28/03 +0100, Alex Martelli wrote: > >AND, adaptation is not typecasting: > >e.g y=adapt("23", int) should NOT succeed. > > And, why do you consider adaptation *not* to be typecasting? > I always > think of it as "give me X, rendered as a Y", which certainly > sounds like a > description of typecasting to me. Because (IMO anyway) adaption is *not* "give me X, rendered as Y". Adaption is "here is an X, can it be used as a Y?". They are two distinct concepts, although obviously there are crossover points. A string cannot be used as an int, although an int can be created from the string representation of an int. Adaption should not involve any change to the underlying data - mutating operations on the adapted object should (attempt to) mutate the original object (assuming the adapted object and original object are not one and the same). Tim Delaney

1 0

PEP 322: Generator Expressions (implementation team)
by Raymond Hettinger 29 Oct '03

29 Oct '03

Guido has accepted the generator expressions pep, so it's time for me to form an implementation team. Any volunteers are welcome to email me directly. Alex, Brett, Neal, Jeremy? Raymond

2 1

Re: the "3*x works w/o __rmul__" bug
by Fernando Perez 29 Oct '03

29 Oct '03

Hi all, I just wanted to add a small comment on this discussion, which I'd been following via the newsgroup mirror. Python is picking up a lot of steam in the scientific computing community, and in science it is quite common to encounter non-commutative multiplication. Just to remind Guido from his old math days :), even for square matrices, AB!=BA in most cases. The Matrix class supplied with Numpy is one example of a widely used library which implements '*' as a non-commutative multiplication operator. From what I've read, I realize that this is quite a subtle and difficult bug to treat. I just wanted to add a data point for you folks to consider. Please don't dismiss non-commutative multiplication as too much of an obscure corner case, it is a daily occurrence for a growing number of python users (scientists). Thanks, Fernando.

3 3

[Python-Dev] RE: [Python-checkins] python/nondist/peps pep-0323.txt, NONE, 1.1 pep-0000.txt, 1.254, 1.255
by Raymond Hettinger 29 Oct '03

29 Oct '03

Excellent PEP! Consider adding your bookmarking example. I found it to be a compelling use case. Also note that there are many variations of the bookmarking theme (undo utilities, macro recording, parser lookahead functions, backtracking, etc). Under drawbacks and issues there are a couple of thoughts: * Not all iterators will be copyable. Knowing which is which creates a bit of a usability issue (i.e. the question of whether a particular iterator is copyable will come up every time) and a substitution issue (i.e. code which depends on copyability precludea substitution of other iterators that don't have copyability). * In addition to knowing whether a given iterator is copyable, a user should also know whether the copy is lightweight (just an index or some such) or heavy (storing all of the data for future use). They should know whether it is active (intercepting every call to iter()) or inert. * For heavy copies, there is a performance trap when the stored data stream gets too long. At some point, just using list() would be better. Consider adding a section with pure python sample implementations for listiter.__copy__, dictiter.__copy__, etc. Also, I have a question about the semantic specification of what a copy is supposed to do. Does it guarantee that the same data stream will be reproduced? For instance, would a generator of random words expect its copy to generate the same word sequence. Or, would a copy of a dictionary iterator change its output if the underlying dictionary got updated (i.e. should the dict be frozen to changes when a copy exists or should it mutate). Raymond Hettinger

3 9

Re: 2.3.3 plans
by Michael Lauer 29 Oct '03

29 Oct '03

Anthony wrote: >I'm currently thinking of doing 2.3.3 in about 3 months time. My focus >on 2.3.3 will be on fixing the various build glitches that we have on >various platforms - I'd like to see 2.3.3 build on as many boxes as >possible, "out of the box". Does this also include cross compiling? I'm the maintainer of a python-for-arm-linux distribution (http://opie.net.wox.org/python) which is created using the OpenZaurus build infrastructure (http://openzaurus.org). To get Python cross compiled for arm-linux, I did a few (pretty rough) patches which I attached to this message. It would be useful for cross compiling, if (conceptually) the first two could be integrated into Python 2.3.3. Best Regards, Mickey. -- :M: -------------------------------------------------------------------------- Dipl.-Inf. Michael 'Mickey' Lauer mickey(a)tm.informatik.uni-frankfurt.de Raum 10b - ++49 69 798 28358 Fachbereich Informatik und Biologie --------------------------------------------------------------------------

3 2