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
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, and
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(self,
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
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
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
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 even though
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 be made
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 set of
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
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 in stuff
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)
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 that an
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__ (already included)
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
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', dt, 'seconds to compute'
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 the
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
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 parameters
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
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
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,
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
numbers is
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. So
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
33 matches
Mail list logo
