473,322 Members | 1,610 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

pep-318 questions

....and opinions:-)

I don't understand some of the arguments in pep-318 (version 1.19),
or what the current syntax has to do with some of the design goals
mentioned there. Could someone explain?
Design Goals

The new syntax should
(...)
make it obvious what is happening; at the very least it should be
obvious that new users can safely ignore it when writing their own
code
Huh? The current no-keyword, no-indentation syntax seems as far
removed from "obvious" as one could get for Python.

As for obvious that new users need not use it, it seems pretty hard
to _avoid_ meeting that goal. Is it just included for completeness,
or does it mean something more than I see in the statement?
not make it more difficult to scan through code quickly. It should
still be easy to search for all definitions, a particular definition,
or the arguments that a function accepts
The current syntax seems like the clear loser here too:
No whitespace above the function name. Not too bad with a single
decorator, but several is a problem. In fact, I think decorator-
before-def scales very badly in this respect, at least the syntaxes
without indentation. And the way people are coming up with uses for
decorators, functions could end up with a lot of decorators.

Quoting Arthur, "Doesn't readibility require that you have the
ability to move in a direction down the page, and, if so, why am I
getting information about a method prior to the existence of the
method, before a proper introduction has been made, i.e. before I
even know its name."

Anyway, to me, decorator after the def's ':' seems like the clear
winner on the "easy to scan" point, decorator before ':' might
possibly be #2 (unsure here - it's "theoretically right" but some
posted examples look ugly), and a statement with indentation in
front of the def #3. (Could indent just the decorators like the
'using' suggestion in the PEP, see below.)
Alternate Proposals using:
dec1
dec2
...
def foo(arg1, arg2, ...):
pass

The function definition is not nested within the using: block
making it impossible to tell which objects following the block
will be decorated.
Huh? How is this different from telling which 'else:' is tied to an
'if:'?

It does give the def statement a new syntax in that it can be the
2nd part of a compound statement. Is that what you mean - that
people who do not know about decorators won't know they must read
the 'using:' together with the 'def:'? If so, it seems to me that
the cure is exactly the same as with the @ syntax: Don't put any
whitespace between the decorator and the def. If you do put
whitespace there, both syntaxes lose readers who do not know about
decorators. And probably some readers who do, as well.
Nesting the function definition within the using: block suggests
nesting of namespaces that doesn't exist.
Why, when try:, if:, for: and while: do not?
True, this surprised me when I learned Python. But when I had
learned it, I had learned it.
Finally, it would require the introduction of a new keyword.


Actually, I'm wondering about that too. As far as I can see, if a
statement starts with one word and a colon, then the word is a
keyword. If so, it would not be ambiguous to allow 'using', 'else'
and 'try' as variable names. And since they are immediately
followed by the colon, the parser only needs one lookahead symbol to
tell that they are keywords. Yet I do see that it might complicate
the parser somewhat, and allow more bugs or more obscure error
messages when someone forgets the colon.

Anyway, '@using:' could be an alternative, even if it has an excess
of special characters. Or __future__, of course.

--
Hallvard
Jul 18 '05 #1
3 1126

Hallvard> I don't understand some of the arguments in pep-318 (version
Hallvard> 1.19), or what the current syntax has to do with some of the
Hallvard> design goals mentioned there. Could someone explain?

The PEP is known to be pretty far out-of-date with both the current patch
and current thinking. Anthony Baxter and I are the people who have most
recently edited it, but we are both short on time. I was out of town for
three days and returned to more than a thousand Python-related mails, most
dealing with PEP 318. I'm still digging out from that avalanche and have
yet to even look at the text of the PEP for several days, let alone
incorporate the wiki page or any of the comments here or in python-dev into
the text.
Design Goals

The new syntax should
(...)
make it obvious what is happening; at the very least it should be
obvious that new users can safely ignore it when writing their own
code
Hallvard> Huh? The current no-keyword, no-indentation syntax seems as
Hallvard> far removed from "obvious" as one could get for Python.

I think it's fairly well understood at this point that "obvious" is both in
the eye of the beholder and difficult to achieve (there's not a large body
of similar features in enough other languages that most programmers will
have had experience with). Thankfully, it says "should" instead of
"must". ;-)

Hallvard> As for obvious that new users need not use it, it seems pretty
Hallvard> hard to _avoid_ meeting that goal. Is it just included for
Hallvard> completeness, or does it mean something more than I see in the
Hallvard> statement?

I can take it out if you like. ;-)

I think the biggest single requirement has to be that any solution adopted
must be easier to use than the current decorate-after-body scheme:

def func(a, b):
blah
blah
... 75 more lines ...
blah
return blah
func = staticmethod(func)

Thankfully, all proposals I've seen satisfy that requirement.

Hallvard> The current syntax seems like the clear loser here too: No
Hallvard> whitespace above the function name. Not too bad with a single
Hallvard> decorator, but several is a problem.

There's no requirement that you smash them all together. This is valid with
the current patch:

@ a

# comment
# comment
# comment
# comment
@ b
def func(*args, **kwds):
...

Hallvard> Anyway, to me, decorator after the def's ':' seems like the
Hallvard> clear winner on the "easy to scan" point, decorator before ':'
Hallvard> might possibly be #2 (unsure here - it's "theoretically right"
Hallvard> but some posted examples look ugly), and a statement with
Hallvard> indentation in front of the def #3. (Could indent just the
Hallvard> decorators like the 'using' suggestion in the PEP, see below.)

I think Guido pronounced on this over the weekend. He stated that
decorators don't belong indented with the code, even at the beginning. In
fact, he commented that in retrospect he feels that doc strings belong
outside the function as well. (Of course, that would present a practical
conflict between a module's doc string and that of the first executable code
in the module file should it happen to be a function definition. But I
digress...)
Finally, it would require the introduction of a new keyword.


Hallvard> Actually, I'm wondering about that too.

Nobody has so far been able to come up with a single keyword that seems to
connote "this is a decorator function that is to be applied to the next
function definition".

Skip
Jul 18 '05 #2
Skip Montanaro <sk**@pobox.com> wrote in message news:<ma**************************************@pyt hon.org>...
<snip>
I think Guido pronounced on this over the weekend. He stated that
decorators don't belong indented with the code, even at the beginning. In
fact, he commented that in retrospect he feels that doc strings belong
outside the function as well. (Of course, that would present a practical
conflict between a module's doc string and that of the first executable code
in the module file should it happen to be a function definition. But I
digress...)
The nice thing about the @decor syntax is that it might be easy to
extend it to @"""Docstring""" - "decorate" a function (or class) with
the docstring if the decorator expression is a string literal instead
of an expression.

I prefer in-body docstrings though. While function decorators should
be well visible - they may do important changes to function's behavior
- the docstring is of secondary importance, only needed when we don't
know/remember what the function/class does (and hence should also fold
easily in a folding editor).
<snip>
Nobody has so far been able to come up with a single keyword that seems to
connote "this is a decorator function that is to be applied to the next
function definition".


And '@' does good job of it - it stands out well. Plus, it's a
decorated 'a' in many fonts :)

AdSR
Jul 18 '05 #3
Sorry with the late reply; when I got back to clp I had the silly idea
that I'd try to catch up with the decorator threads before answering...
Anyway,

Skip Montanaro wrote:
Hallvard> The current syntax seems like the clear loser here too: No
Hallvard> whitespace above the function name. Not too bad with a single
Hallvard> decorator, but several is a problem.

There's no requirement that you smash them all together. This is valid with
the current patch:

@ a

# comment
# comment
# comment
# comment
@ b
def func(*args, **kwds):
...


Which is even worse because one can easily miss some of the decorators
after locating the function.
>> Finally, it would require the introduction of a new keyword.


Hallvard> Actually, I'm wondering about that too.

Nobody has so far been able to come up with a single keyword that seems to
connote "this is a decorator function that is to be applied to the next
function definition".


I thought the main objection to a keyword is that it breaks existing
code; I wasn't talking about _which_ keyword to choose.

My point is that maybe the J2 syntax does _not_ need to be a keyword.

It should work to recognize statements that begin with one word and a
colon, and treat that word as a pseudo-keyword in that statement. As
far as I can tell, that does not break anything: A valid statement
cannot begin with a non-keyword followed by a colon today.

That also makes 'apply' a candidate for the... pseudo-keyword, if anyone
still wants that one.

And if anyone wanted to, one could make 'else', 'try' and 'finally'
into non-keywords so they could be used as variables:-)

--
Hallvard
Jul 18 '05 #4

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Christoph Becker-Freyseng | last post by:
Hello, recently there was a lot discussion about a new Path-class. So Gerrit Holl started to write a pre-PEP http://people.nl.linux.org/~gerrit/creaties/path/pep-xxxx.html We tried to...
27
by: John Roth | last post by:
PEP 263 is marked finished in the PEP index, however I haven't seen the specified Phase 2 in the list of changes for 2.4 which is when I expected it. Did phase 2 get cancelled, or is it just not...
0
by: Nick Coghlan | last post by:
Anyone playing with the CPython interpreter's new command line switch might have noticed that it only works with top-level modules (i.e. scripts that are directly on sys.path). If the script is...
15
by: Nick Coghlan | last post by:
Python 2.4's -m command line switch only works for modules directly on sys.path. Trying to use it with modules inside packages will fail with a "Module not found" error. This PEP aims to fix that...
18
by: Steven Bethard | last post by:
In the "empty classes as c structs?" thread, we've been talking in some detail about my proposed "generic objects" PEP. Based on a number of suggestions, I'm thinking more and more that instead of...
14
by: Marcin Ciura | last post by:
Here is a pre-PEP about print that I wrote recently. Please let me know what is the community's opinion on it. Cheers, Marcin PEP: XXX Title: Print Without Intervening Space Version:...
8
by: Micah Elliott | last post by:
I also have this living as a wiki <http://tracos.org/codetag/wiki/Pep> if people would like to add comments there. I might try to capture there feedback from this group anyway. First try at a PEP...
2
by: Bryan Olson | last post by:
Though I tried to submit a (pre-) PEP in the proper form through the proper channels, it has disappeared into the ether. In building a class that supports Python's slicing interface, ...
77
by: Ben Finney | last post by:
Howdy all, PEP 354: Enumerations in Python has been accepted as a draft PEP. The current version can be viewed online: <URL:http://www.python.org/peps/pep-0354.html> Here is the...
4
by: dustin | last post by:
I've been hacking away on this PEP for a while, and there has been some related discussion on python-dev that went into the PEP: ...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.