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
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
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
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
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
On Thu, 5 Feb 2009 08:35:30 -0800, Raymond Hettinger pyt...@rcn.com 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
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
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 library
Jaroslav Pachola pachola at 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,
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);
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
cesare.dima...@a-tono.com wrote:
Looking at the UNARY_NOT case in ceval.c:
case UNARY_NOT:
v = TOP();
err = PyObject_IsTrue(v);
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
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
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
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
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
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
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 non
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?
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
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:
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
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()
On Thu, Feb 5, 2009 at 9:20 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
Why is call expr a more enticing syntax than yield *expr ?
On Thu, Feb 5, 2009 at 9:31 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
27 matches
Mail list logo
