Re: [Python-Dev] Rationale for sum()'s design?
Guido van Rossum wrote:
On Tue, 15 Mar 2005 00:05:32 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
... try:
... value += first
... except TypeError:
... raise TypeError("Cannot add first element %r to initial value %r" %
(first, value))
No, no, no! NO! Never catch a general exception like that and replace
it with one of your own. That can cause hours of debugging pain later
on when the type error is deep down in the bowels of the += operation
(or perhaps deep down inside something *it* invoked).
Ouch. Obviously, I hadn't thought about that. . .
Wasn't there a concept floating around some time ago to support exception
chaining, so additional context information could be added to a thrown
exception, without losing the location of the original problem?
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
Brian Sabbey wrote:
Samuele Pedroni wrote:
OTOH a suite-based syntax for thunks can likely not work as a
substitute of lambda for cases like:
f(lambda: ..., ...)
where the function is the first argument, and then there are further
arguments.
I do not see why you say suite-based thunks cannot be used in the case
in which the function takes more than one argument. Using the syntax I
described earlier, they work in just that way:
def pickled_file(thunk, name):
...
new_data = thunk(pickle.load(f))
...
with greetings from pickled_file('greetings.pickle'):
...
value greetings
One can make an analogy with "self". Both the thunk and self can be
passed automatically as the first argument, and further arguments can
follow. In this way, functions that already take a thunk as a first
argument (such as sort) can be re-used without modification.
Of course now one has a problem with things that take functions as last
arguments, wich if I rembember correctly is the natural position in
Ruby. Unless the syntax involve placeholders (likely icky) one is going
to have this kind of limitations. My point is that a suite-based syntax
can only be a half substitute for lambda and anyway requiring a suite
seems overkill and unnatural for the just 1 expression case, for example
predicates. IOW a suite-based syntax is not a lambda killer in itself, I
would not try to stress that point.
Apart this one very hard problem, it would be nice to be able to define
and pass more thunks simultaneously. In particular a more concise
syntax for
def setx(self, v): self._x = v
def getx(self): return self._x
x = property(getx,setx)
was considered in the past discussions about the topic a worthy goal.
Here I can make another analogy with self. Just as python does not give
syntactic support for multiple dispatch because (I assume) it would
require major syntax changes
multiple dispatch has nothing to do with syntax, in fact usual call
syntax is sufficient, and people do use multiple dispatch sometimes,
and decorators now can be even used to sugar up the definition side
of it.
for something that would be rarely used, I
do not think
well that's up to discussion to discover
it is worth it to give syntactic support for multiple
thunks. If only a fraction "epsilon" of functions take a single thunk,
then I would guess that "epsilon**2" take two thunks, and it is not
worth creating syntax for such a small number of cases, especially if
that syntax compromises what would otherwise be a much cleaner syntax
for the single thunk case.
well, but this is stated without even trying to come up with a syntax
for that case. Notice that the first time around Guido himself would
have preferred if achievable a multithunk syntax, he obviously can have
changed his mind. But, yes, syntax vs expressivity is the key issue here.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
Guido van Rossum wrote: I think the conclusion should be that sum() is sufficiently constrained by backwards compatibility to make "fixing" it impossible before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is only used for empty lists. Two questions about this: 1. When omitting the second argument, would supplying an empty list return 0, None or raise an exception? The last seems most reasonable, as otherwise the function is guessing about what the programmer wants. 2. How would the initial value that forms the basis of summation be built for non-empty sequences? The first element can't be used directly, as that would mutate the first element for a sequence of lists or other mutable objects. Using the default constructor for the type of the first element in the iterable has its own problem. With the second argument being ignored for non-empty iterables, it makes it impossible to use sum() with classes that do have an additive identity, but it isn't created by the default constructor. At the moment, such classes can be used by supplying the additive identity as the second argument to sum(). Both of the above cases can be supported by an approach that says: a. If a second argument is not supplied, and the iterable is empty, raise an exception. b. If a second argument is not supplied, and the iterable is not empty, use the default constructor of the type of the first argument as the initial value c. If a second argument is supplied, and the iterable is empty, return the second argument. d. If a second argument is supplied, and the iterable is not empty, use the second argument as the initial value. This scheme can be made backwards compatible with the current sum() by switching point a. from 'raise an exception' to 'return zero'. With the above compatibility change, getting all the way back to the existing sum() behaviour only requires changing point b. to say "use zero as the initial value" Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (no subject)
Phillip J. Eby wrote: I discussed this approach with Guido in private e-mail a few months back during discussion about an article I was writing for DDJ about decorators. We also discussed something very similar to 'update_meta()', but never settled on a name. Originally he wanted me to PEP the whole thing, but he wanted it to include optional type declaration info, so you can probably see why I haven't done anything on that yet. :) However, if we can define a __signature__ format that allows for type declaration, I imagine there'd be little problem with moving forward on it. But one of the reasons for providing 'update_meta' is so that additional metadata (like __signature__) can later be added transparently. Does deciding whether or not to supply the function really need to be dependent on whether or not a format for __signature__ has been chosen? Cheers, Nick. P.S. the patch is currently deficient in the test and documentation departments, so it's formally incomplete, but I figure it makes sense to finish the discussion before sorting those out. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
On Tuesday 2005-03-15 01:57, Guido van Rossum wrote: > I think the conclusion should be that sum() is sufficiently > constrained by backwards compatibility to make "fixing" it impossible > before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is > only used for empty lists. Why's that better than having the 2nd argument only *needed* for empty lists, but *used* whenever it's given? -- g ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Rationale for sum()'s design?
Tim writes: > I'd personally be delighted if sum() never worked on anything other > than numbers. Guido writes: > I think the conclusion should be that sum() is sufficiently > constrained by backwards compatibility to make "fixing" it impossible > before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is > only used for empty lists. Guido, I find myself far more convinced by Tim's suggestion than yours. This all started with your claim that sum() was a replacement for most reduce() uses. We all agree that it works fine for summing up numbers. We all agree it DOESN'T work for any case where the operator isn't __add__. So trying to make it work well for non-numbers is just arguing over whether it replaces 75% of all reduce() uses, or 85% of them. Who cares? Remember, *ANY* use of sum() can be replaced by a simple, readable, three line for loop: total = for i in total += i And for that matter, other uses of reduce are similarly easy to write as a loop. I'm not saying reduce() is useless, just that it's not worthwhile to expend effort trying to cover every last use case with things like sum() or product() -- one can always write the loop instead. What I think is MORE important is that sum() have predictable behavior in the degenerate cases. And by "predictable", I mean predictable by a newbie user or one someone who hasn't looked at the docs for sum() for the past year and mostly remembers what it does only because the name is so blatantly obvious. _IF_ we follow Tim's advice and think of sum() as designed to add up numbers (as the name implies), then the corner cases are obvious: summing a list of 1 item should return the item, and summing a list of 0 items should return 0. If we think of sum as a form of reduce() that operates only on the __add__ operator, then we need to make other choices for these corner cases, and the people using it to add numbers will suffer the small indignity of having to recall how the corner case works. Honestly, the only case I even remotely care about is concatenating strings -- as far as _I_ am concerned, everyone else can just write out the loop or provide their own "sum_matrix()" method. And if I understand correctly, there's no plan to make sum() "just work" for concatenating strings (besides which, we'd still need to handle the empty list). So I'm in favor of REMOVING the second argument of sum() for python 3000, unless it was kept purely for "backward compatibility" reasons, which would be defeated by changing it's behavior. (And if this doesn't convince you, then so be it... this isn't a particularly important issue.) -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
On Tue, 15 Mar 2005 22:21:07 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I think the conclusion should be that sum() is sufficiently > > constrained by backwards compatibility to make "fixing" it impossible > > before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is > > only used for empty lists. > > Two questions about this: > > 1. When omitting the second argument, would supplying an empty list return 0, > None or raise an exception? Good question... > The last seems most reasonable, as otherwise the function is guessing about > what > the programmer wants. OTOH 0 is more compatible and None is a strong candidate too... > 2. How would the initial value that forms the basis of summation be built for > non-empty sequences? Here's you're way off. There's never any use of "+=", so never any need to create a new object. The algorithm I had in mind was: - if empty, return 2nd arg - if one item, return that - if more than one item (A, B, C, ...) return (...((A + B) + C) + ...) But I'm not so sure now. Thinking ahead to generic types, I'd like the full signature to be: def sum(seq: sequence[T], initial: T = 0) -> T. and that's exactly what it is today. Conclusion: sum() is perfect after all! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Rationale for sum()'s design?
Title: RE: [Python-Dev] Rationale for sum()'s design? [Guido van Rossum] #- > 1. When omitting the second argument, would supplying an #- empty list return 0, #- > None or raise an exception? #- #- Good question... I'd go for None: - Is a good default for a non-existing argument. - If won't get None from sum() in other case (unless you do sum(None), but you should be aware of that). . Facundo Bitácora De Vuelo: http://www.taniquetil.com.ar/plog PyAr - Python Argentina: http://pyar.decode.com.ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
On Mon, 14 Mar 2005 17:57:42 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Unfortunately this started when I claimed in my blog that sum() was a > replacement for 80% of all reduce() uses. That's probably where the error lies, then. When it was introduced, sum() was for summing numbers. Whether summing numbers is 80% of all uses of reduce or not is debatable, but I can't say I care. But I *do* care that this claim was taken as meaning that sum() was *intended* specifically to replace 80% of all reduce() uses - a clear misinterpretation. > I think the conclusion should be that sum() is sufficiently > constrained by backwards compatibility to make "fixing" it impossible > before 3.0. It seems wrong to be talking about "fixing" sum so soon after it was introduced. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Rationale for sum()'s design?
"Michael Chermside" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Tim writes: >> I'd personally be delighted if sum() never worked on anything other >> than numbers. > > Guido writes: >> I think the conclusion should be that sum() is sufficiently >> constrained by backwards compatibility to make "fixing" it impossible >> before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is >> only used for empty lists. > > Guido, I find myself far more convinced by Tim's suggestion than > yours. I am leaning in that direction too. >This all started with your claim that sum() was a replacement > for most reduce() uses. To me, the proper general replacement for the doubly broken builtin reduce would be a properly-defined functional.reduce (a subject for another post), not a bloated sum ;-) > We all agree that it works fine for summing up > numbers. We all agree it DOESN'T work for any case where the operator > isn't __add__. However, __add__ can be defined to mean anything. I'd hate to see people choosing '+' as an operator symbol merely to get reduction disguised as summation. [snip] > What I think is MORE important is that sum() have predictable behavior > in the degenerate cases. And by "predictable", I mean predictable by > a newbie user or one someone who hasn't looked at the docs for sum() > for the past year and mostly remembers what it does only because the > name is so blatantly obvious. Nick's very unmemorable a,b,c,d rules shows the complications that reduction-disguised-as-summation can lead to. Terry J. Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
[Guido] > > Unfortunately this started when I claimed in my blog that sum() was a > > replacement for 80% of all reduce() uses. [Paul] > That's probably where the error lies, then. When it was introduced, > sum() was for summing numbers. Um, Python doesn't provide a lot of special support for numbers apart from literals -- sum() should support everything that supports the "+" operator, just like min() and max() support everything that supports comparison, etc. > Whether summing numbers is 80% of all > uses of reduce or not is debatable, but I can't say I care. But I *do* > care that this claim was taken as meaning that sum() was *intended* > specifically to replace 80% of all reduce() uses - a clear > misinterpretation. Not intended, but it happens to address many cases. > > I think the conclusion should be that sum() is sufficiently > > constrained by backwards compatibility to make "fixing" it impossible > > before 3.0. > > It seems wrong to be talking about "fixing" sum so soon after it was > introduced. 3.0 is soon?!? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Rationale for sum()'s design?
Title: RE: [Python-Dev] Rationale for sum()'s design? [Guido van Rossum] #- 3.0 is soon?!? *You* should answer this, ;) . Facundo Bitácora De Vuelo: http://www.taniquetil.com.ar/plog PyAr - Python Argentina: http://pyar.decode.com.ar/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
[Guido van Rossum] > Um, Python doesn't provide a lot of special support for numbers apart > from literals -- sum() should support everything that supports the "+" > operator, just like min() and max() support everything that supports > comparison, etc. The discussion in the patch that introduced it may be illuminating: http://www.python.org/sf/724936 >From your (Guido's) first comment there, it seems clear that sum() was originally intended only for numbers. Then it got generalized. Then sequences of strings specifically were disallowed. Then it was suggested that mention of a sequence of lists or tuples be removed from the docs, and that datetime.timedelta() be used in examples where "0" didn't make sense as the identity. Then Alex changed it to disallow any sequence of sequences. Then you suggested either specifically disallowing only sequences of lists, tuples or strings (but allowing all other sequence types as elements), _or_ going back to disallowing only sequences of strings. Alex took the latter suggestion, and that's where it ended. The closest thing to a design rationale I found is Guido's Pronouncement here, and I think it covers most issues raised this time around: http://mail.python.org/pipermail/python-dev/2003-April/034853.html The optional argument was my fault. The rest was Guido's : If we add an optional argument for Tim's use case, it could be used in two different ways: (1) only when the sequence is empty, (2) always used as a starting point. IMO (2) is more useful and more consistent. Nobody opposed that. I remember silently agreeing at the time, just because #2 had precedent in other languages, and seemed easiest to explain: sum(seq, start=0) same-as start + seq[0] + seq[1] + ... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Rationale for sum()'s design?
> OTOH 0 is more compatible and None is a strong candidate too... None is useless as a default return value for summation. Any code outside the summation would have to explicitly test for that value. Stick with zero. Theoretical musings are no reason to make this function hard to use. > But I'm not so sure now. Thinking ahead to generic types, I'd like the > full signature to be: > > def sum(seq: sequence[T], initial: T = 0) -> T. > > and that's exactly what it is today. Conclusion: sum() is perfect after > all! +1 This works for me! I use sum() quite a bit and have had no disappointments with the current API. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
Nick Coghlan wrote:
Guido van Rossum wrote:
On Tue, 15 Mar 2005 00:05:32 +1000, Nick Coghlan
<[EMAIL PROTECTED]> wrote:
... try:
... value += first
... except TypeError:
... raise TypeError("Cannot add first element %r to initial value
%r" % (first, value))
No, no, no! NO! Never catch a general exception like that and replace
it with one of your own. That can cause hours of debugging pain later
on when the type error is deep down in the bowels of the += operation
(or perhaps deep down inside something *it* invoked).
Ouch. Obviously, I hadn't thought about that. . .
Wasn't there a concept floating around some time ago to support
exception chaining, so additional context information could be added to
a thrown exception, without losing the location of the original problem?
Yes, but it didn't go anywhere. See
http://www.python.org/dev/summary/2003-06-01_2003-06-30.html#pep-317 for the
summary.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
Samuele Pedroni wrote: My point is that a suite-based syntax can only be a half substitute for lambda and anyway requiring a suite seems overkill and unnatural for the just 1 expression case, for example predicates. IOW a suite-based syntax is not a lambda killer in itself, I would not try to stress that point. I see your point (also I see Greg Ewing's related point). multiple dispatch has nothing to do with syntax, in fact usual call syntax is sufficient, and people do use multiple dispatch sometimes, and decorators now can be even used to sugar up the definition side of it. But one needs to use decorators or some other mechanism for the sugar, that is all I intended the phrase "does not give syntactic support" to mean. Perhaps "syntactic sugar" is the correct term to have used. for something that would be rarely used, I do not think well that's up to discussion to discover ok well, but this is stated without even trying to come up with a syntax for that case. Notice that the first time around Guido himself would have preferred if achievable a multithunk syntax, he obviously can have changed his mind. But, yes, syntax vs expressivity is the key issue here. Ok. Allow me to try. Up to a choice of (or existence of!) keywords, the simplest to me is: def add(thunk1, thunk2, other): print thunk1(1,2) + thunk2(3,4) + other with x,y from add(100): value x*y also a,b: # yikes?? value a*b # this is thunk2 -Brian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
Eric Nieuwland wrote: The full syntax is: [ f(x) for x in seq if pred(x) ] being allowed to write 'x' instead of 'identity(x)' is already a shortcut, just as dropping the conditional part. That's not the full syntax. The full syntax is [ for in ] where can be an arbitrary expression: and, or, lambda, +, -, ... can be a list of expression, except for boolean and relational expressions (but I think this is further constrained semantically) list a list of tests is optional, and can be another for or if block So a more complex example is [ lambda a: a[x]+y*z for x,y in A for z in B if x > z] (Not that this does what you think it does :-) So that you can write f(x) is just a tiny special case. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
Martin v. Löwis wrote: That's not the full syntax. The full syntax is [ for in ] where can be an arbitrary expression: and, or, lambda, +, -, ... can be a list of expression, except for boolean and relational expressions (but I think this is further constrained semantically) list a list of tests is optional, and can be another for or if block Aren't these names a bit mixed up w.r.t. what's in that position? As far as I know is not a test but a function as it produces any value not just True/False is a list of names, not arbitrary expressions is anything which will produce an iterator Or so I've understood so far. So a more complex example is [ lambda a: a[x]+y*z for x,y in A for z in B if x > z] I'm schocked ;-) --eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
Eric Nieuwland wrote: Martin v. Löwis wrote: That's not the full syntax. The full syntax is [ for in ] where can be an arbitrary expression: and, or, lambda, +, -, ... can be a list of expression, except for boolean and relational expressions (but I think this is further constrained semantically) list a list of tests is optional, and can be another for or if block Aren't these names a bit mixed up w.r.t. what's in that position? The names come directly from the grammar file (Grammar/Grammar) and thus have multiple uses. Basically ignore the actual names and just consider them placeholders. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
On Mar 15, 2005, at 01:16, Tim Peters wrote: [Eric Nieuwland] Perhaps the second argument should not be optional to emphasise this. After all, there's much more to sum() than numbers. [Greg Ewing] I think practicality beats purity here. Using it on numbers is surely an extremely common case. I'd personally be delighted if sum() never worked on anything other than numbers. That makes it easy to understand, easy to document, easy to remember, obvious at first sight, and straightforward to implement. Everything a framework isn't, but it's not a bad thing to have *something* that actually means exactly what it looks like it says <0.5 wink>. I'm reasonably often using sum on lists of datetime.timedelta instances, "durations", which ARE summable just like numbers even though they aren't numbers. I believe everything else for which I've used sum in production code DOES come under the general concept of "numbers", in particular X+0 == X. Unfortunately, this equation doesn't hold when X is a timedelta, as X+0 raises an exception then. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation
Eric Nieuwland wrote:
[ for in ]
Aren't these names a bit mixed up w.r.t. what's in that position?
It comes more-or-less straight out of Grammar/Grammar, so: no,
I don't think so.
As far as I know
is not a test but a function as it produces any value not just
True/False
To quote more of Grammar/Grammar, it is
test: and_test ('or' and_test)* | lambdef
and_test: not_test ('and' not_test)*
not_test: 'not' not_test | comparison
comparison: expr (comp_op expr)*
comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'|'is'|'is' 'not'
expr: xor_expr ('|' xor_expr)*
...
power: atom trailer* ['**' factor]
trailer: '(' [arglist] ')' | '[' subscriptlist ']' | '.' NAME
So a function call is a power is a factor is a term is an arith_expr
is a shift_expr is an and_expr is a xor_expr is an expr is a comparison
is a not_test is an and_test is a test.
is a list of names, not arbitrary expressions
No, it's more than that. I can also be
a, (b, c, (d, e))
But as I said: there are further (semantical) constraints what
kind of expression you can have there.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RE: code blocks using 'for' loops and generators
It may be time to PEP (or re-PEP), if only to clarify what people are actually asking for. Brian Sabbey's example from message http://mail.python.org/pipermail/python-dev/2005-March/052202.html *seems* reasonably clear, but I don't see how it relates in any way to "for" loops or generators, except as one (but not the only) use case. def add(thunk1, thunk2, other): print thunk1(1,2) + thunk2(3,4) + other with x,y from add(100): value x*y also a,b: # yikes?? value a*b # this is thunk2 To make my own understanding explicit: (1) Calls for "Ruby blocks" or "thunks" are basically calls for placeholders in a function. These placeholders will be filled with code from someplace else, but will execute in the function's own local namespace. (2) A function as a parameter isn't good enough, because the passed-in function can't see bindings in the surrounding larger function. (It still sees the lexical scope it which it was defined.) (3) A function as a parameter isn't good enough, because the passed-in function can't modify bindings in the surrounding larger function. (4) A thunk could be used today be creating a string (rather than a pre-compiled function) and substituting in the thunk's string (rather than the code to which it would compile) before execution, though this would be ugly. (5) A thunk *might* be do-able with exec or eval if a function's locals were still a dictionary. (6) This has nothing whatsoever to do with for loops or generators, except as a common use case. In particular, thunks may be used to lock/unlock or unwind-protect some resource. Generators are not the only place this is needed, but they have made the "what do you mean, __del__ might never get called?" problem even worse, and Ruby often solves these with a Ruby Block. (7) A __leave__ or __exit__ special method really turns into another name for __del__. It might still be useful if it came with semantics of "I explicitly don't care what order cycles are broken; call me as soon as my object is garbage and who cares if it gets resurrected." There have been recipes (from Tim?) for emulating this by using a proxy to the resource, so that no __del__ cycles can form. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Rationale for sum()'s design?
Nick Coghlan wrote: Guido van Rossum wrote: No, no, no! NO! Never catch a general exception like that and replace it with one of your own. That can cause hours of debugging pain later on when the type error is deep down in the bowels of the += operation (or perhaps deep down inside something *it* invoked). Ouch. Obviously, I hadn't thought about that. . . Wasn't there a concept floating around some time ago to support exception chaining, so additional context information could be added to a thrown exception, without losing the location of the original problem? Like that? try : (...) except Exception, exception: # Keep the current exception stack and add information to exception. raise Exception( 'Additional exception info... :\n' + sys.exc_info()[0].__name__ + ': ' + str(exception)), None, sys.exc_info()[-1] I made for myself a reraise function that I use a lot for that purpose, but it has some limitations. A standard way to do it would be great. Regards, Nicolas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: comprehension abbreviation (was: Adding any() and all())
Gareth McCaughan wrote:
> Some bit of my brain is convinced that [x in stuff if condition]
> is the Right Syntax and keeps making me type it even though
> I know it doesn't work.
(and I agree with Gareth)
On Monday 2005-03-14 12:42, Eric Nieuwland wrote:
> The full syntax is:
> [ f(x) for x in seq if pred(x) ]
> being allowed to write 'x' instead of 'identity(x)' is already a
> shortcut, just as dropping the conditional part.
I think this is the heart of the disagreement.
Mentally, I'm not collecting some function of x (which happens
to be identity). I am filtering an existing set. Being able to
collect f(x) instead is just a useful but hackish shortcut.
Gareth again:
> and in fact no set theorist would be at all troubled by seeing
>{ x in S : predicate(x) }
> which is the nearest equivalent in mathematical notation
> for the abbreviated comprehension expressions being discussed.
Again, I agree. I think that is what I am unconsciously writing,
by translating the ":" into "if"
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RE: code blocks using 'for' loops and generators
Jim Jewett wrote: It may be time to PEP (or re-PEP), if only to clarify what people are actually asking for. Brian Sabbey's example from message http://mail.python.org/pipermail/python-dev/2005-March/052202.html *seems* reasonably clear, but I don't see how it relates in any way to "for" loops or generators, except as one (but not the only) use case. def add(thunk1, thunk2, other): print thunk1(1,2) + thunk2(3,4) + other with x,y from add(100): value x*y also a,b: # yikes?? value a*b # this is thunk2 To make my own understanding explicit: (1) Calls for "Ruby blocks" or "thunks" are basically calls for placeholders in a function. These placeholders will be filled with code from someplace else, but will execute in the function's own local namespace. (2) A function as a parameter isn't good enough, because the passed-in function can't see bindings in the surrounding larger function. (It still sees the lexical scope it which it was defined.) (3) A function as a parameter isn't good enough, because the passed-in function can't modify bindings in the surrounding larger function. (4) A thunk could be used today be creating a string (rather than a pre-compiled function) and substituting in the thunk's string (rather than the code to which it would compile) before execution, though this would be ugly. (5) A thunk *might* be do-able with exec or eval if a function's locals were still a dictionary. notice that while closures with the current semantics of def cannot rebind, the internal mechanism for closures is perfectly capable of supporting rebinding. So thunks could be function objects. (6) This has nothing whatsoever to do with for loops or generators, except as a common use case. In particular, thunks may be used to lock/unlock or unwind-protect some resource. Generators are not the only place this is needed, but they have made the "what do you mean, __del__ might never get called?" problem even worse, and Ruby often solves these with a Ruby Block. (7) A __leave__ or __exit__ special method really turns into another name for __del__. It might still be useful if it came with semantics of "I explicitly don't care what order cycles are broken; call me as soon as my object is garbage and who cares if it gets resurrected." There have been recipes (from Tim?) for emulating this by using a proxy to the resource, so that no __del__ cycles can form. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for sum()'s design?
[Alex Martelli] > I'm reasonably often using sum on lists of datetime.timedelta > instances, "durations", which ARE summable just like numbers even > though they aren't numbers. I believe everything else for which I've > used sum in production code DOES come under the general concept of > "numbers", in particular X+0 == X. Unfortunately, this equation > doesn't hold when X is a tiwmedelta, as X+0 raises an exception then. I count timedeltas "as numbers" too -- or at least I did when sum() was being designed, cuz I asked for the optional start= argument, and precisely in order to sum things like this (timedelta was indeed the driving example at the time). I can't say it bothers me to specify an appropriate identity element when 0 is inappropriate. If it switched to ignoring the start= argument unless the sequence was empty, that would be OK too, although I think sum(seq, start=0) same-as start + seq[0] + seq[1] + ... will always be easiest to explain, so all else being equal I prefer current behavior. The number of times I've passed a sequence to sum() with elements that were lists, tuples, or any other kind of object with a "concatenate" meaning for __add__ is zero so far. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (no subject)
At 10:36 PM 3/15/05 +1000, Nick Coghlan wrote: Phillip J. Eby wrote: I discussed this approach with Guido in private e-mail a few months back during discussion about an article I was writing for DDJ about decorators. We also discussed something very similar to 'update_meta()', but never settled on a name. Originally he wanted me to PEP the whole thing, but he wanted it to include optional type declaration info, so you can probably see why I haven't done anything on that yet. :) However, if we can define a __signature__ format that allows for type declaration, I imagine there'd be little problem with moving forward on it. But one of the reasons for providing 'update_meta' is so that additional metadata (like __signature__) can later be added transparently. Yes, exactly. Does deciding whether or not to supply the function really need to be dependent on whether or not a format for __signature__ has been chosen? Um, no. Why would you think that? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
