> > MAL seems to want two other changes: directive should be allowed > > (required???) > > "allowed" not "required". but last I looked if there was a docstring before the directive you couldn't guarantee that the directive applied. > > before the module docstring, and it should support the > > syntax from his proto-PEP (directive key = value). > > > > But MAL and PaulP don't seem to agree on the semantics of this > > directive, and I haven't gotten a good answer why we can't do that > > with a magic comment. > > We don't ? It seems to me that each post from you gets a response from Paul with some kind of objection, and vice versa. Maybe you're converging, but I don't see where you are converging yet. Also, your arguments sometimes seem contradictory. For example, Paul has said that you may need a comment with an editor-specific encoding indicator, while you were expecting editors to look at the directive and made this a reason why the directive should precede the docstring. > Paul suggested adding encoding directives for 8-bit > strings and comments, but these cannot be used by the Python > compiler in any way and would only be for the benefit of an > editor, so I don't really see the need for them. Another indication you two aren't on the same page just yet. > A programmer > can still add some editor specific comment to the source file > to tell the editor in what encoding to display the file, but this > information is really only useful for the editor, not the > Python compiler. This redundancy worries me though. Are we going to encourage people to use an editor-specific comment for each editor out there that could be used to touch the file? > About the magic comment: Unicode literals are translated into > Unicode objects at compile time. The encoding information is > vital for the decoding to succeed. If you place this information > into a comment of the Python source code and have the compiler > depend on it, removing the comment would break your program. Yes, and so would removing a directive. I don't see the point at all. > I don't think that's good language design (besides, we already > have enough Unicode magic in Python already...), but then > people may feel different about this. Directives come with their own set of magic. > > In the mean time, I've decided to enable the yield keyword with a > > future statement. In general I now prefer using future statements for > > enabling future features over the directive statement. > > > > So it's still unclear if we want a directive... > > One way or another we need a way to specify compiler parameters > and settings on a per-source file basis. Whether you call it > directive, pragma or magic comment is really secondary and only > a matter of language design. I still haven't seen this need demonstrated. Most purported uses of these are better done with existing mechanisms. For example, in PEP 253 I propose an assignment to a global __metaclass__ to set the default class for a baseless class statement. > I've only chosen PEP 244 as basis for the PEP because it seemed > to fit the need. If you decide to go down some other path, > then I'll happily update the PEP to whatever becomes part of > Python. But you're implying without clearly specifying all sorts of amendments to PEP 244, which weakens your position. For example, PEP 244 allows a doc string before the directive, but you indicated that the directive can only affect strings that occur after it. I don't think this is true: the creation of actual string objects is done after the whole file has been parsed, is it wouldn't be hard to collect and interpret all directives before creating code objects. --Guido van Rossum (home page: http://www.python.org/~guido/)
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