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:
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/xtech
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 al
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.
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 t
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
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]
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
implementat
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
"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 con
10 matches
Mail list logo
