> - Before anybody asks, I really do think the reason this is requested
> at all is really just to save typing; there isn't the "avoid double
> evaluation" argument that helped acceptance for assignment operators
> (+= etc.), and I find redability is actually improved with 'for'.
I'd like it, and
Guido van Rossum wrote:
But I think the logical consequence of your approach would be that
sum([]) should raise an exception rather than return 0, which would be
backwards incompatible. Because if the identity element has a default
value, the default value should be used exactly as if it were
speci
It's needed to implement things that behave like instance methods, for
instance, and I notice that at at least some point in the past Zope3
has used the function with a note attached saying "Guido says this is
OK".
Also, the context is that I want to submit a patch to PyObjC using the
function, an
Neat! But please add something to the __doc__ so we can also see it was
changed. E.g.
self.__doc__ = other.__doc__ + os.linesep + "*** deprecated ***"
On 12 mrt 2005, at 5:25, Nick Coghlan wrote:
I like "update_meta"
Patch against current CVS added to SF with the behaviour:
def update_meta(sel
On Mar 14, 2005, at 10:57, Gareth McCaughan wrote:
of way as it's distracting in C or C++ seeing
Thing thing = new Thing();
with the type name appearing three times.
I think you can't possibly see this in C:-), you need a star there in
C++, and you need to avoid the 'new' (just cal
On Mar 14, 2005, at 11:20, Nick Coghlan wrote:
...
Somewhat ugly, but backwards compatible:
I realize you're mostly talking semantics, not implementation, but, as
long as we're at it, could we pretty please have back the optimization
indicated by...:
# Add the elements
if isinstance(valu
Greg Ewing wrote:
Guido van Rossum wrote:
- the identity (defaulting to 0) if the sequence is empty
- the first and only element if the sequence only has one element
- (...(((A + B) + C) + D) + ...) if the sequence has more than one
element
While this might be reasonable if the identity
argument i
Gareth McCaughan wrote:
I'd like it, and my reason isn't "just to save typing".
There are two reasons.
1 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.
2 Seeing [x for x in stuff if con
Hi Michael,
> ... _PyType_Lookup ...
There has been discussions about copy_reg.py and at least one other place in
the standard library that needs this; it is an essential part of the
descriptor model of new-style classes. In my opinion it should be made part
not only of the official C API but th
On Monday 2005-03-14 12:09, Alex Martelli wrote:
>
> On Mar 14, 2005, at 10:57, Gareth McCaughan wrote:
>
> > of way as it's distracting in C or C++ seeing
> >
> > Thing thing = new Thing();
> >
> > with the type name appearing three times.
>
> I think you can't possibly see this
On Monday 2005-03-14 12:42, Eric Nieuwland wrote:
> Gareth McCaughan wrote:
>
> > I'd like it, and my reason isn't "just to save typing".
> > There are two reasons.
> >
> > 1 Some bit of my brain is convinced that [x in stuff if condition]
> > is the Right Syntax and keeps making me type it
Armin Rigo <[EMAIL PROTECTED]> writes:
> Hi Michael,
>
>> ... _PyType_Lookup ...
>
> There has been discussions about copy_reg.py and at least one other place in
> the standard library that needs this; it is an essential part of the
> descriptor model of new-style classes. In my opinion it should
Eric Nieuwland wrote:
Neat! But please add something to the __doc__ so we can also see it was
changed. E.g.
self.__doc__ = other.__doc__ + os.linesep + "*** deprecated ***"
Decorators that alter the signature, or wish to change the docstring can make
their modifications after copying from the
Nick Coghlan writes:
> Patch against current CVS added to SF with the behaviour:
>
>def update_meta(self, other):
> self.__name__ = other.__name__
> self.__doc__ = other.__doc__
> self.__dict__.update(other.__dict__)
Nice... thanks. But I have to ask: is this really the right s
Alex Martelli wrote:
On Mar 14, 2005, at 11:20, Nick Coghlan wrote:
...
Somewhat ugly, but backwards compatible:
I realize you're mostly talking semantics, not implementation, but, as
long as we're at it, could we pretty please have back the optimization
indicated by...:
It turns out the sent
Title: RE: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
[Gareth McCaughan]
#- 1 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.
My brain says: '"x i
I had
PyArg_ParseTuple(args, "s#s#i:compare", &p1, &bytes1, &p2, &bytes2)
in a program. There are not enough arguments to PyArg_ParseTuple. Does
PyArg_ParseTuple know how many arguments it is getting? If so, I suggest
that an exception should be raised here.
_
At 05:34 AM 3/14/05 -0800, Michael Chermside wrote:
Nice... thanks. But I have to ask: is this really the right set of metadata to
be updating? Here are a few things that perhaps ought be copied by
update_meta:
f.__name__ (already included)
f.__doc__ (already included)
f.__di
"Edward C. Jones" <[EMAIL PROTECTED]> writes:
> I had
>
> PyArg_ParseTuple(args, "s#s#i:compare", &p1, &bytes1, &p2, &bytes2)
>
> in a program. There are not enough arguments to PyArg_ParseTuple. Does
> PyArg_ParseTuple know how many arguments it is getting?
I don't think so.
> If so, I suggest
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 05:34 AM 3/14/05 -0800, Michael Chermside wrote:
>>Nice... thanks. But I have to ask: is this really the right set of metadata to
>> be updating? Here are a few things that perhaps ought be copied by
>> update_meta:
>>
>> f.__name__ (alread
At 04:35 PM 3/14/05 +0100, Thomas Heller wrote:
Another possibility (ugly, maybe) would be to create sourcecode with the
function signature that you need, and compile it. inspect.getargspec() and
inspect.formatargspec can do most of the work.
I've done exactly that, for generic functions in PyProto
On Tue, 15 Mar 2005 00:05:32 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
[...]
> Maybe what we really should be doing is trapping the TypeError, and
> generating a
> more meaningful error message.
>
> E.g.
>
[...]
> ... try:
> ... value += first
> ... except TypeError:
> ... raise
Phillip J. Eby wrote:
[SNIP]
One solution is to have a __signature__ attribute that's purely
documentary. That is, modifying it wouldn't change the function's
actual behavior, so it could be copied with update_meta() but then
modified by the decorator if need be. __signature__ would basically
Bug has been filed with id 1163244.
regards,
--Tim
-Original Message-
From: "Martin v. Lowis" [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 12, 2005 3:12 PM
To: Leeuw van der, Tim
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Python2.4.1c1 and win32com
Leeuw van der, Tim wrote:
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Brian Sabbey wrote:
>
> > How about something like below? In the same way
> > that "self" is passed "behind the scenes" as the first argument, so can
> > the thunk be.
> >
> > with stopwatch() result dt:
> > a()
> > b()
> > print 'it took', d
Kurt B. Kaiser wrote:
Do you happen to remember the precise error message?
"This installation package could not be opened."
Ah, that you get if the file is already open. Do you run some shell
extension that might want to look into the MSI file, or virus scanners?
I also recall a KB article that th
Josiah Carlson wrote:
Since PEP 310 was already mentioned, can we just say that the discussion
can be boiled down to different ways of spelling __enter__/__exit__ from
PEP 310?
It's not quite the same thing. PEP 310 suggests a mechanism
with a fixed control flow -- do something on entry, do the
cod
Edward C. Jones wrote:
I had
PyArg_ParseTuple(args, "s#s#i:compare", &p1, &bytes1, &p2, &bytes2)
in a program. There are not enough arguments to PyArg_ParseTuple. Does
PyArg_ParseTuple know how many arguments it is getting?
No. There is no standard way for a C function to find out how
many paramet
Guido van Rossum wrote:
But I think the logical consequence of your approach would be that
sum([]) should raise an exception rather than return 0, which would be
backwards incompatible. Because if the identity element has a default
value, the default value should be used exactly as if it were
speci
be guaranteed to run under all conditions, I think it
would be useful if it could be arranged so that
for x in somegenerator():
...
raise Blather
...
would caused any finallies that the generator was suspended
inside to be executed. Then the semantics would be the
same as if the for-loop-
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,
That's a really strange way of looking at it. Unless
you would also say that
x = y
is a shorthand for
x = identity(y)
Not that it's false,
Eric Nieuwland wrote:
Perhaps the second argument should not be optional to emphasise this.
After all, there's much more to sum() than numbers.
I think practicality beats purity here. Using it on
numbers is surely an extremely common case.
--
Greg Ewing, Computer Science Dept, +---
[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() ne
Brian Sabbey wrote:
be guaranteed to run under all conditions, I think it would be
useful if it could be arranged so that
for x in somegenerator(): ... raise Blather ...
would caused any finallies that the generator was suspended inside
to be executed. Then the semantics would be the same as if the
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
On Mon, 14 Mar 2005 19:16:22 -0500, Tim Peters <[EMAIL PROTECTED]> 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
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Ok, so it's likely incomplete download.
Definitely.
It's a bit of a misfeature that the icon appears on the desktop before
the download is complete. But I'd say there's no real issue here,
besides my impatience/inattention.
--
KBK
__
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.
Which is not unlike the get() method of dicts. S
On 14-mrt-05, at 14:26, Michael Hudson wrote:
Armin Rigo <[EMAIL PROTECTED]> writes:
Hi Michael,
... _PyType_Lookup ...
There has been discussions about copy_reg.py and at least one other
place in
the standard library that needs this; it is an essential part of the
descriptor model of new-style cl
39 matches
Mail list logo
