> I came up with the idea of a new statement
>
> call expr
I don't think your ideas should stop us from doing the right
thing right now, i.e. add operator.call (for symmetry with
everything else that is in the operator module).
Whether a call keyword gets added to Python remains to be seen;
I
Why is "call expr" a more enticing syntax than "yield *expr" ?
On Thu, Feb 5, 2009 at 9:31 PM, Greg Ewing wrote:
> Guido van Rossum wrote:
>
>> What's so special about your proposal that requires a new keyword?
>
> I was thinking about the proposals that are made
> from time to time for things li
Guido van Rossum wrote:
What's so special about your proposal that requires a new keyword?
I was thinking about the proposals that are made
from time to time for things like
yield *foo
to yield all the items from a sub-generator. I was
also thinking about what could be done to make
using g
On Thu, Feb 5, 2009 at 9:20 PM, Greg Ewing wrote:
> I've been thinking about proposing an enhancement
> concerning generators that would entail making
> "call" a reserved word, so I'd be a little
> disappointed if this name were used.
>
> Maybe apply() could be reinstated and put into
> the operat
Hrvoje Niksic wrote:
Is there a reason why the operator module doesn't have an operator.call
function?
I've been thinking about proposing an enhancement
concerning generators that would entail making
"call" a reserved word, so I'd be a little
disappointed if this name were used.
Maybe apply()
Eric Smith wrote:
Aahz wrote:
On Tue, Feb 03, 2009, Ross Light wrote:
Hello, python-dev. I submitted a patch a couple weeks ago for Issue
4285, and it has been reviewed and revised. Would someone please
review/commit it? Thank you.
http://bugs.python.org/issue4285
When sending in a reques
Christian Heimes wrote:
... The performance penalty is slime to nothing for the common case
Sorry, I love this typo.
-Scott
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:
Raymond Hettinger wrote:
The arguments for and against the patch could be brought against
partial()
itself, so I don't understand the -1's at all.
Quite so, but that doesn't justify adding more capabilities to partial().
I concur with Collin. Lever arguments are a road to bloat.
One pers
Hi,
My reading of the most recent set of emails on this topic is that the
balance of opinion is against adding a 'partial_right' or 'partial.skip'
feature. I still think such a feature would be of real use, although I
can see the arguments against adding it. Is the conclusion 'no thanks',
then?
Terry Reedy schrieb:
>> The first time a non str object is inserted or looked up, the dict
>> swiches to a more general lookup methods.
>
> This makes adding a string-only dict pretty trivial, if desired.
It's not as trivial as it seems. The switch over to the general lookup
method happens when a
Christian Heimes wrote:
Nick Coghlan wrote:
Generally speaking, Python namespace dictionaries (be it globals(),
locals(), the __dict__ attribute of an instance or a set of keyword
arguments) aren't required to enforce the use of legal identifiers (in
many cases, the CPython variants don't even e
> How are we going to handle str subclasses and unicode?
"Are we going to"? You mean, the current code is not good enough? Why not?
> Should we allow
> all subclasses of basestring? Or just str and unicode? Or str only?
In 2.x, str only, in 3.x, unicode only.
Regards,
Martin
___
Guido van Rossum schrieb:
> I'd prefer a compromise -- the keys should be strings, but should not
> be required to be valid identifiers. All Python implementations should
> support this. Rationale: a type check is cheap, and using strings
> exclusively makes the use of a faster dict implementation
Nick Coghlan wrote:
> Generally speaking, Python namespace dictionaries (be it globals(),
> locals(), the __dict__ attribute of an instance or a set of keyword
> arguments) aren't required to enforce the use of legal identifiers (in
> many cases, the CPython variants don't even enforce the use of s
I'd prefer a compromise -- the keys should be strings, but should not
be required to be valid identifiers. All Python implementations should
support this. Rationale: a type check is cheap, and using strings
exclusively makes the use of a faster dict implementation possible. A
check for a conforming
Michael Haggerty wrote:
> Is this behavior required somewhere by the Python language spec, or is
> it an error that just doesn't happen to be checked, or is it
> intentionally undefined whether this is allowed?
Generally speaking, Python namespace dictionaries (be it globals(),
locals(), the __dic
It's to make up for the lack of SET_TOP in that path.
On Thu, Feb 5, 2009 at 10:19 AM, Cesare Di Mauro
wrote:
> Looking at the UNARY_NOT case in ceval.c:
>
>case UNARY_NOT:
>v = TOP();
>err = PyObject_IsTrue(v);
>
Looking at the UNARY_NOT case in ceval.c:
case UNARY_NOT:
v = TOP();
err = PyObject_IsTrue(v);
Py_DECREF(v);
if (err == 0) {
Py_INCREF(Py_True);
Jaroslav Pachola mageo.cz> writes:
>
> What's the replacement in the library then, in case that I just want to
> create
> a unique file name and I don't care about the possible issues?
Three alternatives I'm thinking of:
- tempfile.mktemp(): the doc says it has been deprecated since 2.3, but i
Hello,
Dne Thursday 05 February 2009 Antoine Pitrou napsal(a):
> Hello,
>
> > I agree. The best thing to do would be to deprecate the Python wrappers
> > around insecure C functions and then remove them after a couple releases.
>
> They have been removed in 3.0.
What's the replacement in the lib
Hello,
> I agree. The best thing to do would be to deprecate the Python wrappers
> around insecure C functions and then remove them after a couple releases.
They have been removed in 3.0.
> Why does Python offer
> this attractive nuisance?
Well, there was a time when security concerns were a
On Thu, 5 Feb 2009 08:35:30 -0800, Raymond Hettinger wrote:
import os
os.tmpnam()
RuntimeWarning: tmpnam is a potential security risk to your program
This warning is a reflection of the fact that (at least) the glibc authors
think you shouldn't be using tmpnam(2). If you compile a C progra
import os
os.tmpnam()
RuntimeWarning: tmpnam is a potential security risk to your program
Are these runtime warnings necessary? Suppressing these warnings is a pita for
one-off uses of os.tmpnam() or os.tempnam().
I would hate for this sort of thing to propagate throughout the standard libr
Calvin Spealman wrote:
I would favor this not being constrained. I don't want every use of **
to cause a pattern match to verify each key. I would even be fine
without the check for being strings. Define what it should be, but let
the implementation be lax. It is no different from any other place
I would favor this not being constrained. I don't want every use of **
to cause a pattern match to verify each key. I would even be fine
without the check for being strings. Define what it should be, but let
the implementation be lax. It is no different from any other place
where you need to know i
I can't find documentation about whether there are constraints imposed
on the keys in the map passed to a function via **, as in f(**d).
According to
http://docs.python.org/reference/expressions.html#id9
, d must be a mapping.
test_extcall.py implies that the keys of this map must be string
Guido van Rossum wrote:
def call(o, *args, **kwds):
return o(*args, **kwds)
which would make call a synonym for apply (and would also provide for
the first definition as a special case). However, with that API, it
isn't so easy anymore to pass the same arguments to all callables
(unless it is
27 matches
Mail list logo
