Re: [Python-Dev] dict(keys, values)
George Sakkis wrote: Perhaps this has been brought up in the past but I couldn't find it in the archives: far too often I use the idiom dict(zip(keys,values)), or the same with izip. How does letting dict take two positional arguments sound ? Pros: - Pretty obvious semantics, no mental overhead to learn and remember it. - More concise (especially if one imports itertools just to use izip). - At least as efficient as the current alternatives. - Backwards compatible. Cons: - Yet Another Way To Do It - Marginal benefit Also note that the keyword variant is longer than the zip variant e.g. dict(zip(keys, values)) dict(keys=keys, values=values) and the relationship between the keys and values seems far less obvious to me in the keyword variant. Cheers, Brian ___ 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] Python's C interface for types
Jim Jewett [EMAIL PROTECTED] wrote: For 0: hash(+0.0)==hash(-0.0)==hash(0)=hash(0L)=0 Unfortunately, that assumes that equality is transitive. No, but the (transitively closed set of equivalent objects) must have the same hash. ... Er, how do you have a transitive closure for a non-transitive operation? I really do mean that quite a lot of floating-point bells and whistles are non-transitive. The only one most people will have come across is IEEE NaNs, where 'a is b' does not imply 'a == b', but there are a lot of others (and have been since time immemorial). I don't THINK that IEEE 754R decimal introduces any, though I am not prepared to bet on it. let us say that I am implementing a special function and want to distinguish -0.0 and +0.0. Why can't I use a dictionary? Because they are equal. They aren't identical, but they are equal. You have missed my point, which is extended floating-points effectively downgrade the status of the purely numeric comparisons, and therefore introduce a reasonable requirement for using a tighter match. Note that I am merely commenting that this needs bearing in mind, and NOT that anything should be changed. a = float(+0.0) b = float(-0.0) print a, b 0.0 -0.0 With the standard windows distribution, I get just 0.0 0.0 Watch that space :-) Expect it to change. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] dict(keys, values)
On 2/1/07, Brian Quinlan [EMAIL PROTECTED] wrote: George Sakkis wrote: Perhaps this has been brought up in the past but I couldn't find it in the archives: far too often I use the idiom dict(zip(keys,values)), or the same with izip. How does letting dict take two positional arguments sound ? Pros: - Pretty obvious semantics, no mental overhead to learn and remember it. - More concise (especially if one imports itertools just to use izip). - At least as efficient as the current alternatives. - Backwards compatible. Cons: - Yet Another Way To Do It - Marginal benefit Also note that the keyword variant is longer than the zip variant e.g. dict(zip(keys, values)) dict(keys=keys, values=values) and the relationship between the keys and values seems far less obvious to me in the keyword variant. Cheers, Brian Um, you do realize that dict(keys=keys, values=values) is already valid and quite different from dict(zip(keys, values)), don't you ? :) George ___ 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] dict(keys, values)
Brian Quinlan wrote:
George Sakkis wrote:
Perhaps this has been brought up in the past but I couldn't find it in
the archives: far too often I use the idiom dict(zip(keys,values)), or
the same with izip. How does letting dict take two positional
arguments sound ?
Pros:
- Pretty obvious semantics, no mental overhead to learn and remember it.
- More concise (especially if one imports itertools just to use izip).
- At least as efficient as the current alternatives.
- Backwards compatible.
Cons:
- Yet Another Way To Do It
- Marginal benefit
Also note that the keyword variant is longer than the zip variant e.g.
dict(zip(keys, values))
dict(keys=keys, values=values)
and the relationship between the keys and values seems far less obvious
to me in the keyword variant.
Unfortunately
dict(keys=keys, values=values) == {keys: values}
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007
___
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] dict(keys, values)
George Sakkis wrote: Um, you do realize that dict(keys=keys, values=values) is already valid and quite different from dict(zip(keys, values)), don't you ? :) Sorry, minor misreading on my part. Like that time in Sunday school when I missed the not in Though shall not kill. That was a rough week for everyone involved. OK, the non-zip variant saves you 5 characters i.e. dict(zip(keys, values)) vs. dict(keys, values) I still don't like it :-) Cheers, Brian ___ 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] dict(keys, values)
Unfortunately
dict(keys=keys, values=values) == {keys: values}
Ummm, no:
dict(keys=keys, values=values) == {'keys': keys, 'values': values}
___
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] dict(keys, values)
Andrew Koenig wrote:
Unfortunately
dict(keys=keys, values=values) == {keys: values}
Ummm, no:
dict(keys=keys, values=values) == {'keys': keys, 'values': values}
Of course I should really have written
dict(keys=keys, values=values) != dict(zip(keys, values))
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007
___
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] Python's C interface for types
Nick Maclaren schrieb: For 0: hash(+0.0)==hash(-0.0)==hash(0)=hash(0L)=0 Unfortunately, that assumes that equality is transitive. No, but the (transitively closed set of equivalent objects) must have the same hash. ... Er, how do you have a transitive closure for a non-transitive operation? I really do mean that quite a lot of floating-point bells and whistles are non-transitive. If so, they just shouldn't use the equal operator (==). == ought to be transitive. It should be consistent with has(). You have missed my point, which is extended floating-points effectively downgrade the status of the purely numeric comparisons, and therefore introduce a reasonable requirement for using a tighter match. Note that I am merely commenting that this needs bearing in mind, and NOT that anything should be changed. If introducing extended floating-points would cause trouble to existing operations, I think extended floating-points should not be introduced to Python. If all three of you really need them, come up with method names to express almost equal or equal only after sunset. 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] Python's C interface for types
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote: I really do mean that quite a lot of floating-point bells and whistles are non-transitive. If so, they just shouldn't use the equal operator (==). == ought to be transitive. It should be consistent with has(). Fine. A very valid viewpoint. Would you like to explain that to the IEEE 754 people? Strictly, it is only the reflexive property that IEEE 754 and the Decimal module lack. Yes, A == A is False, if A is a NaN. But the definition of 'transitive' often requires 'reflexive'. from decimal import * x = Decimal(NaN) x == x False I don't know any CURRENT systems where basic floating-point doesn't have the strict transitive relation, but I wouldn't bet that there aren't any. You don't need to extend floating-point to have trouble; even the basic forms often had it. I sincerely hope that one is dead, but people keep reinventing old mistakes :-( The most common form was where comparison was equivalent to subtraction, and there were numbers such that A-B == 0, B-C == 0 but A-C != 0. That could occur even for integers on some systems. I don't THINK that the Decimal specification has reintroduced this, but am not quite sure. You have missed my point, which is extended floating-points effectively downgrade the status of the purely numeric comparisons, and therefore introduce a reasonable requirement for using a tighter match. Note that I am merely commenting that this needs bearing in mind, and NOT that anything should be changed. If introducing extended floating-points would cause trouble to existing operations, I think extended floating-points should not be introduced to Python. If all three of you really need them, come up with method names to express almost equal or equal only after sunset. Fine. Again, a very valid viewpoint. Would you like to explain it to the IEEE 754, Decimal and C99 people, and the Python people who think that tracking C is a good idea? We already have the situation where A == B == 0, but where 'C op A' != 'C op B' != 'C op 0'. Both where op is a built-in operator and where 'C op' is a standard library function. This one is NOT going to go away, and is going to get more serious, especially if extended floating-point formats like Decimal take off. Note that it is not a fault in Decimal, but a feature of almost all extended floating-points. As I said, I have no answer to it. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] Python's C interface for types
Nick Maclaren schrieb: If so, they just shouldn't use the equal operator (==). == ought to be transitive. It should be consistent with has(). Fine. A very valid viewpoint. Would you like to explain that to the IEEE 754 people? Why should I? I don't talk about IEEE 754, I talk about Python. Strictly, it is only the reflexive property that IEEE 754 and the Decimal module lack. Yes, A == A is False, if A is a NaN. But the definition of 'transitive' often requires 'reflexive'. I deliberately stated 'transitive', not 'reflexive'. The standard definition of 'transitive' is if a==b and b==c then a==c. The most common form was where comparison was equivalent to subtraction, and there were numbers such that A-B == 0, B-C == 0 but A-C != 0. That could occur even for integers on some systems. I don't THINK that the Decimal specification has reintroduced this, but am not quite sure. I'm not talking about subtraction, either. I'm talking about == and hash. Fine. Again, a very valid viewpoint. Would you like to explain it to the IEEE 754, Decimal and C99 people, and the Python people who think that tracking C is a good idea? I'm not explaining anything. I'm stating an opinion. This one is NOT going to go away, and is going to get more serious, especially if extended floating-point formats like Decimal take off. Note that it is not a fault in Decimal, but a feature of almost all extended floating-points. As I said, I have no answer to it. It doesn't look like you *need* to give an answer now. I thought you were proposing some change to Python (although I'm uncertain what that change could have been). If you are merely explaining things (to whom?), just keep going. 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
[Python-Dev] dict(keys, values)
George Sakkis wrote: far too often I use the idiom dict(zip(keys,values)), or the same with izip. How does letting dict take two positional arguments sound ? I think the dict constructor is already a bit too complicated, and would prefer that it be a separate classmethod, such as dict.zip(keys, values=itertools.repeat(None)) The default argument on values should finish the replacement of dict.fromkeys functionality that sets and defaultdicts began. At least as efficient as the current alternatives. I think it has to do better (at least by eliminating the temporary zip object) to be worthwhile; the do-it-yourself alternative is pretty short. # from itertools import izip as zip def dictz(keys, values): return dict(zip(keys,values)) -jJ ___ 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] Python's C interface for types
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote: If so, they just shouldn't use the equal operator (==). == ought to be transitive. It should be consistent with has(). Fine. A very valid viewpoint. Would you like to explain that to the IEEE 754 people? Why should I? I don't talk about IEEE 754, I talk about Python. The problem is that Python is increasingly assuming IEEE 754 by implication, and you were stating something as a requirement that isn't true in IEEE 754. Strictly, it is only the reflexive property that IEEE 754 and the Decimal module lack. Yes, A == A is False, if A is a NaN. But the definition of 'transitive' often requires 'reflexive'. I deliberately stated 'transitive', not 'reflexive'. The standard definition of 'transitive' is if a==b and b==c then a==c. When I was taught mathematics, the lecturer said that a transitive relation is a reflexive one that has that extra property. It was then (and may still be) a fairly common usage. I apologise for being confusing! The most common form was where comparison was equivalent to subtraction, and there were numbers such that A-B == 0, B-C == 0 but A-C != 0. That could occur even for integers on some systems. I don't THINK that the Decimal specification has reintroduced this, but am not quite sure. I'm not talking about subtraction, either. I'm talking about == and hash. Grrk. Look again. So am I. But let this one pass, as I don't think that mistake will return - and I sincerely hope not! Fine. Again, a very valid viewpoint. Would you like to explain it to the IEEE 754, Decimal and C99 people, and the Python people who think that tracking C is a good idea? I'm not explaining anything. I'm stating an opinion. You are, however, stating an opinion that conflicts with the direction that Python is currently taking. It doesn't look like you *need* to give an answer now. I thought you were proposing some change to Python (although I'm uncertain what that change could have been). If you are merely explaining things (to whom?), just keep going. Thanks. I hope the above clarifies things a bit. My purpose in posting is to point out that some changes are already happening, by inclusion from other standards, that are introducing problems to Python. And to many other languages, incidentally, including Fortran and C. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] Python's C interface for types
Nick Maclaren wrote: I really do mean that quite a lot of floating-point bells and whistles are non-transitive. Martin v. Löwis wrote: If so, they just shouldn't use the equal operator (==). == ought to be transitive. It should be consistent with has(). Nick Maclaren wrote: Fine. A very valid viewpoint. Would you like to explain that to the IEEE 754 people? When Decimal was being argued, Tim pointed out that the standard requires certain operations, but doesn't require specific spelling shortcuts. If you managed to do (and document) it right, people would be grateful for methods like a.exactly(b) a.close_enough(b) a.same_expected_value(b) but that doesn't mean any of them should be used when testing a==b (In Lisp, you typically can specify which equality predicate a hashtable should use on pairs of keys; in python, you only specify which it should use on objects of your class, and if the other object in the comparison disagrees, you're out of luck.) Strictly, it is only the reflexive property that IEEE 754 and the Decimal module lack. Yes, A == A is False, if A is a NaN. Therefore NaNs should never be used (in python) as dictionary keys. Therefore, they should be unhashable. Also note that PyObject_RichCompareBool (from Objects/object.c) assumes the reflexive property, and if you try to violate it, you will get occasional surprises. We already have the situation where A == B == 0, but where 'C op A' != 'C op B' != 'C op 0'. Both where op is a built-in operator and where 'C op' is a standard library function. That's fine; it just means that numeric equality may not be the strongest possible equivalence. hash in particular just happens to be defined in terms of ==, however == is determined. -jJ ___ 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
