Jim Jewett wrote:

One of the problems with the current syntax is that calling sites

...

don't match the definition site the way they do for normal functions. This proposal doesn't seem to help with that. ...

def m(self, a, b, z=None): ...

...

# self is moved outside the parens, changing the tuple size self.m(a, b, z) self.m(a, b)

On Sun, Aug 24, 2008 at 6:26 PM, Terry Reedy <tjreedy@udel.edu> wrote:

If m is an attribute of type(s) (which is s.__class__), this shrinkage is a convenient abbreviation, not a requirement. The above calls are the same as type(s).m(s.a,b,z) or type(s).m(s,a,b). Or, if you prefer, fn = type(s).m # or s.__class__.m fn(s,a,b,z) If m is an attribute s, and s in not a class, the shrinkage is not available, and one must write s.m(s,a,b,z) or s.m(s.a,b).

Terry Jan Reedy

If I could write: class foo: def self.bar(): self.rebar(self.babar) then the call to object.bar() would match the declaration. Back to Russ's proposal: it would be better accomodated IMHO by allowing $ as a character in a variable name, just like _ is. Then, conventionally, people could use $ as self: def $.bar(): $.rebar($.babar) and for whatever it's worth, I find $.bar easier to read then $bar as the explicit dot reminds me it's doing an attribute get rather than looking like a special variable name. --- Bruce

Brandon Mintern wrote:

Having used Lisp before Python, I'm used to just about any character being allowed in identifier names. The more characters available, the more expressive the names can be, and I think it could only help things.

3.0 uses the standard Unicode syntax for identifiers: " identifier ::= id_start id_continue* id_start ::= <all characters in general categories Lu, Ll, Lt, Lm, Lo, Nl, the underscore, and characters with the Other_ID_Start property> id_continue ::= <all characters in id_start, plus characters in the categories Mn, Mc, Nd, Pc and others with the Other_ID_Continue property> " This is 10s of thousands of characters ;-) -- but no symbols. " The Unicode category codes mentioned above stand for: Lu - uppercase letters Ll - lowercase letters Lt - titlecase letters Lm - modifier letters Lo - other letters Nl - letter numbers Mn - nonspacing marks Mc - spacing combining marks Nd - decimal numbers Pc - connector punctuations All identifiers are converted into the normal form NFC while parsing; comparison of identifiers is based on NFC. " I think we should stick with this international cross-language standard. tjr

Jim Jewett schrieb:

On Mon, Aug 25, 2008 at 11:46 AM, Terry Reedy > 3.0 uses the standard Unicode syntax for identifiers:

...

" identifier ::= id_start id_continue*

id_start ::= <all characters in general categories Lu, Ll, Lt, Lm, Lo, Nl, the underscore, and characters with the Other_ID_Start property>

Are you sure?

IIRC, the unicode consortion themselves recommend the xid_start and xid_continue properties instead.

I thought we were already using them. Georg

Brandon Mintern wrote:

The more characters available, the more expressive the names can be,

Also the more confusing they can be. It's bearable in Lisp because there are very few characters that have special meaning to the parser, and most symbols are set off by whitespace or parentheses. But in Python, most punctuation is syntactically special, and names are set off by operators at least as often as whitespace. So allowing just a few randomly-chosen punctuation chars as part of names would be confusing, I think. I find that Ruby code with ! and ? in variable names trips up my visual parser, for example. I see something like set! and it looks like the name 'set' followed by a '!' operator. -- Greg

On Mon, Aug 25, 2008 at 06:41:06PM -0700, Russ Paielli wrote:

Just for fun, I made a copy of one of my Python files with hundreds of occurrences of "self", and I replaced them all with "S". This streamlines things significantly, and I think it looks good, but I suppose most Python aficionados would be aghast. I'm thinking about doing it permanently for all my files. I normally avoid single-character names, but I think this case could be a reasonable exception. What would you think if you saw this in "production" code?

I'd be against it because it violates a well-established convention. I consider having a One True Style (a naming convention in this particular case) is a Good Thing. I am accustomed to that naming convention; if I see code with a different convention I'd have problems reading and understanding it. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

My editor, Xemacs, also highlights the word "self." I personally find that a bit annoying, and perhaps that is part of the reason I don't appreciate the word. When I write an algorithm, I don't want to see some artifact highlighted, as if it is somehow the most important part of the algorithm. I like seeing keywords highlighted, but I don't want to see "self" highlighted because it is only a convention. Maybe I'm alone on that. As I wrote earlier, I copied one of my larger Python files and replaced each occurrence of "self" with "S". That was approximately 350 occurrences. I also replaced each occurrence of "cls" with "C", which was another 50 or so occurrences. The file size was reduced by 2.8%, many wrapped lines no longer need to wrap, and I like the way it looks. I understand that people like to have "one true way," but I think Python programmers are adaptable enough to handle this one. When you read code, you certainly need to read the argument names anyway, so the fact that "S" is being used instead of "self" should be obvious. The only minor disadvantage I can think of is that searching on a single character can be problematic, but if you are using an IDE, that should not be an issue (and I can't remember ever searching on "self" anyway). One of these days, when I get a chance, I may write an informational PEP recommending the use of "S" as an acceptable replacement for "self", and "C" as an accptable replacement for "cls". I hope that doesn't blow any fuses. Have a nice day. --Russ On Mon, Aug 25, 2008 at 11:58 PM, Torsten Bronger < bronger@physik.rwth-aachen.de> wrote:

Hallöchen!

Russ Paielli writes:

...

Just for fun, I made a copy of one of my Python files with hundreds of occurrences of "self", and I replaced them all with "S". This streamlines things significantly, and I think it looks good, but I suppose most Python aficionados would be aghast. I'm thinking about doing it permanently for all my files. I normally avoid single-character names, but I think this case could be a reasonable exception. What would you think if you saw this in "production" code?

The "self" convention goes so far that my editor highlights it -- this may be true for other editors/HTML highlighters, too. I'd even frown upon any programmer who breaks this convention for code that has the slightest chance to become public.

Besides, I don't consider "self"s cluttering up the code. YMMV, but I don't measure code legibility by the terseness of certain identifies at all.

Tschö, Torsten.

-- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bronger@jabber.rwth-aachen.de

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- http://RussP.us

Normally I agree with you on the single-character identifiers, but I consider this case an exception. Lets not forget that C++ and Java use zero-character identifiers for "self", and I don't hear a din of complaints that it harms readability. My code does not appear to me to be any less readable to me when I substitute "S" for "self". The fact that it is a capital letter helps a bit here, I think. The fact that it usually appears as "S.attr" rather than just "S" also makes it stand out clearly. I just don't see the problem with having an "approved" shorthand form for self when it does not require any changes in the language itself. --Russ On Wed, Aug 27, 2008 at 12:11 AM, Cesare Di Mauro <cesare.dimauro@a-tono.com

wrote:

On 27 aug 2008 at 02:02:39, Russ Paielli <russ.paielli@gmail.com> wrote:

...

My editor, Xemacs, also highlights the word "self." I personally find that a bit annoying, and perhaps that is part of the reason I don't appreciate the word. When I write an algorithm, I don't want to see some artifact highlighted, as if it is somehow the most important part of the algorithm. I like seeing keywords highlighted, but I don't want to see "self" highlighted because it is only a convention. Maybe I'm alone on that.

As I wrote earlier, I copied one of my larger Python files and replaced each occurrence of "self" with "S". That was approximately 350 occurrences. I also replaced each occurrence of "cls" with "C", which was another 50 or so occurrences. The file size was reduced by 2.8%, many wrapped lines no longer need to wrap, and I like the way it looks.

I understand that people like to have "one true way," but I think Python programmers are adaptable enough to handle this one. When you read code, you certainly need to read the argument names anyway, so the fact that "S" is being used instead of "self" should be obvious. The only minor disadvantage I can think of is that searching on a single character can be problematic, but if you are using an IDE, that should not be an issue (and I can't remember ever searching on "self" anyway).

One of these days, when I get a chance, I may write an informational PEP recommending the use of "S" as an acceptable replacement for "self", and "C" as an accptable replacement for "cls". I hope that doesn't blow any fuses.

Have a nice day.

--Russ

I absolutely disagree. It's the same thing that happens when we use one character identifiers: the code becomes less readable.

Identifiers must be self-explicative.

Cheers, Cesare

-- http://RussP.us

Russ Paielli schrieb:

Normally I agree with you on the single-character identifiers, but I consider this case an exception. Lets not forget that C++ and Java use zero-character identifiers for "self", and I don't hear a din of complaints that it harms readability.

Yes, because most have coding styles that mandate hungarian prefixes on such identifiers. And "mInfo" isn't really more readable than "self.info". Georg

On Wed, Aug 27, 2008 at 8:38 PM, Greg Ewing <greg.ewing@canterbury.ac.nz>wrote: Russ Paielli wrote:

...

Lets not forget that C++ and Java use zero-character identifiers for "self", and I don't hear a din of complaints that it harms readability.

I'm not so sure about that. Frequently people adopt conventions such as always writing this->x, or naming all instance variables with an "m_" prefix, suggesting that zero characters is considered a problem by many.

And that's despite the fact that they have more assistance from IDEs for autocomplete, highlighting, etc. George

On Tue, Aug 26, 2008 at 5:02 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

My editor, Xemacs, also highlights the word "self." I personally find that a bit annoying, and perhaps that is part of the reason I don't appreciate the word. When I write an algorithm, I don't want to see some artifact highlighted, as if it is somehow the most important part of the algorithm. I like seeing keywords highlighted, but I don't want to see "self" highlighted because it is only a convention. Maybe I'm alone on that.

As I wrote earlier, I copied one of my larger Python files and replaced each occurrence of "self" with "S". That was approximately 350 occurrences. I also replaced each occurrence of "cls" with "C", which was another 50 or so occurrences. The file size was reduced by 2.8%, many wrapped lines no longer need to wrap, and I like the way it looks.

I understand that people like to have "one true way," but I think Python programmers are adaptable enough to handle this one. When you read code, you certainly need to read the argument names anyway, so the fact that "S" is being used instead of "self" should be obvious. The only minor disadvantage I can think of is that searching on a single character can be problematic, but if you are using an IDE, that should not be an issue (and I can't remember ever searching on "self" anyway).

One of these days, when I get a chance, I may write an informational PEP recommending the use of "S" as an acceptable replacement for "self", and "C" as an accptable replacement for "cls". I hope that doesn't blow any fuses.

You can submit anything you want. You know what Guido is going to say with regards to self -> S and cls -> C as a proposed change to the PEP 8 style guide? Something along the lines of "no". He may even be that polite. What you do in your own code (that you write and maintain) is your own business. If S/C makes you happy: use it. But don't be surprised if/when someone starts working on that same code they start asking (perfectly valid) questions about why you chose to go against the PEP 8 style guide. - Josiah

I really don't think any of the proposed solutions are logically, functionally or aesthetically better than what we currently have with "def foo(self)". I find all proposed variants of "$.foo" to be jarring. "def self.bar()" is somewhat less ugly, but misleading since the method is actually being bound to its outer class, not "self" (presumably, any instances of that class rather than the class itself):

...

...

class Foo(object): ... def bar(self): ... print "Hello, 0x%x" % id(self) ... foo = Foo() Foo.bar(foo) Hello, 0xb7729f8c foo.bar() Hello, 0xb7729f8c

Note that the declaration of "bar" binds the function to class "Foo", not to the instance "foo". Would these semantics change with the "self.bar()" syntax? Either way it's a -1 from me until a more Pythonic proposal surfaces. I'm not sure there's a way to improve on the simplicity of the existing semantics though. Cheers, T Russ Paielli wrote:

On Mon, Aug 25, 2008 at 12:45 AM, Bruce Leban <bruce@leapyear.org <mailto:bruce@leapyear.org>> wrote:

Jim Jewett wrote:

If I could write:

class foo: def self.bar(): self.rebar(self.babar)

then the call to object.bar() would match the declaration.

Back to Russ's proposal: it would be better accomodated IMHO by allowing $ as a character in a variable name, just like _ is. Then, conventionally, people could use $ as self:

def $.bar(): $.rebar($.babar)

and for whatever it's worth, I find $.bar easier to read then $bar as the explicit dot reminds me it's doing an attribute get rather than looking like a special variable name.

def $.bar(): $.rebar($.babar)

That's two separate proposals, but I think I like both of them.

Of course, Python already allows "S", which is very similar to "$", as the first argument, so we're almost there on that aspect of it. Come to think of it, I may start using "S" and see how it works out.

So how about

def S.bar(): S.rebar(S.babar)

--Russ

------------------------------------------------------------------------

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

On Sun, Aug 24, 2008 at 8:22 PM, Terry Reedy <tjreedy@udel.edu> wrote:

Russ Paielli wrote: ...

...

instance for which it is called. What I will say is that I think Python syntax could be significantly simplified with the simple little convention that I am proposing. All I ask is that you carefully read my proposal before you reply. Thank you.

I have. It strikes me as an improvement over .attr and other ideas posted on c.l.p.

In Python, the class instance for which a method is called is referred to within the method by the first formal argument.

Somehow awkward.

By convention, that first argument is typically named "self".

For public code among English speakers. But how far this extends and for how long, given Unicode identifiers in 3.0, is a moot point for your proposal.

In Python, class instance methods are functions in which the first formal argument refers to the instance for which the method was called.

In Python, class instance methods are functions accessed as an attribute of the class, in particular of the object passed as the first argument. To me your discussion is weakened by the implication that Python has a method class separate from functions. (Bound methods are specialized partial-function wrappers; functools.partial is the general version.) For instance

could even work for regular functions if the first argument is an object with attributes and/or methods that can be accessed with standard "dot" notation.

Def statements produce functions. Period.

This proposal takes no position of whether the latter should be allowed or not.

To repeat: former *is* latter with a particular access path. So the question is not whether to 'allow' $ to work in functions; that *is* your proposal, whether you know it or not. To do otherwise would require some other significant change to Python, one that would complicate it.

Four possible candidates for the choice of that symbol are "~", "@", "^", and "$".

You left out "?" (not too good ;-) and now, in 3.0, "`" (backtick, no longer an repr synonym). The latter is lighter than "$" but perhaps more visible than ".", depending on the font. Hmmm, a comparison:

Minor point, but the backtick is NOT up for grabs, at least as of a discussion on this very list from last year. Quoting a response from Guido: """ On 1/2/07, Chris Rebert <cvrebert@gmail.com> wrote:

Thus, I propose one of the following as the new use for the backtick (`):

You're missing one of the main reasons for removing the backtick syntax in the first place: the character itself causes trouble by looking too much like a regular quote (depending on your font), is routinely mangled by typesetting software (as every Python book author can testify), and requires a four-finger chord on Swiss keyboards. No new uses for it will be accepted in Python 3000 no matter how good the idea. -- --Guido van Rossum (home page: http://www.python.org/~guido/) """ Not that I understand the relevance of Swiss keyboards, but anyway, there you have it. Perhaps we need to alias __future__.backtick to __future__.braces so people remember this ;) - Chris ======== Follow the path of the Iguana... Rebertia: http://rebertia.com Blog: http://blog.rebertia.com

self.d = sqrt(self.x*self.x + self.y*self.y)

s.d = sqrt(s.x*s.x + s.x*s.x)

.d = sqrt(.x*.x + .y*.y)

$d = sqrt($x*$x + $y*$y)

`d = sqrt(`s*`x + `y*`y)

I think I like this last best.

Terry Jan Reedy

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas