On Thu, 3 Feb 2000 gvwilson@nevex.com wrote:
> FWIW, I favor {3, 5, 7} because it's similar to the notation for
> dictionaries.
>
> Greg
>
> On Thu, 3 Feb 2000, Ka-Ping Yee wrote:
> > On Thu, 3 Feb 2000, Greg Stein wrote:
> > >
> > > I think the follow is just as readable, if not more so:
> > >
> > > >>> s = set(1, 5, 7)
> > >
> > > Where set() is a new builtin, taking an arbitrary number of arguments and
> > > returning a new Set type.
> >
> > Sure. We would certainly need a set() built-in anyway.
> > I just thought the {1, 5, 7} syntax would be quite nice
> > for math-and-science people, as it matches textbooks well.
Context was dropped here. I had stated earlier (in my original note) that
{3, 5, 7} is syntactically ambiguous. It *can* be resolved, but it would
truly be messy. Borrowing Tim's Guido-channeling-headgear, I foresee that
Guido wouldn't want to implement sets if it creates this kind of ambiguity
and hackery in the parser/compiler.
Cheers,
-g
p.s. Basically, the problem is the parser can't detect certain types of
syntax errors in dictionary/set construction, but has to defer them to the
byte-compile phase. Unfortunately, this means you can have a syntax tree
that represents an invalid Python program. Given the increasing interest
in manipulating syntax trees, this would imply that tools will have to be
aware of this "feature" of syntax trees. Or we'd have to insert a
post-parse tree walk to find these (and report an error before allowing
tools to access the parse tree). There's more along this line, but I hope
that I've clarified the issue (at least, as I see it :-)
--
Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4