Re: [Python-Dev] Missing operator.call
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 no arguments that you want to pass). My version is in line with the other operators in the operator module. The version that binds the arguments and returns a callable is already available as functools.partial. And it works well in the case I encountered. In fact, it works even better because it allows things like map(call, l1, l2) to apply each element of l2 to the corresponding function in l1. If there's no opposition to this, I'll post a patch to the tracker. ___ 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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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 strings in the
following test:
f(**{1:2})
Traceback (most recent call last):
...
TypeError: f() keywords must be strings
But must the keys be valid python identifiers?
In particular, the following is allows by the Python 2.5.2 and the
Jython 2.2.1 interpreters:
f(**{'1':2})
{'1': 2}
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?
Michael
___
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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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 its not a promise, just an artifact, and
shouldn't rely on what the implementation currently does or does not
force.
On Thu, Feb 5, 2009 at 3:03 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
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 strings in the
following test:
f(**{1:2})
Traceback (most recent call last):
...
TypeError: f() keywords must be strings
But must the keys be valid python identifiers?
In particular, the following is allows by the Python 2.5.2 and the
Jython 2.2.1 interpreters:
f(**{'1':2})
{'1': 2}
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?
Michael
___
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/ironfroggy%40gmail.com
--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
___
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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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
where you need to know its not a promise, just an artifact, and
shouldn't rely on what the implementation currently does or does not
force.
I agree. There was a similar issue in http://bugs.python.org/issue2598,
and we decided not to do anything about it.
Eric.
On Thu, Feb 5, 2009 at 3:03 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
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 strings in the
following test:
f(**{1:2})
Traceback (most recent call last):
...
TypeError: f() keywords must be strings
But must the keys be valid python identifiers?
In particular, the following is allows by the Python 2.5.2 and the
Jython 2.2.1 interpreters:
f(**{'1':2})
{'1': 2}
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?
Michael
___
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/ironfroggy%40gmail.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
[Python-Dev] Warnings
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 library. Some folks think eval() should never be used and the same for input(). Some folks think md5 should be removed. Some folks think pickles are the ultimate security threat. IMO, it is enough to note potential vulnerabilities in the docs. Even then, I'm not too keen on the docs being filled with lots of red-outlined pink-boxed warning signs, effectively communicating that Python itself is dangerous and unreliable. Raymond - Happy FUN BALL! -only $14.95- Warning: Pregnant women, the elderly and children under 10 should avoid prolonged exposure to Happy Fun Ball. Caution: Happy Fun Ball may suddenly accelerate to dangerous speeds. Happy Fun Ball Contains a liquid core, which, if exposed due to rupture, should not be touched, inhaled, or looked at. Do not use Happy Fun Ball on concrete. Discontinue use of Happy Fun Ball if any of the following occurs: Itching, Vertigo, Dizziness Tingling in extremities, Loss of balance or coordination Slurred speech, Temporary blindness, Profuse sweating, Heart palpitations If Happy Fun Ball begins to smoke, get away immediately. Seek shelter and cover head. Happy Fun Ball may stick to certain types of skin. When not in use, Happy Fun Ball should be returned to its special container and kept under refrigeration... Failure to do so relieves the makers of Happy Fun Ball, Wacky Products Incorporated, and its parent company Global Chemical Unlimited, of any and all liability. Ingredients of Happy Fun Ball include an unknown glowing substance which fell to Earth, presumably from outer space. Happy Fun Ball has been shipped to our troops in Saudi Arabia and is also being dropped by our warplanes on Iraq. Do not taunt Happy Fun Ball. Happy Fun Ball comes with a lifetime guarantee. Happy Fun Ball ACCEPT NO SUBSTITUTES! ___ 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] Warnings
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 compile a C program that uses it, you'll see a warning about it. Since you can write a Python program that uses tmpnam(2) without ever compiling such a C program, you get a RuntimeWarning instead. It's not quite analogous, since you don't get the warning from the C program every time you run it, but it's about as close as you can do in Python without resorting to crazy tricks. Are these runtime warnings necessary? Suppressing these warnings is a pita for one-off uses of os.tmpnam() or os.tempnam(). Why are you using them? Why not just use one of the many, many, many other APIs for generating temporary files that Python exposes? One of the ones that doesn't emit any warnings? I would hate for this sort of thing to propagate throughout the standard library. Some folks think eval() should never be used and the same for input(). Some folks think md5 should be removed. Some folks think pickles are the ultimate security threat. IMO, it is enough to note potential vulnerabilities in the docs. Even then, I'm not too keen on the docs being filled with lots of red-outlined pink-boxed warning signs, effectively communicating that Python itself is dangerous and unreliable. 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. It's not as though these functions fill a critical niche - the tempfile module and even os.tmpfile are more than enough. Why does Python offer this attractive nuisance? Jean-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
Re: [Python-Dev] Warnings
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 lot less wide-spread. Regards Antoine. ___ 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] Warnings
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 then, in case that I just want to create a unique file name and I don't care about the possible issues? Why does Python offer this attractive nuisance? Well, there was a time when security concerns were a lot less wide-spread. Is using of virtual memory secure? Aren't we all adults suddenly? ;-) I know, the damage has already been done (as with cmp parameter of sort(ed) etc.) and I should have notice them sooner. Or it is only me, maybe, who thinks that such weight losing is not healthy for the language and library users. Regards, JP ___ 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] Warnings
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, but it's still there; - NamedTemporaryFile(delete=False): that's the officially suggested replacement in the doc; - tempfile.mkdtemp() and then create a regular file in the created directory. Regards Antoine. ___ 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] Why a STACKADJ(-1) in UNARY_NOT on ceval.c?
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);
SET_TOP(Py_True);
continue;
}
else if (err 0) {
Py_INCREF(Py_False);
SET_TOP(Py_False);
err = 0;
continue;
}
STACKADJ(-1);
break;
I don't understand why there's a STACKADJ(-1) at its end. Looking at the
code, we know that if the CPU arrives to the STACKADJ, it's because of an
error condition in the PyObject_IsTrue that sets err to a 0 value, so
exiting the big switch statement, an error will be raised.
So the question is, why there's the need to skip the top stack PyObject?
It's a different behaviour comparing it to the all other unary operators.
For example:
case UNARY_NEGATIVE:
v = TOP();
x = PyNumber_Negative(v);
Py_DECREF(v);
SET_TOP(x);
if (x != NULL) continue;
break;
There's no STACKADJ instruction on errors.
Can someone explain it?
Thanks a lot
Cesare
___
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] Why a STACKADJ(-1) in UNARY_NOT on ceval.c?
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);
Py_DECREF(v);
if (err == 0) {
Py_INCREF(Py_True);
SET_TOP(Py_True);
continue;
}
else if (err 0) {
Py_INCREF(Py_False);
SET_TOP(Py_False);
err = 0;
continue;
}
STACKADJ(-1);
break;
I don't understand why there's a STACKADJ(-1) at its end. Looking at the
code, we know that if the CPU arrives to the STACKADJ, it's because of an
error condition in the PyObject_IsTrue that sets err to a 0 value, so
exiting the big switch statement, an error will be raised.
So the question is, why there's the need to skip the top stack PyObject?
It's a different behaviour comparing it to the all other unary operators.
For example:
case UNARY_NEGATIVE:
v = TOP();
x = PyNumber_Negative(v);
Py_DECREF(v);
SET_TOP(x);
if (x != NULL) continue;
break;
There's no STACKADJ instruction on errors.
Can someone explain it?
Thanks a lot
Cesare
___
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/guido%40python.org
--
--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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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 __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 strings). Enforcing legal identifiers is usually the compiler's job and if you're using dict syntax to access the contents of a namespace, the compiler doesn't care. That laxness is a CPython implementation detail though - other implementations are quite free to be stricter with their namespaces (e.g. I believe Jython namespaces use explicitly string-keyed dictionaries, so Jython would reject the example below). Cheers, Nick. P.S. An example of messing about with a class's dictionary in CPython: Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type help, copyright, credits or license for more information. class C: pass ... C.__dict__[5] = Not an identifier! C.5 # obviously not allowed File stdin, line 1 C.5 # obviously not allowed ^ SyntaxError: invalid syntax C.__dict__['5'] = Still not an identifier! C.5 # still not allowed File stdin, line 1 C.5 # still not allowed ^ SyntaxError: invalid syntax C.__dict__[5] 'Not an identifier!' getattr(C, 5) Traceback (most recent call last): File stdin, line 1, in module TypeError: getattr(): attribute name must be string getattr(C, '5') 'Still not an identifier!' Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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 identifier is relatively expensive and serves no purpose except being pedantic. --Guido On Thu, Feb 5, 2009 at 12:19 PM, Nick Coghlan ncogh...@gmail.com wrote: 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 __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 strings). Enforcing legal identifiers is usually the compiler's job and if you're using dict syntax to access the contents of a namespace, the compiler doesn't care. That laxness is a CPython implementation detail though - other implementations are quite free to be stricter with their namespaces (e.g. I believe Jython namespaces use explicitly string-keyed dictionaries, so Jython would reject the example below). Cheers, Nick. P.S. An example of messing about with a class's dictionary in CPython: Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type help, copyright, credits or license for more information. class C: pass ... C.__dict__[5] = Not an identifier! C.5 # obviously not allowed File stdin, line 1 C.5 # obviously not allowed ^ SyntaxError: invalid syntax C.__dict__['5'] = Still not an identifier! C.5 # still not allowed File stdin, line 1 C.5 # still not allowed ^ SyntaxError: invalid syntax C.__dict__[5] 'Not an identifier!' getattr(C, 5) Traceback (most recent call last): File stdin, line 1, in module TypeError: getattr(): attribute name must be string getattr(C, '5') 'Still not an identifier!' Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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/guido%40python.org -- --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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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 strings). Side note: CPython's dict code has a special case for str objects (PyStringObject in 2.x, PyUnicodeObject in 3.x). The internal lookup method is optimized for str objects. Python uses dict objects for all its namespaces like classes, modules and most objects, so dict with str as keys are pretty common. The first time a non str object is inserted or looked up, the dict swiches to a more general lookup methods. lookdict() still fast but not as fast as lookdict_string(). It doesn't make a huge difference but you should still keep the fact in your head. We could abuse the state of the ma_lookup function pointer to check the dict for str only keys. But it would break for unicode keys thus making from __future__ import unicode_literals useless. Christian ___ 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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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 possible. A
check for a conforming identifier is relatively expensive and serves
no purpose except being pedantic.
As pointed out in my other posting, an additional type check isn't
required in most cases. A C function that checks ma_lookup does the same
trick.
int
PyDict_StringKeysOnly(PyObject *dict) {
if (((PyDictObject*)dict)-ma_lookup == lookdict_string)
return 1;
else {
/* check all keys for PyStringObject */
}
}
The performance penalty is slime to nothing for the common case.
How are we going to handle str subclasses and unicode? Should we allow
all subclasses of basestring? Or just str and unicode? Or str only?
Christian
___
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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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 ___ 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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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 enforce the use of strings). Side note: CPython's dict code has a special case for str objects (PyStringObject in 2.x, PyUnicodeObject in 3.x). The internal lookup method is optimized for str objects. Python uses dict objects for all its namespaces like classes, modules and most objects, so dict with str as keys are pretty common. 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. lookdict() still fast but not as fast as lookdict_string(). It doesn't make a huge difference but you should still keep the fact in your head. We could abuse the state of the ma_lookup function pointer to check the dict for str only keys. But it would break for unicode keys thus making from __future__ import unicode_literals useless. Assuming that 3.x dicts are optimized for the 3.x string type, this is not a problem for 3.x ;-). tjr ___ 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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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 str object is *looked up*.
d = {'a': None} # uses lookdict_string()
d.get(1, None) # d now uses lookdict()
d-ma_lookup == lookdict_string is a sufficient condition, not a
condicio sine qua non.
Assuming that 3.x dicts are optimized for the 3.x string type, this is
not a problem for 3.x ;-).
Well, it's always optimized for the str type - which happens to be
PyUnicodeObject in 3.x.
Christian
___
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] Partial function application 'from the right'
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? (I still have not had time to create an issue in the tracker and attach the patch, but will do so for completeness.) Thanks for the discussions, Ben. ___ 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] Partial function application 'from the right'
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 person's bloat is another person's rich and complete toolbox. In for a penny, in for a pound is not a language design principle. Neither are slippery slope arguments. One of the real problems with partial() and its variants is that they provide almost no advantage over an equivalent lambda. How about speed? I don't have a recent version of Python here to test, but my recollection is that partial is significantly faster than lambda. And even if it currently isn't, there could be (is?) more opportunity to optimize partial. I guess that the voting on this is going to be fall along functional lines: those who like functional languages will vote +1 on partial and co, and those who don't will vote -1. While I don't dislike partial(), I'd rather see one good use-case for partial_right() to be removed: built-ins that don't accept keywords. From Ben North's post starting this thread: I find 'functools.partial' useful, but occasionally I'm unable to use it because it lacks a 'from the right' version. E.g., to create a function which splits a string on commas, you can't say # Won't work when called: split_comma = partial(str.split, sep = ',') and to create a 'log to base 10' function, you can't say # Won't work when called: log_10 = partial(math.log, base = 10.0) because str.split and math.log don't take keyword arguments. I'd argue that it is better to add support for keyword arguments than to add partial_right. -- Steven ___ 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] The interpreter accepts f(**{'5':'foo'}); is this intentional?
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://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 4285 Review
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 request like this, it's useful to summarize the issue; few people know bug reports by number, and at least some people who might be interested in looking probably won't bother if they have no clue whether it's in their area of expertise. I'll review it with the intention of committing it. The subject is Use a named tuple for sys.version_info. Committed in r69331 (trunk) and r69346 (py3k). I hope I got the merge/block command correct. 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] Missing operator.call
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() could be reinstated and put into the operator module? -- Greg ___ 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] Missing operator.call
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 put into the operator module? That would lose the symmetry with __call__. What's so special about your proposal that requires a new keyword? -- --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] Missing operator.call
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 generators as coroutines more convenient, and I came up with the idea of a new statement call expr which would be equivalent to for x in expr: yield x This happens to be the same as what yield * would do, so it kind of unifies the two issues. -- Greg ___ 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] Missing operator.call
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 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 generators as coroutines more convenient, and I came up with the idea of a new statement call expr which would be equivalent to for x in expr: yield x This happens to be the same as what yield * would do, so it kind of unifies the two issues. -- Greg ___ 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/guido%40python.org -- --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] Missing operator.call
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 would expect some opposition if a PEP was written. 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
