On Apr 14, 2006, at 4:43 AM, Guido van Rossum wrote: >> Kendall Clark wrote: >>> I don't know if the Ruby syntax for symbols, :foo, will work in >>> Python (though I think visually it's a good thing), but it would be >>> really nice to have symbols with *some* syntax in Python 3000. >>> >>> Again, this design request is based on aesthetics and fun: having >>> symbols would make Python more fun. > > I don't see how this particular feature adds more fun; I'd rather see > it argued on the basis of use cases.
Fair enough. My primary use case is using Python as a host for a Domain Specific Language. This may not be a core Python use case, though I don't know if that's true. It is something that happens a lot in Ruby (Rails has been described as a DSL for Web programming), Haskell, and Common Lisp. I think having a symbol type makes writing DSLs in Python easier (hence, my claim about "more fun"), since you can use symbols to reflect terms from the domain of the DSL in Python in a relatively easy way. Easier than creating a module full of constants or variables. Perhaps not really easier than using strings, but it expresses one's intent more clearly, IMO -- in a way I find analogous to using tuples instead of lists in some cases. > The aesthetics of the earlier proposal to use :foo to indicate symbols > are poor; using random punctuation is unpythonic (as is the use of ? > or ! in identifiers BTW) but more importantly there are a few > syntactic positions where it would be ambiguous, e.g. foo[:bar] > already means foo[0:(bar)]. Good points. (Though I don't concede that "?" and "!" in method or function identifiers is random. But that's beside the point.) I worried that :foo might make the grammar ambiguous, and I should have thought about that more. I'm more interested in having a symbol type than any particular concrete syntax, FWIW. So I'm happy to consider the :foo variant dead in the water. > I'd also like to point out (again?) that the "const-ness" of ALLCAPS > is a red herring; in practice, we treat almost all imported names as > constants, and in fact class and function names are generally > considered constant. (I've also seen plenty of code that used ALLCAPS > to indicate "configuration parameter" rather than "constant" and which > freely assigned to ALLCAPS variables in configuration code.) Agreed. I don't read ALLCAPS in Python as meaning constant. I almost always use it as configuration parameter, for cases where a separate configuration mechanism isn't warranged. > Somewhat unrelated: there's one advantage to enums (which have been > suggested as an alternative to symbols) which symbols don't share: if > you have a typo in an enum name, you presumably get an early, hard > NameError or AttributeError (and pychecker could easily check this); Yes, absolutely. That's entirely true. I assume that enums will be more heavyweight to create (that is, more keystrokes than simply writing the symbol straight away), which is perhaps an advantage for symbols. I'd like to see both added to Py3k. > but if you misspell a symbol, you just pass a different symbol, which > is likely to trigger a later error or no error at all (depending on > how the symbol is used). Of course, enums really serve a different use > case; they wouldn't help at all for the property-defining use case > Nick described here. Agreed; I think they are distinct and should be considered orthogonally. Cheers, Kendall _______________________________________________ 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
