On 12/18/2011 2:36, Steven D'Aprano wrote: > The barrier to new keywords in Python is very high. Not going to > happen for something that already has perfectly good syntax already > familiar to Python and Ruby programmers. Might else well try to get C > and Java to stop using "..." (ellipses). I agree to some extent; I did say my suggestion was somewhat an effort in brainstorming. (Though I would point out that, if you accept the premise of this PEP suggestion, "perfectly good" only sort of applies.)
> The burden is that you complicate the compiler and reduce the pool of > useful names available to the programmer. To be useful, the keywords need > to be short, meaningful and memorable -- which means they're already used > in code, which you will break needlessly. OTOH, it wouldn't be the first time it was done. For instance, 'with'. > With operators that otherwise would be illegal, the programmer doesn't > need to learn about varargs until they need to. With keywords, the > programmer needs to learn "you can't use varargs or kwargs as variable > names" practically from day 1. Yes, but it's not exactly a hard lesson. I can't think of any time where you'd have ambiguous syntax, so misuse could always produce a good error message. And keyword highlighting is something that basically all editors can do well... so unless you're opposed to using an editor more advanced than Notepad, you'll type in "varargs", it'll turn purple or whatever, and you'll go "oh that's a keyword." > So you're not just adding keywords, you're adding new syntax: something > which looks like a function call, but isn't a function call. Well, almost by definition these proposals consider adding syntax. > I'm going to pose the same question to you I have already posed to Eelco: > in your proposal, what happens if the caller has shadowed the list built- > in? Does argument l become a built-in list, or does it become whatever > type list is currently bound to? > > Some more questions: > > Can varargs accepted arbitrary callables, or only a fixed set of known > types? > > How does this differ from what can be done with annotations? These are questions I don't feel I can answer very well. I was giving my thoughts on what I would do or consider doing with the proposal assuming the fundamental idea is sound. Whether it should be accepted at all is a matter for someone else. :-) Evan
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list
