Re: [Python-3000] set literals
I've also sometimes thought of unifying dicts and sets by implementing
set operations on the keys of dicts only. When the values aren't the
same, we could make an arbitrary decision e.g. the left operand wins.
You get quite far. E.g.
a = {1: "a", 2: "b"}
b = {1: "c", 3: "d"}
# These already work:
assert 1 in a
assert 1 in b
assert 3 not in a
# etc.
# These would be new (the equivalent augmented assignments would work too):
assert a|b == {1: "a", 2: "b", 3: "c"}
assert a&b == {1: "a"}
assert a^b == {2: "b", 3: "d"}
assert a-b == {2: "b"}
assert b-a == {3: "d"}
# We could use these equivalencies:
assert {1} == {1: None} == set({1: "a"}) # I.e. canonical sets have
all None values
# And of course it would solve the empty set notation problem nicely:
assert dict() == {} == set()
Unfortunately we couldn't redefine <=, <, >=, > to mean various
subset/superset tests without backwards incompatibilities (but does
anyone care?), and == and != would of course take the values into
account which would occasionally sting. Also, sets would grow some
operations that don't make a lot of sense (e.g. __getitem__, get,
setdefault) but that's minor once you know the same implementation is
used.
I still expect there's a fatal flaw in the scheme, but I can't think
of it right now...
--Guido
On 7/8/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > moreover, you can say a set is a "kind of" a keys-only dict. in fact,
> > the first implementation of set used a dict, where the keys where the
> > elements of the set, and their value was always True.
>
> Or you could adopt the approach used by SETL: A dict is equivalent to a set
> of 2-tuples. In other words, {1:2, 3:4} could be defined as being
> equivalent to {(1,2), (3,4)}, with the run-time system being responsible for
> maintaining the information needed for efficient associative access. Then
> there's no question about the type of {}, because there's really only one
> type.
>
> No, I'm not serious; I think it would be too big a change. But you have to
> admit it's a cool idea :-)
>
>
> ___
> Python-3000 mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Lexical Scoping and Javascript
Talin wrote: > I would like to refer everyone to a very interesting URL: > > http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7 Let me follow up with Brendan Eich's XTech 2006 presentation on 'JavaScript 2 And the Future of The Web': http://developer.mozilla.org/presentations/xtech2006/javascript/ The short version is that JS2 is actively being reshaped to look a lot more like Python. -- Ivan Krstic <[EMAIL PROTECTED]> | GPG: 0x147C722D ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] No Container Literals
On 7/8/06, Aahz <[EMAIL PROTECTED]> wrote: > On Sat, Jul 08, 2006, Calvin Spealman wrote: > > Just throwing this out there, but I would love to see a complete > > dropping of container literals from Python. That is why I proposed the > > coercion syntax (ex: list from something) because it would allow > > things like list(1, 2, 3) and we can already do dict(ten=10, > > eleven=11), so what is the real need for literals as they are? With > > some proper compiler optimization we can deduce if list, dict, and > > such are in fact bound to the builtins we know, and build literals > > from these expressions just the same, but I feel they seem much more > > readable, and allow better addition of more literal compilations (set > > literals are fixed then, for example). I know no one will like this, > > but I have to make the idea known anyway. > > Could someone add this to the rejected proposals PEP? Done. Has Calvin explained *why* he wants this yet? (Not that that will make me change my mind. I'm just curious. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Switch and static, redux
Guido van Rossum wrote: > On 7/7/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > >> You seem to be conflating "nested functions" and >> "functional programming", which doesn't make sense >> to me. > > Not even a smidgen? Small nested functions (or lambdas) are pretty > common in a functional style. Yes, but the implication doesn't go the other way -- there are uses for nested functions outside of the functional paradigm. The defining characteristic of the functional style is absence of side effects, not presence of nested functions. And it's certainly not absence of case statements -- case-like pattern matching is used all the time in functional languages. > I don't like storing it as a global; and that's probably incorrect > too, e.g. if multiple definitions of f are being made in a loop. I'm not so sure it would be wrong -- the cases are meant to be constant, remember? So they shouldn't be changing between definitions of f()! But if you really want to allow for this, it's still easy -- store in a cell in the f_closure of the function object created by def f(). Functions nested within f find it the same way they find any other cell, i.e. it gets passed down to them through the scoping system. This is exactly the same mechanism you would use to attach it to g(), except that you're hauling it up more than one level. > The kind of optimization that's within reach for the CPython compiler > is pretty much limited to compile-time constant expressions, By "optimisation" I just mean avoiding the recomputation of case values as much as reasonably practical. And it seems quite reasonably practical to me to only compute the case values of g() once in the example I gave -- for reasons which I think are obvious to a human reader of the program. > Questions like "why did my code suddenly change from O(log N) to O(N) > performance" are really hard to answer if it's the compiler (not) > taking a shortcut in one case. The number of times the cases are evaluated would only make a constant-factor difference to the running time, not an O() difference. > we can have two nearly identical cases involving an outer and an > inner def, the latter containing a switch; yet one is fast and the > other is slow, and the clue is that the slow one uses a local variable > of the outer def in the switch. That's true, but we seem to differ on how much of a problem that will be in practice. If the case values really are constant (we do agree that they *should* be, don't we?) then this situation is almost never going to arise, because there's no reason you would want to use anything other than a module-level variable in a case. So I'm calling FUD on that one. With your scheme, the nested case would *always* be slow, with no straightforward means available to make it fast. With mine, it would *almost always* be fast, unless you're trying to do something screwy like use non-constant cases, in which case you're asking for trouble anyway. And if you *mistakenly* use something non-constant as a case, then that's a bug which is likely to bite you in other ways as well, so you've got a debugging problem anyway. > The other POV is that of the expert > user trying to understand (accidentally) obfuscated code. I still like > there to be simple rules to rememver for the latter. For an expert user, I don't think "outermost possible function object" is substantially harder to grasp than "immediately enclosing function object". -- Greg ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] set literals
Andrew Koenig wrote: > Or you could adopt the approach used by SETL: A dict is equivalent to a set > of 2-tuples. > > No, I'm not serious; I think it would be too big a change. But you have to > admit it's a cool idea :-) One fairly disastrous consequence would be that the *values* would have to be hashable as well as the keys... -- Greg ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] No Container Literals
Calvin Spealman wrote: > Just throwing this out there, but I would love to see a complete > dropping of container literals from Python. ... it would allow > things like list(1, 2, 3) ... I feel they seem much more > readable, That's highly debatable. There's semiotic value in not having everything built out of function calls. -- Greg ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] No Container Literals
Calvin Spealman wrote:
> dict(1=2) could be allowed, with additional syntax rules.
No, it couldn't, unless you were willing to give up
on dict(a=2) being equivalent to {'a':2} rather than
{a:2}.
--
Greg
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Lexical Scoping and Javascript
Talin wrote: > As you can see, there are a lot of features that are being considered > for inclusion in Javascript that have been pretty much copied verbatim > from Python. If Javascript and Python continue to converge like this, there mightn't need to be a browser-embeddable Python implementation -- the Javascript people will end up doing it for us! -- Greg ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Switch and static, redux
On 7/9/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > For an expert user, I don't think "outermost possible > function object" is substantially harder to grasp than > "immediately enclosing function object". I'm not getting through here. I think it is harder to debug because now you have to take into account the scopes of all cases, which may mean inspecting a lot of code. I'm just going to make an executive decision here to end the discussion. IMO the number of times that your proposal produces better results than mine is so small that it's not worth the complexity. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] Lexical Scoping and Javascript
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Talin wrote: > >> As you can see, there are a lot of features that are being considered >> for inclusion in Javascript that have been pretty much copied verbatim >> from Python. > > If Javascript and Python continue to converge like this, > there mightn't need to be a browser-embeddable Python > implementation -- the Javascript people will end up > doing it for us! If only we could persuade them to drop the braces... though maybe embedded in html/xml is one place they are useful. tjr ___ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
