Pete Shinners:
> Some of these may even be bad ideas apon further
> thought, but it's something to ponder.
Also, many of them don't work with the proposed
syntax. Specifically, you're trying to provide
a second binding for the function (such as running
for __main__, or registering with the exit handler).
For me, this is the most common use case, but ...
PEP 318 doesn't handle it. (Which is one reason
that I don't think this will be the *last* extension,
which is one reason I don't want *bare* syntax.)
Skip:
> Quixote'd PTL uses almost this exact syntax to
> distinguish between PTL functions/methods which
> return HTML or plain text. The only difference
> is that it places the annotation before the argument
> list:
> def head [html] (title):
> I haven't heard any Quixote users complain about the
> construct.
But they do warn you that it doesn't quite work with
standard python. Nobody comes across this syntax until
they have gone out of their way to expect it. Even so,
would it be better or worse for them to start finding
code that says
def head [classmethod] (title):
I realize that the new syntax (patch version) would
actually say something more like
def head [html](title)[classmethod]:
which goes a fair way toward exhausting special syntax.
If they want to get more detailed (xml vs html, only
do this if the user is authenticated, etc), then the
new syntax starts to be useful to them as well.
def head(title) decorators[html4, authenticated_user]:
Even if the two cases are combined, I don't see it
as useful enough to use up bare syntax. (And so I
suggest yet another possible keyword, "decorators")
Paul Prescod:
> C# allows the wrapping of attributes, not just
> functions and classes.
> In Python this could be accomplished if we used
> delimiters that didn't look like lists (e.g. <> or [! !]).
Do this sort of thing often enough, and you have a
keyword anyhow -- it just happens to look like line noise.
> C# distinguishes between bareword declarations like
> "public" and "int" and metadata attachments like
> XML serialization information.
...
> The Java way does make clear what is a language builtin
> ("public", "void") and what is extension metadata
> "@remote", "@debug". That may not be a bad thing...
Unless we define a specific list (just classmethod and
staticmethod?), then this might be more confusing than
useful. in __builtins__? In the current standard library?
in another module that might become standard someday?
Skip Montanaro:
> If anything, features which are expected to be used by
> more advanced users should require less "COBOL" to be
> useful. I'm not arguing that the zen of Python shouldn't
> apply, just that advanced features (which will probably
> be used a lot less than more basic features) don't
> necessarily need quite the English-like structure supporting
> them in the language syntax.
Features which are used frequently need to be short.
Features which are used rarely (like this one?) can be
more verbose.
I agree that if only advanced users will need it, then it
can be a bit more complex to use. It should absolutely
not be harder to recognize as irrelevant.
If you use an almost meaningless keyword like
"extended_syntax_form_a", then the only extra burden is
on the advanced users who actually use it. (This is one
reason that I'm not too concerned over *which* keyword
gets used.) If you use bare syntax, then the burden is
on everyone, and you have raised the barrier to entry for
the rest of the language.
Paul Moore:
> Exactly. As a beginner, classes were more advanced than
> you needed. So the (relative) difficulty of finding the
> relevant details wasn't an issue - you just didn't use
> the feature for a while. By the time you needed classes,
> you were familiar enough with Python to know where to look.
I have never *needed* classes, and have a bias towards
functions. If *functions* had seemed awkward, I would have
chosen another language instead. People with a bias
towards objects - or wanting to learn about them - may
well have different criteria. (In real life, most
object systems are pretty wordy, so this particular concern
may not bother OO folk as much. But the main use cases are
for functions.)
-jJ
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