Mitigating 'self.' Method Pollution
Last night I made a post to the neopythonic blog proposing a Python 3.x feature that Guido asked me to forward to this alias. For the full background, see the link to my post below. For brevity, I will simply submit the proposal here. The specific problem I am addressing is the pollution of Python methods by 'self.' to reference fields. Here is the proposal: The name of the first parameter to a method can be used to scope subsequent variable references similar to the behavior of 'global'. Here are some examples: class Foo: def method_a(self) self x # subsequent 'x' references are scoped to 'self' x = 5 # same as self.x = 5 def method_b(this) this x, y # subsequent 'x' & 'y' refs are scoped to 'this' x = y # same as this.x = this.y def method_c(its) its.x = 5 # still works just like it used to This suggestion is fully backward compatible with existing Python code, but would eliminate the need to pollute future Python methods with copious 'self.' prefixes, thereby improving both readability and maintainabilty. Thank you for your consideration. Michael Hewitt Original Post: http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html
On Fri, Jul 10, 2015 at 07:28:14PM -0400, Joseph Jevnik wrote:
How does this interact with descriptors, are they looked up everytime x and y are referenced or are they cached at the `this x, y` statement?
My understanding is that the actual execution of Python code does not change. Today, if you write: def method(self): self.spam = self.eggs + 1 it compiles to something like this (in Python 2.7, different versions may use different bytecode): 2 0 LOAD_FAST 0 (self) 3 LOAD_ATTR 0 (eggs) 6 LOAD_CONST 1 (1) 9 BINARY_ADD 10 LOAD_FAST 0 (self) 13 STORE_ATTR 1 (spam) 16 LOAD_CONST 0 (None) 19 RETURN_VALUE There's no caching of attribute look-ups, if spam or eggs are descriptors (methods, properties, etc.) the descriptor protocol gets called each time LOAD_ATTR or STORE_ATTR is called. If you re-write that to: def method(self): self spam, eggs spam = eggs + 1 it should compile to *exactly the same byte code*. It's just a compiler directive, telling the compiler to treat any "spam" and "eggs" tokens as if they were actually "self.spam" and "self.eggs". That would, of course, mean that it's impossible to have a local variable with the same name as the declared attribute. I often write micro-optimized code like this: spam = self.spam = {} for x in big_loop: # avoid the repeated look-ups of ".spam" spam[x] = something If I declared "self spam", this wouldn't work (or rather, it would work, but it wouldn't have the effect I am looking for). The solution is simple: don't declare "self spam" in this case. -- Steve
On 10/07/2015 23:31, Michael Hewitt wrote:
I disagree completely. When I see:- self.x = 1 I currently know exactly what I'm looking at. All I see with this proposal is more work for my MKI eyeballs, which are already knackered, and more work for the people who maintain our static analysis tools, as you can still forget to properly scope your variables. So -1.
-- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
Let's compare two versions of a method taken from some code that my 11 year old son wrote yesterday: *Current* global height def keep_moving_gravity(self): self.y += self.gravity self.y = max(self.y, 0) self.y = min(self.y, height - 1) *Proposed* global height def keep_moving_gravity(self): self y, gravity y += gravity y = max(y, 0) y = min(y, height - 1) Is anyone actually going to argue that the first version is cleaner and more readable than the second? All I see when I read the first is 'self', 'self', 'self' -- my son's exact words to me last night. As far as maintainability, the author of the first version must repeatedly make the same decisions over and over regarding how to scope each variable reference as he/she types 'y', 'gravity', and 'height'. The author of the second code makes these decisions exactly once at the top of the method and then is free to refer to each variable naturally without the mental overhead of prefixing each 'y' and 'gravity' with 'self.', but God forbid - not 'height'. I can tell you that the mental overhead of this is taxing my son & is the cause of many painful mistakes -- just forgetting a single 'self.' prefix on one of the above field references can waste a significant amount of time. As far as static analysis tools, this should honestly not be a lot of extra work, since the tools must already handle 'global' in a very similar fashion. If the 'self.' prefix really does make code clearer, then we should do away with the 'global' scope declaration as well as automatic local scoping and require prefixing of all Python variables with 'self.', 'global.' or 'local.'. My mind becomes numb thinking about writing such code. To me, the existence of the keyword 'global' for automatically scoping subsequent variable references is a strong argument that a similar 'self' scoping mechanism is called for as well. And, for folks who still prefer to prefix all their field references with 'self.', the proposal in no way prevents them from doing so. It merely allows the rest of us to be a bit less wordy and more pithy in our code. Mike On Friday, July 10, 2015, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On Sat, Jul 11, 2015 at 5:25 PM, Michael Hewitt <michael@hewitts.us> wrote:
Alternate proposal: # You could in-line this if you want to. def limit(low, n, high): """Limit a number to be within certain bounds""" return min(low, max(n, high)) def keep_moving_gravity(self): self.y = limit(0, self.y + self.gravity, height - 1) There are precisely two references to self.y (one reading, one writing), and one reference to self.gravity. The global identifier height needs no declaration, because it's not being assigned to. Instead of doing three operations (increment, then check against zero, then check against height), it simply does one: a bounded increment by gravity. Bad code is not itself an argument for a language change. Sometimes there's an even better alternative :) ChrisA
Chris Angelico writes:
That was my first reaction.
Bad code is not itself an argument for a language change. Sometimes there's an even better alternative :)
If you're a language wonk, it's obviously better, true (well, I'm a wannabe wonk so I say that and cross my fingers for luck :-). But if you're a very new and possibly very young programmer (both meaning you have little experience abstracting in this way) who's basically scripting your way through the problem, defining an "internal" function to be used once looks like throwing the garbage in the garage through a window onto the lawn. I think this is going to be be one of those features that "scripters"[1] and "programmers" evaluate very differently. Personally, I'm -1 but that says more about my proclivities than about the proposal. :-) Steve Footnotes: [1] Sorry if that sounds pejorative. It's not intended to. I tried to find a better term but failed.
Let me state my argument more succinctly. If 'self.' is a good thing, then *all* Python variable references should always be explicitly prefixed by their scope -- 'global.', 'local.', and 'self.'. Why does it make more sense to not require explicit scoping of global variables, which are far more dangerous, while requiring explicit class scoping when nothing is more natural than for a method to refer to variables within its own class? This is totally backwards. If anything, the opposite should be true. 'global.' should be required for *all* global references, of which there should be very few in well-written, modular code, and 'self.' should not be required for class references because of course methods are going to naturally refer to variables within their class. Keep in mind that the proposed design explicitly specifies the class variable scoping at the top of each method, so that anyone reading the method can simply look at the top of the method to find out which variables are class variables. On Sat, Jul 11, 2015 at 12:25 AM, Michael Hewitt <michael@hewitts.us> wrote:
On Sat, Jul 11, 2015 at 5:49 PM, Michael Hewitt <michael@hewitts.us> wrote:
How many times do you call on standard library functions? Those are almost always global references. Either you're looking for something directly from the builtins (eg len, max, range), or you import a module at the top of your file and then use that (eg math.sin, logging.info), in which case the module reference is itself a global of your own module. So, no. Globals are extremely common - just not often reassigned. ChrisA
On Jul 11, 2015, at 00:49, Michael Hewitt <michael@hewitts.us> wrote:
Let me state my argument more succinctly. If 'self.' is a good thing, then *all* Python variable references should always be explicitly prefixed by their scope -- 'global.', 'local.', and 'self.'.
If I were designing a new pythonesque language, I think I might well add something like that for when you need to disambiguate from the default, and then get rid of the global statement. In fact, if it weren't for the obvious huge backward compat problems, I might even go for a suggestion to do that in Python. Even for closure variables, I kind of like the look of "nonlocal.x = 3", although it's not _as_ compelling as "global.x = 3" to me. But the idea that self is a more important default than local, and we should therefore have SLEGB instead of LEGB for unqualified lookups, and self for unqualified assignments instead of local? Definitely not. Creating new locals is something I do in half my functions and methods; creating new attributes is something I rarely do outside of __init__ methods. I've used plenty of languages that don't require declarations, and I've never found one whose default rules made me as happy as Python's LEGB/L. It sort of works in languages where classes have a predefined set of attributes, but even there I don't like it as much; I always end up naming one set or the other with an underscore prefix or suffix or some other marker which is just "self." in a disguise that fools my tools.
On Sat, Jul 11, 2015 at 8:02 PM, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
Want it in Python? No problem. You can't have "global.x" because it's a keyword, but... globl = SimpleNamespace() def use_globals(): globl.x += 1 return globl.y If you want it, it's there, but I wouldn't bother with it for constants - including functions, which are globals just the same as any other. We do NOT need this kind of enforced adornment for all names. ChrisA
On Jul 11, 2015, at 03:13, Chris Angelico <rosuav@gmail.com> wrote:
But that doesn't give me what I want. The whole point is to continue to use the existing default LEGB rules for lookup (which is much more common), but to mark global assignments (where you want to differ from the default of local assignments) on the assignment statement itself, instead of function-wide. Using a different namespace obviously fails at the former, so it's like using a sledgehammer as a flyswatter. (I suppose you _could_ use global.const instead of const with this change, but there'd never actually be a reason to do so, unless you intentionally shadowed the global with a local and wanted to access both, and that's a silly thing to do and trivial to avoid, even in auto-generated code.)
Which is why I suggested it might be good only for global assignments (and nonlocal assignments), not for all names. Global assignments are much rarer than global lookups and local assignments, and marking them at the point of assignment would make it explicit that you're doing something uncommon. If you keep your functions small enough, it's rarely a serious issue that you have to look upward to notice that the x=5 isn't creating a local variable, but I still think it might be better (again, in a new pythonesque language--I don't seriously want to change Python here) to remove the issue.
On Sat, Jul 11, 2015 at 8:52 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
But that doesn't give me what I want. The whole point is to continue to use the existing default LEGB rules for lookup (which is much more common), but to mark global assignments (where you want to differ from the default of local assignments) on the assignment statement itself, instead of function-wide. Using a different namespace obviously fails at the former, so it's like using a sledgehammer as a flyswatter.
Oh, I see what you mean. My apologies, I thought you wanted adornment on all usage. There had at one point been a proposal to allow "global NAME = EXPR" to mean both "global NAME" and "NAME = EXPR", but I don't know that it ever took off. What you can do, though, is repeat the global declaration on every assignment: def func(x): if not _cached: global _cached; _cached = expensive() _cached[x] += 1 return _cached[x] Given that there'll often be just the one such assignment anyway (as in this example), it won't be a big problem. This is perfectly legal, although it's worth noting that it does trigger a SyntaxWarning (name used prior to global declaration). It's not perfect, but it does allow you to put the word "global" right next to the assignment. ChrisA
On Sat, Jul 11, 2015 at 03:02:23AM -0700, Andrew Barnert via Python-ideas wrote:
Fortunately, Michael has not suggested that. Michael has suggested optional syntax to explicitly declare attributes. He has not suggested to add attributes to the existing implicit lookup order. If "spam" is declared with "self spam", then it must be an attribute. Not a local, nonlocal, global or builtin. If "eggs" is *not* likewise declared, then it *cannot* be an attribute, and the same implicit lookup rules that Python already uses will continue to apply. -- Steve
You are confusing scoping with attribute access. 'self' is not a lexical scope. In a way, if you squint just right, it resembles a dynamic scope (or would under your proposal). But Python isn't elisp, and we don't want to have dynamic scoping. I.e. you'd like bare variables to be (sometimes) scoped to the namespace of the instance eventually created somewhere outside of the class definition (quite likely only created under runtime dependent conditions). In contrast, actual Python is far simpler... all variables are lexically local when defined, unless explicitly declared to have a different and specific *lexical* scope. On Jul 11, 2015 12:58 AM, "Michael Hewitt" <michael@hewitts.us> wrote:
On Sat, Jul 11, 2015 at 08:23:39AM -0700, David Mertz wrote:
I believe you are misunderstanding either dynamic scoping or Michael's proposal. In dynamic scoping, the scope of variables depends on the call chain. So if you write: def spam(): print(x) and then *call* it from function eggs(), spam gets x from the scope of eggs. This is nothing like Michael's proposal.
self is always an instance created outside of the class definition, under runtime dependent conditions. You are describing every instance of every class. You can't create an instance of class Spam *inside the class definition* of Spam, because the class doesn't exist yet: class Spam: x = Spam() # doesn't work
That's not correct. If it were, this would fail with NameError or UnboundLocalError: s = "hello world" def func(): print(s) func() -- Steve
On Sat, Jul 11, 2015 at 10:21 AM, Steven D'Aprano <steve@pearwood.info> wrote:
It's not *exactly* dynamic scope, hence "resembling."
In dynamic scoping, the scope of variables depends on the call chain.
class Foo(): def __init__(self, val): self.val = val if random() < .5: a, b = Foo(1), Foo(2) else: a, b = Foo(2), Foo(1) What's the value of the attribute .val in the namespace 'a' after this code runs? You're right that this is always true of instances, that they are *dynamically* created at runtime. C.f. "resembling". I didn't claim that the proposal changes the scoping *semantics* of Python, per se. But right now, we have this convenient *syntactic* marker that .val is going to live in the namespace whose place is held in the definition by the name 'self'. Under his proposal, readability suffers because we no longer have that marker on the variable itself.
Take a look at what I wrote. 's' is *defined* in the enclosing scope of the function definition (i.e. probably the module scope; although perhaps your code is copied from some other nested scope, which would make 's' nonlocal rather than global). Module scope is also "lexical locality".
Michael Hewitt <michael@hewitts.us> writes:
That's a pity. You can choose a different word if you like.
Another way to say that is that the author must *explicitly communicate*, to the reader, the namespace of each name within the function scope. don't make the mistake of attempting to optimise time spent typing in code, versus time spent comprehending the code as a reader. The latter far outweighs the former, and is the preferred target for optimisation.
With respect, I doubt that the time spent on that is anywhere near the time which would be spent trying to diagnose bugs caused by implicit namespaces. You're aware of the cost in writing explicit names, because you're paying it now. You are, I testify from painful experience in languages other than Python, saving a much greater amount of time in hunting bugs caused by ambiguously-written code.
I share your abhorrence, that would be an unwarranted step. Who is advocating taking that step? No-one in this thread that I can see. If someone advocates “require prefixing of all Python [names] with ‘self.’, ‘global.’, or ‘local.’” within my earshot, I'll join you in criticising the foolishness of such an idea.
You haven't presented anything compelling in support of that. The latter doesn't follow at all from the former.
Python requires explicit declaration of the namespace for names. That protects me from ambiguities that would otherwise be very common in other people's code. I appreciate that and do not want it threatened. -- \ “I distrust those people who know so well what God wants them | `\ to do to their fellows, because it always coincides with their | _o__) own desires.” —Susan Brownell Anthony, 1896 | Ben Finney
On Sat, Jul 11, 2015 at 6:33 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
Not quite true; Python requires explicit declaration of names when they're bound to, but is quite happy to do a scope search (local, nonlocal, global, builtin) for references. But the rules are fairly simple. Aside from the possibility that someone imports your module and sets module.len to shadow a builtin, everything can be worked out lexically by looking for the assignments. ChrisA
On Sat, Jul 11, 2015 at 06:38:34PM +1000, Chris Angelico wrote:
No it doesn't. It only requires an explicit declaration of names when you don't wish to use the default *implicit* rule that any name you bind to is a local. Accessing a local is always implicit. You cannot declare locals at all (apart from function parameters). You just bind to a name, and Python implicitly treats them as local. Accessing nonlocals and globals may be implicit or explicit, depending on whether you use a global or nonlocal declaration. Accessing builtins is implicit, unless you import builtins and write "builtins.len" (say), which we hardly ever do. In Python, most variables (or name bindings, if you prefer) are implicitly scoped. It is rare that they are explicitly scoped as global, and when they are, that's usually a code smell. ("Global variables considered harmful.") The same applies to attribute access: we normally don't explicitly read from a particular scope. That goes against the principle of inheritence. When you look up "self.attr", you don't know whether the attribute returned will come from the instance __dict__, the class, or a superclass, the scope is implied by the history and type of the instance itself. To say nothing of descriptors like property, or methods. That's about as implicit as you can get. A naive reading of the Zen would suggest that, explicit being better than implicit (what, always? under all circumstances?), Python must be a pretty crap language, it has got so many implicit semantics... In contrast, the new rule suggested is *explicit*. You explicitly declare that a name belongs to the scope: self spam, eggs, cheese declares that spam, eggs and cheese are members of self. That's good enough for nonlocals and globals. (By the way, I used to prefix all my global variables with "g", to be explicit that they were global. That stage in my development as a programmer didn't last very long. Fortunately, I was never silly enough to prefix all my locals with "l".) Ben has agreed that it would be harmful to have to explicitly scope each and every name access: if not builtins.len(nonlocals.x + locals.y): raise builtins.ValueError(globals.ERROR_MSG) I trust that everyone agrees with this point. So it seems that explicit is *not* always better than implicit. So why do we behave as if the Zen of Python is some source of ultimate truth? The Zen is not supposed to be a thought-terminating cliche. As Terry Reedy wrote a few years ago: "People sometimes misuse Tim Peter's Zen of Python points. He wrote them to stimulate thought, not serve as a substitute for thought, and certainly not be a pile of mudballs to be used to chase people away." When you read a line of code in isolation: spam = eggs + cheese there is no hint, no clue, as to which of these are globals, nonlocals, locals, or even builtins. And yet we cope with the ambiguity, and I don't hear people claiming that we need to explicitly tag names with their scope, as we do with attributes. So what makes attributes so special that we have to break the rules that apply to all other variables? No tags needed: builtins, globals, nonlocals, locals. Tags needed: attributes. This isn't a rhetorical question, but this post is long enough, and I daresay half my readers have tuned out a few paragraphs ago, so I'll take my answer to the question to a new post. -- Steve
On Sun, Jul 12, 2015 at 1:07 AM, Steven D'Aprano <steve@pearwood.info> wrote:
Sorry, that was sloppily worded. I was making the point that Python does _not_ require declarations when names are referenced, but in the process implied that Python _does_ require them when they're bound to, which as you say is not always the case. But it is still true that Python requires explicit declarations _only_ when names are bound to. In any case, I was arguing against a position which nobody actually held, due to a misunderstanding of a previous post. We're all in agreement that the search path is a Good Thing when referencing names. (Side point: This is true of a lot of other search paths, too. Create explicitly, reference implicitly. The command path on Unix or Windows, the PostgreSQL schema search path, the Python module search directories (sys.path), they're all looked up by unqualified name; but when you create something, you usually have to say exactly where it gets put. Sometimes there's a default (Postgres lets you implicitly put things into the first location on the search path, which is what you most commonly want anyway), sometimes not even that (creating a file without a path name will put it in the current directory, which on Unix is not in $PATH).) ChrisA
On Sun, Jul 12, 2015 at 01:07:56AM +1000, Steven D'Aprano wrote:
The short answer is, sometimes they are special, and sometimes they aren't. Implicit self is a much-requested feature, and not just in Python. Eiffel, for example, uses the "Current" keyword, and it is sometimes optional. Swift has implicit member access as well: var x = MyEnumeration.SomeValue x = .AnotherValue https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift... And yet C++ which has implicit "this", people regularly end up prfixing their attributes with a pseudo namespace, "m_..." (for member). I have come to the conclusion that this is not just personal preference. I now believe that where you stand on this question will, to some degree, depend on the type of code you are writing. If you are writing "enterprisey" heavily object oriented code, chances are you are dealing with lots of state, lots of methods, lots of classes, and you'll need all the help you can get to keep track of where that state lives. You will probably want explicit self for every attribute access, or a pseudo-self naming convention like m_ in C++, to help keep it straight in your head. *Understanding the code* is harder than writing it in the first place, so having to write a few extra selfs is a negligible cost with a big benefit. Attributes are special because they are state, and you have lots of state. But look at Michael's example code. That's real code too, it's just not enterprisey, and there are many Python programmers who don't write enterprisey code. They're beginners, or sys admins hacking together a short script, or editing one that already exists. For them, or at least for some of them, they have only a few classes with a little bit of state. Their methods tend to be short. Although they don't have much state, they refer to it over and over again. For these people, I believe, all those explicit selfs do is add visual noise to the code, especially if the code is the least bit mathematical or if there are well-known conventions that are being followed: class Vector: def abs(self): return sqrt(x**2 + y**2 + z**2) # versus return sqrt(self.x**2 + self.y**2 + self.z**2) We're told that programs are written firstly for the human readers, and only incidentally for the computer. I expect that most people, with any knowledge of vectors, would have understood that the x, y, z in the first return must refer to coordinates of the vector. What else could they be? The selfs are just noise. If we are writing for human readers, sometimes we can be too explicit. Or to put it another way: If we are writing text for human readers who will read that text written by us, sometimes we can be too explicit in our writing for those same readers, causing a decrease in readability, which is an undesirable outcome. I don't intend to defend "Do What I Mean" attribute inference. I don't believe that is practical or desirable in Python. But there's a middle ground: Michael's suggestion, where we can explicitly declare that certain names are attributes of self, and thereby decrease the visual noise in that method. If you're thinking about enterprisy 50- or 100-line methods, this solution probably sounds awful. Every time you see a variable name in the method, you have to scroll back to the top of the method to see whether it is declared as a self attribute or not. And there are too many potential attributes to keep track of them all in your head. And I agree. But that sort of code is not the code that would benefit from this. Instead, think of small methods, say, ten or fifteen lines at most, few enough that you can keep the whole method in view at once. Think of classes with only a few attributes, but where you refer to them repeatedly. Maybe *you* don't feel the need to remove those in-your-face selfs, but can you understand why some people do? In recent years, Python has gained some nice new features and batteries aimed at the advanced programmer, such as async etc. This, I believe, is one which may assist programmers at the less advanced end. They have no need for awaitables and static type checking, but they sure would like less visual noise in the methods. -- Steve
On Jul 11 2015, Steven D'Aprano <steve-iDnA/YwAAsAk+I/owrrOrA@public.gmane.org> wrote:
Thanks for that excellent post. I hope it'll cause some people to reconsider. Although there seems to be a flood of objection mails, most of them seem more instintive than rational to me. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
On Sat, Jul 11, 2015 at 12:10 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
This is a great example of why the proposal is a bad one. Yes, not using magic makes a one-line function slightly longer (and even slightly less readable). But I also don't want to have to guess about WHICH 'x' or 'y' or 'z' is the one being used in calculation of Cartesian distance. Sure, an obvious implementation of a Vector class probably has x, y, z attributes of self. The example was rigged to make that seem obvious. But even then, I don't really know. Maybe the z direction of the vector is stored as a class attribute. Maybe the class expects to find a global definition of the z direction. Sure, keeping the z direction somewhere other than in self is probably foolish if you assume "Vector" means "generic vector". What if the class was called "RestrictedVector"? Would you know without reading the full class and docstring exactly in what respect it is "restricted"? E.g. are you sure it's not "restricted in the z dimension"? As someone else points out, if you WANT local variables in a method, you are welcome to use them. E.g.: def times_matrix(self, matrix): x, y, z = self.x, self.y, self.z # Many more than one line of implementation # ... stuff with matrix indexing and referencing x # etc. return result_matrix No one stops you now from giving local names to values stored in the instance within a method body. But when you do so, you KNOW 30 lines later that they are local names, even after the "local-looking name is actually an attribute" declaration has scrolled away. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
On Sat, Jul 11, 2015 at 12:18 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Actually I was taught to use "this" everywhere if I can. But look at Michael's example code. That's real code too, it's just not
I disagree that we really need to distinguish what consituttes enterprisey code. In fact it is a bad idea to think there is even such notion because people should express code in the cleanest and most intuitive way possible. Even a beginner can and should benefit from explicitness. I am sure everyone here have read enterprisey code and know that enterprisey code is not really enterprisey code. Complexity is a different discussion, and does not justify why someone would want to be less explicit or more explicit. That's same argument why can't we have make init a reserved class method, why have __init__? I can come up with a bunch of other arguments why Python language should do Y instead of X to make code less visually noisy. We cannot appeal to everyone's need if the visual noise is such a no deal in performance and in learning a language. Sure people can write "self" like this: def regular_function(elf, self): # self is just some Python object... elf.name = 'foo' self.name = 'bar' But this is still clear to beginner that hey this is just a regular function, self in this case is some kind of object.... Anyway, when I was a student, scoping was a very popular question among my peers when they first learn a new language. On Sat, Jul 11, 2015 at 12:04 PM, Michael Hewitt <michael@hewitts.us> wrote:
I still -1 on the dot prefix. We might as well adopt $ in that case. "dot" is a poor choice. It is one of the most easily missed character to type. And again I don't see the benefit of having self. and $ co-exist. We should choose one way, but obviously this cannot be the case because we need backward compatibility. On Sat, Jul 11, 2015 at 3:41 PM, David Mertz <mertz@gnosis.cx> wrote:
John Wong writes:
I don't think "unintuitive" is what is meant by "enterprisey code". I suspect that what is meant is large objects that have slews of attributes that need to be initialized, with a large variety of conventions for constructing defaults. If your code needs to consist mostly of long sequences of attribute assignments followed by returning the result of a method call, I see nothing wrong with writing it as a long sequence of assignments followed by a method call.
On 12 July 2015 at 05:41, David Mertz <mertz@gnosis.cx> wrote:
Perhaps that's an answer that could be pushed more heavily? Q: My method is drowning in self references, how can I make it more readable? A: Bind referenced attributes to local names at the beginning of the method, and write them back to instance attributes at the end of the method. For example, rather than writing: class ObjectInMotion: def keep_moving_gravity(self): self.y += self.gravity self.y = max(self.y, 0) self.y = min(self.y, height - 1) We can write: class ObjectInMotion: def keep_moving_gravity(self): y = self.y + self.gravity y = max(y, 0) y = min(y, height - 1) self.y = y This approach is then conveniently amenable to factoring out helper functions that are independent of the original class definition: def calculate_next_location(current, gravity, height): next_location = current + gravity next_location = max(next_location, 0) next_location = min(next_location, height - 1) return next_location class ObjectInMotion: def keep_moving_gravity(self): self.y = calculate_next_location(self.y, self.gravity, height) I like this angle, as it encourages thinking about mutating operations on instances as a "read, transform, write" cycle, rather than multiple in-place mutations (although the latter may of course still happen when the attributes being manipulated are themselves mutable objects). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12 July 2015 at 01:04, Nick Coghlan <ncoghlan@gmail.com> wrote:
<snip>
I prefer this particular style. Following object-oriented code means keeping track of state. In any non-trivial method this approach makes it easier to see what state serves as additional input to the method and what state is changed as output of the method. This is part of the implicit "signature" of a method on top of its input arguments and return values so it's good to separate it out from any internal calculations. Also modifying state in place is inappropriate for objects being used in a "physics" situation as the motivating examples does: def keep_moving_gravity(self): self.y += self.gravity self.y = max(self.y, 0) self.y = min(self.y, height - 1) The problem is that this method simultaneously calculates the new position and overwrites the old one (in a non-invertible way). In a program where there is only one variable that might be fine. However if we need to detect collisions with other objects then this won't work. Also if the velocity/acceleration of this object depends on e.g. the position of some other object then we end up with order-dependent physics: if I update ball1 first and then ball2 I get different results than I would if I call the update methods in the reverse order. Similarly if you write something like this: def update(self, dt): self.vy += self.gravity * dt self.y += self.vy * dt Then the result depends on the order of the two lines of code in the method. It should really be something like: def update(self, dt): # read y, vy = self.y, self.vy # calculate new values from old new_vy = vy + self.gravity * dt new_y = y + vy * dt # Using vy not new_vy on RHS # update state atomically self.y, self.vy = new_y, new_vy A better general approach is that each object reports what velocity it thinks it should have: def get_velocity(self, system_state): return (0, self.gravity) # Assuming 2D Then a controller can pass the current state of the system to each object and ask what velocity it has and then update all objects simultaneously checking for and resolving collisions etc. as it does so. Building the update logic into every class means that every class needs to be changed in order to redesign anything in the main physics loop (to add collision detection, variable timestep etc). -- Oscar
On 7/11/2015 3:41 PM, David Mertz wrote:
or def abs(v): return sqrt(v.x**2 + v.y**2 + v.z**2)
Localization, which is not limited to self attributes, does two things: it removes the need to continually type 'object.x'; it makes the remaining code run faster. I would be interested to know how many faster local references are needed to make up for the overhead of localization. -- Terry Jan Reedy
Terry Reedy wrote:
If you access the attribute just twice, that's enough for localisation to yield a speedup. Local variable access is just that much faster than attribute lookup. $ python3 -V Python 3.4.3Terry Reedy wrote:
If you access the attribute just twice, that's enough for localisation to yield a speedup. Local variable access is just that much faster than attribute lookup. $ python3 -V Python 3.4.3 $ python3 -m timeit -s "class C: pass" -s "c = C();c.x=1" "c.x;c.x" 10000000 loops, best of 3: 0.106 usec per loop $ python3 -m timeit -s "class C: pass" -s "c = C();c.x=1" "x=c.x;x;x" 10000000 loops, best of 3: 0.0702 usec per loop $ python -V Python 2.7.3 $ python -m timeit -s "class C(object): pass" -s "c = C();c.x=1" "c.x;c.x" 10000000 loops, best of 3: 0.105 usec per loop $ python -m timeit -s "class C(object): pass" -s "c = C();c.x=1" "x=c.x;x;x" 10000000 loops, best of 3: 0.082 usec per loop regards, Anders
My stance on this: that's the responsibility of the Python interpreter not the one of the Python programmer. Reminds me of the string concatenation issue of older Python versions: - https://wiki.python.org/moin/PythonSpeed/PerformanceTips#String_Concatenatio... - https://wiki.python.org/moin/PythonSpeed/PerformanceTips#Avoiding_dots... On 12.07.2015 17:11, Anders J. Munch wrote:
On 24 Jul 2015, at 16:22, Sven R. Kunze <srkunze@mail.de> wrote:
My stance on this: that's the responsibility of the Python interpreter not the one of the Python programmer.
It’s just one of the tricks you can micro-optimise code when needed. The important bit is *when needed*, this trick (and simular ones) should IMHO only be used when benchmarking shows that you have a problem that is solved by it and not proactively because these tricks tend to make code less readable. Ronald
On Jul 11 2015, David Mertz <mertz-vlcHsuTvavqeZLLa646FqQ@public.gmane.org> wrote:
So how do you know if z is a class or an instance attribute if you write "self.z" instead of "z"?
Maybe the class expects to find a global definition of the z direction.
With the proposal, the above would actually read def abs(self): self x, y, z return sqrt(x**2 + y**2 + z**2) so it is obvious that z is not a global but an attribute of self.
As Steven has so nicely written in the mail that I responded to: ,---- | If you are writing "enterprisey" heavily object oriented code, chances | are you are dealing with lots of state, lots of methods, lots of | classes, and you'll need all the help you can get to keep track of where | that state lives. You will probably want explicit self for every | attribute access, or a pseudo-self naming convention like m_ in C++, to | help keep it straight in your head. *Understanding the code* is harder | than writing it in the first place, so having to write a few extra | selfs is a negligible cost with a big benefit. Attributes are special | because they are state, and you have lots of state. | | But look at Michael's example code. That's real code too, it's just not | enterprisey, and there are many Python programmers who don't write | enterprisey code. They're beginners, or sys admins hacking together a | short script, or editing one that already exists. For them, or at least | for some of them, they have only a few classes with a little bit of | state. Their methods tend to be short. Although they don't have much | state, they refer to it over and over again. | [...] | If you're thinking about enterprisy 50- or 100-line methods, this | solution probably sounds awful. Every time you see a variable name in | the method, you have to scroll back to the top of the method to see | whether it is declared as a self attribute or not. And there are too | many potential attributes to keep track of them all in your head. | | And I agree. But that sort of code is not the code that would benefit | from this. Instead, think of small methods, say, ten or fifteen lines at | most, few enough that you can keep the whole method in view at once. | Think of classes with only a few attributes, but where you refer to them | repeatedly. Maybe *you* don't feel the need to remove those in-your-face | selfs, but can you understand why some people do? `---- Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Sure, and this exists right now as an option: def abs(self): x, y, z = self.x, self.y, self.z return sqrt(x**2 + y**2 + z**2) The small number of characters saved on one first line isn't worth the extra conceptual complexity of learning and reading the next construct.
I don't buy it. I don't want a language construct that is meant to self-destruct as soon as people's methods grow past 30 lines (yes, I know it wouldn't literally do so, but there is a pretty small threshold beyond which it turns from making "code golf" easier to actively harming readability).
On 07/11/2015 04:38 AM, Chris Angelico wrote:
I think some don't realise the names in a class block are not part of the static scope of the methods defined in that same class block. The methods get the static scope the class is defined in, but that excludes the names in the class block. If a class inherits methods defined in another module, those methods get the static scope where they were defined, and the methods local to the child class get a completely different static scope. But usually it's not a problem, thanks to "self". ;-) Cheers, Ron
On 11 July 2015 at 18:33, Ben Finney <ben+python@benfinney.id.au> wrote:
That's not the way I read Michael's proposal. I read his proposal as aiming to cut down on visual *noise* when *reading*. It's worthwhile to compare the different examples in terms of "characters conveying useful information": def keep_moving_gravity(self): self.y += self.gravity self.y = max(self.y, 0) self.y = min(self.y, height - 1) Here, self is repeated 7 times: 28 characters. Discounting indentation and line breaks, the whole function is only 96 characters long, so almost a third of the function definition consists of the word "self". With Michael's proposal, that changes to: def keep_moving_gravity(self): self y, gravity y += gravity y = max(y, 0) y = min(y, height - 1) Total character length is now 79 characters, with 15 characters devoted to the "self y, gravity" declarative element. That's a worthy reduction in visual scoping noise (to less than 20%), but it's come at the cost of losing actual signal: there's no longer a local marker on the references to "y" and "gravity" to say they're instance variables rather than local variables. That's also still worse than the best current code can already do (without breaking the "self" convention) which is to assign a frequently accessed object to a single character variable name: def keep_moving_gravity(self): s = self s.y += s.gravity s.y = max(s.y, 0) s.y = min(s.y, height - 1) That keeps all of the relevant attribute lookup signal, and is only 14 characters of scoping noise (8 for the "s = self", 6 for the single character object references) out of 86 total characters. Finally, an "implied reference to first parameter" for attribute lookups inside functions offers the most minimalist proposal I can think of that would still be easy to read from a semantic perspective: def keep_moving_gravity(self): .y += .gravity .y = max(.y, 0) .y = min(.y, height - 1) We've reduced the function length to only 72 characters, and it's 100% signal. The only thing we've lost relative to the original is the 6 explicit references to "self", which are now implied by looking up an attribute without specifying a source object. If we *did* do something like that last example (which I'm not convinced is a good idea, given that the "n = name" trick works for *any* frequently referenced variable, whether inside a function or not), we'd need to think seriously about the implications for implicit scopes, like those created for generator expressions and container comprehensions. At the moment, their first argument is the outermost iterable, which would become accessible within the expression body if there was a syntax permitting implied references for attribute lookups. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Nick Coghlan <ncoghlan@gmail.com> writes:
I read [Michael Hewitt's] proposal as aiming to cut down on visual *noise* when *reading*.
Okay. In response to that, then: Michael appears to want most of those references to entirely omit the explicit namespace. The desire to entirely remove explicit namespaces to distinguish names in a function, I don't sympatise with. Those explicit namespaces make the code much more readable. I don't know what Michael means by “clean”; if it is a simple “fewer characters”, that's not strongly correlated with easier-to-read code. Especially because readable code *also* requires clarity and rapid comprehension – including disambiguation – of the writer's intent. For those purposes, many times the better solution involves writing significantly *more* characters than the strict minimum. So arguments merely leaning on “fewer characters” don't impress me, and I hope they don't impress many others. As for simply choosing a shorter name:
It's worthwhile to compare the different examples in terms of "characters conveying useful information":
Given that “self”, while merely a convention, is now such a strong convention that it is hard-coded into many tools, I argue that “self” conveys much *more* information than a different shorter name (such as “s”). The latter will tend to require rather more effort to comprehend the writer's intent, and to that extent is less readable. -- \ “The right to use [strong cryptography] is the right to speak | `\ Navajo.” —Eben Moglen | _o__) | Ben Finney
On 07/11/2015 05:12 AM, Nick Coghlan wrote:
This works now... def keep_moving_gravity(self): y = self.y + self.gravity y = max(y, 0) self.y = min(y, height - 1) I don't think the self comes up as frequently as it may seem in well written code. And in the above, self is written once, but the other names y and gravity are repeated again. So the gain isn't as great as it may seem at first. What would this do? def __init__(self, red, blue, green): self red, blue green red = red blue = blue green = green If the names are long, it would take more characters than the equivalent version using self. Cheers, Ron
On 11 July 2015 at 17:25, Michael Hewitt <michael@hewitts.us> wrote:
Alternative proposal: def keep_moving_gravity(self): .y += .gravity .y = max(.y, 0) .y = min(.y, height - 1) The main objection folks have to the declarative proposal is the fact that there's nothing obvious at the point of reference to indicate whether we're manipulating a local variable or an instance variable. I can speak from experience in saying that there's a reason the "m_*" prefix notation for C++ member variables is popular: it makes C++ method implementations much easier to read when you can tell at a glance if a line is working with an instance member or a local variable. With the language not providing that separation by default, folks added it by convention. An "implied attribute reference" proposal would be different: it could build on the same mechanism that powers zero-argument super to make it possible to say "if I reference an object attribute in a function without saying which object I'm referring to, then I mean the first parameter". This should work cleanly for standalone functions, class methods, instance methods, etc, as the compiler already keeps track of the necessary details in order to implement PEP 3135 (https://www.python.org/dev/peps/pep-3135/#specification) The main downside is that a leading dot isn't as good a visual indicator as a dot appearing between two other characters. That could potentially be alleviated with a double-dot notation: def keep_moving_gravity(self): ..y += ..gravity ..y = max(..y, 0) ..y = min(..y, height - 1) The downside of *that* is it might make people start thinking in terms stepping up scopes, rather than referring to the first parameter. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jul 11, 2015 1:40 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
Assuming the parser could be made to handle this (which feels like a big stipulation), this variation would deal with the non-explicit dynamic scoping bug magnets. It might violate the "looks like grit on Tim's screen" principle, but it is explicit. I'd only be -0 or -0.5 on this idea. Since we have Unicode though, how about: •y += •gravity Or ∆y += ∆gravity Guaranteed no parser ambiguity, and some symbols are bigger than grit. In fact, maybe we could get the Unicode Consortium to add a glyph that looked like 'self.' To make it stand out even better.
I am officially dropping my original proposal in favor of Nick's. Using a single '.' prefix to reference class variables is brilliant. It has the added benefit of scoping auto-completion within IDEs, which is incredibly helpful for beginners and veterans alike. As an aside, I have learned that long functions are bad form (reference Robert Martin's Clean Code series - #3 Functions). Using short functions with descriptive names has revolutionized code readability at my company. Incidentally, it also mitigates concerns about distinguishing locals from class variables. Additionally, I would caution against allowing a lesser used language feature (decorators) to drive the design of a more common feature (field references in methods). I want to thank you folks for helping to shape one of the most beautiful languages I have encountered. I apologize for the hit-and-run, but I can see that being a part of this discussion is not good for my health, causing me to send emails at 1AM and stew about the issue all night, so I will need to withdraw. My primary reason for exploring Python was as a 'first language' for my son and also as a potential option for future introductory programming courses that I might teach. Except for 'self' redundancy, it is a nearly ideal first language. Hopefully my feedback has been useful. Michael On Sat, Jul 11, 2015 at 1:40 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 11/07/2015 08:25, Michael Hewitt wrote:
Yes, as I already have.
Wrong, as Ben Finney has already pointed out. You'll also have to wade up and down any large methods to ensure that you distinguish local variables from instance variables. Frankly I see nothing in this proposal at all, so I'm moving from -1 to the -1000 somebody else gave it in the early hours of the mornig, I'm sorry but I forget who that was. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On Fri, Jul 10, 2015 at 6:31 PM, Michael Hewitt <michael@hewitts.us> wrote:
I will give it a month after something like this goes into the language for style guides to appear that will recommend prefixing all member variables with a triple underscore to distinguish them from the locals.
Hello, On Fri, 10 Jul 2015 15:31:28 -0700 Michael Hewitt <michael@hewitts.us> wrote:
Even the language which is bag of warts - JavaScript - has essentially banned usage of its "with" statement: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements... . And the reason for this is (as the red box on that page says) that it interferes with readability, maintainability, and performance. And yet you propose to add essentially the same to Python. If you have troubles explaining why "self" is needed to kids, I'd suggest going along the lines of why there's capital letter at the start of sentence, full stop at the end, and wh hmn lnggs hv vwls, vn thgh ts pssbl t rd wtht thm.
-- Best regards, Paul mailto:pmiscml@gmail.com
On Sat, Jul 11, 2015 at 10:06 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
Hebrew and Arabic manage without vowels. English manages (almost) without diacriticals. Hungarian (I think) manages without verb tenses. Chinese and Japanese can manage without punctuation, although these days they usually use it. And Python manages without declared variables, which is why 'self.x = self.y' is completely different from C++ and family. But that also means that it's different from the JavaScript 'with' block, because the "self x, y" declaration is explicit about exactly which names are scoped that way. This wouldn't have that problem. However, I'm not sure it would be all that useful. Also, the current definition means that the first parameter magically becomes a keyword during the parsing of that function, which is extremely odd. I'm not seeing huge value in this, given that the declaration means yet another place to repeat all your attribute names; the only way I could imagine this being smoother is if you could make your declaration at class scope, and then it applies to _all_ the functions defined in it - but that wouldn't solve the problems either. ChrisA
On 07/10/2015 03:31 PM, Michael Hewitt wrote:
This suggestion is fully backward compatible with existing Python code, but would eliminate the need to pollute future Python methods with copious 'self.' prefixes, thereby improving both readability and maintainabilty.
I disagree. Having a method with nothing but plain variables, plus a "scoping" line towards the top, will cause more work in keeping track of which are instance variables and which are local variables. Besides that, what happens when you create a function outside a class, and then add it to a class? class Blah: pass def a_func(self, a, b): self c, d ... Will that work? - Yes seems silly in the case of non-method functions - No seems artificially restrictive -- ~Ethan~
On Fri, Jul 10, 2015 at 03:31:28PM -0700, Michael Hewitt wrote:
At first, I was all "not another poorly thought out implicit self proposal!", but then I read it and thought, "you know, of all the implicit self proposals I've read, this is the first one that I might be able to get behind". It's clever. Possibly too clever. You cleverly avoid needing to introduce a new keyword to the language by using the name of the first parameter as the pseudo-keyword. I like that, but I think it may be a little to radical for the conservatives in the Python community. We tend to suffer from a sort of anti-"not invented here" syndrome: unless something has been tried and tested in at least one other language, and preferably a dozen, we don't want to know about it. It would help your case if you can show a language that already has this feature. Personally, I don't think of "self" as pollution at all. It's nice and explicit and helps readability. But if people wanted to avoid using it, and I can think of the odd case here and there where I might want to do so, I think an explicit declaration is a decent way to go.
You say "same as", I presume that this is a compile-time transformation that you write "x = 5" and the compiler treats it as "self.x = 5". So it doesn't matter whether x is a property or other descriptor, it will resolve the same as it currently does. I can see one (horrible) corner case: suppose you have code like this: def spam(self): self self self = self My guess is that this ought to be banned, as it's not clear when self refers to the self local variable and when it refers to the implicit self.self. It might also help your case to convince people that implicit attribute references are not as bad as they might seem. Can you give a brief survey of languages with implicit attribute references, and how they deal with the ambiguity of "attribute or variable"? -- Steve
Steven D'Aprano <steve@pearwood.info> writes:
Personally, I don't think of "self" as pollution at all. It's nice and explicit and helps readability.
+1. All the complaints that I see about “pollution” or “extra work” or etc., seem IME to be accompanied by a dislike of Python's “explicit is better than implicit” principle. Since I think that principle is essential to Python's readability and maintainability, I think that removing explicit ‘self’ would tangibly *harm* readability and maintainability of Python code. -- \ “I bet one legend that keeps recurring throughout history, in | `\ every culture, is the story of Popeye.” —Jack Handey | _o__) | Ben Finney
-1000 This looks like an absolutely terrible anti-feature. It makes all code less readable, and violates the principle of locality (albeit, `global` and `nonlocal` can also be declared relatively far away from the use of those scoped variables too). On Fri, Jul 10, 2015 at 3:31 PM, Michael Hewitt <michael@hewitts.us> wrote:
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
-1e200. I have to deal with implicit 'this' enough in C++ at the risk of writing "bad style" or something like that. It has bitten before. Until I started following C++ style guides, I always put 'this->' in front of every variable but still had to deal with the accidental member reference when you meant something else. I also like the fact that Python lets you name constructor arguments the same way as members, e.g.: class X: def __init__(self, x, y): self.x = x self.y = y You can do the same in C++, but compilers with -Wall will complain unless you do this: class X { public: X(int x_, int y_): x{x_}, y{y_} {} ... } which is just ugly. On July 10, 2015 5:31:28 PM CDT, Michael Hewitt <michael@hewitts.us> wrote:
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi. Steven D'Aprano <steve@pearwood.info> writes:
Personally, I don't think of "self" as pollution at all. It's nice and explicit and helps readability.
+ 1 as well I am definitely in the conservative camp (I don't know who else but I am). Let's stick to Zen of Python. * I see no real use case why I would write self x,y instead of self.x = 1, self.y = 2. This reminds me of Javascript var x,y. * While this is not exactly like Javascript's "this", I can see the resemblance, and no thanks. * This change will be confusing to everyone reading Python code. We have to stick to real readability, not some rare . We should not introduce this kind of change to say "we can do X in two ways, and most people will write in the old convention ANYWAY but be hold there is a second geeky way to do the same thing." Let's reserve the idea that self x where now x is scoped to self .... reserve this idea to just nonlocal and global - I personally haven't found a use case for nonlocal and global in my own work but that's just my opinion. Thanks. John On Fri, Jul 10, 2015 at 10:42 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
On 11.07.2015 00:31, Michael Hewitt wrote:
-1 on this. How would I know that x is "bound" to self later on in the method without scanning the whole method body for a possible reference to self.x ? As Python programmer, you default to assume that x = 5 refers to a local variable assignment (globals aren't used much, and when they are, the global definition is usually written as first statement in a function/method). If we'd have something like: with self: x = 5 y = 6 as in Pascal, this would be explicit and it's also clear that there's special scoping going on in the body of the with statement block. I still wouldn't like this much, but at least it follows explicit is better than implicit. Overall, I don't believe much in keystroke optimizations - editors provide all the help you need these days to avoid typing too much, while still allowing you to use descriptive identifiers throughout your program. And that results in much better readability than any scoping tricks ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source
::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Sat, Jul 11, 2015 at 02:53:51PM +0300, Joonas Liik wrote:
It's actually taken from Pascal, where it works quite well due to the necessity of explicit declarations of all variables and record fields. There's even a Python FAQ about it. So don't worry, Python won't get this construct. -- Steve
M.-A. Lemburg wrote:
the global definition is usually written as first statement in a function/method).
The same thing applies to the proposed declaration. However, globals are usually given longish and descriptive names, making it easy to spot them and know what they refer to. Both locals and instance attributes, on the other hand, often have very short and cryptic names, so having them both appear with no prefix would be very confusing. -- Greg
On Fri, Jul 10, 2015 at 07:28:14PM -0400, Joseph Jevnik wrote:
How does this interact with descriptors, are they looked up everytime x and y are referenced or are they cached at the `this x, y` statement?
My understanding is that the actual execution of Python code does not change. Today, if you write: def method(self): self.spam = self.eggs + 1 it compiles to something like this (in Python 2.7, different versions may use different bytecode): 2 0 LOAD_FAST 0 (self) 3 LOAD_ATTR 0 (eggs) 6 LOAD_CONST 1 (1) 9 BINARY_ADD 10 LOAD_FAST 0 (self) 13 STORE_ATTR 1 (spam) 16 LOAD_CONST 0 (None) 19 RETURN_VALUE There's no caching of attribute look-ups, if spam or eggs are descriptors (methods, properties, etc.) the descriptor protocol gets called each time LOAD_ATTR or STORE_ATTR is called. If you re-write that to: def method(self): self spam, eggs spam = eggs + 1 it should compile to *exactly the same byte code*. It's just a compiler directive, telling the compiler to treat any "spam" and "eggs" tokens as if they were actually "self.spam" and "self.eggs". That would, of course, mean that it's impossible to have a local variable with the same name as the declared attribute. I often write micro-optimized code like this: spam = self.spam = {} for x in big_loop: # avoid the repeated look-ups of ".spam" spam[x] = something If I declared "self spam", this wouldn't work (or rather, it would work, but it wouldn't have the effect I am looking for). The solution is simple: don't declare "self spam" in this case. -- Steve
On 10/07/2015 23:31, Michael Hewitt wrote:
I disagree completely. When I see:- self.x = 1 I currently know exactly what I'm looking at. All I see with this proposal is more work for my MKI eyeballs, which are already knackered, and more work for the people who maintain our static analysis tools, as you can still forget to properly scope your variables. So -1.
-- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
Let's compare two versions of a method taken from some code that my 11 year old son wrote yesterday: *Current* global height def keep_moving_gravity(self): self.y += self.gravity self.y = max(self.y, 0) self.y = min(self.y, height - 1) *Proposed* global height def keep_moving_gravity(self): self y, gravity y += gravity y = max(y, 0) y = min(y, height - 1) Is anyone actually going to argue that the first version is cleaner and more readable than the second? All I see when I read the first is 'self', 'self', 'self' -- my son's exact words to me last night. As far as maintainability, the author of the first version must repeatedly make the same decisions over and over regarding how to scope each variable reference as he/she types 'y', 'gravity', and 'height'. The author of the second code makes these decisions exactly once at the top of the method and then is free to refer to each variable naturally without the mental overhead of prefixing each 'y' and 'gravity' with 'self.', but God forbid - not 'height'. I can tell you that the mental overhead of this is taxing my son & is the cause of many painful mistakes -- just forgetting a single 'self.' prefix on one of the above field references can waste a significant amount of time. As far as static analysis tools, this should honestly not be a lot of extra work, since the tools must already handle 'global' in a very similar fashion. If the 'self.' prefix really does make code clearer, then we should do away with the 'global' scope declaration as well as automatic local scoping and require prefixing of all Python variables with 'self.', 'global.' or 'local.'. My mind becomes numb thinking about writing such code. To me, the existence of the keyword 'global' for automatically scoping subsequent variable references is a strong argument that a similar 'self' scoping mechanism is called for as well. And, for folks who still prefer to prefix all their field references with 'self.', the proposal in no way prevents them from doing so. It merely allows the rest of us to be a bit less wordy and more pithy in our code. Mike On Friday, July 10, 2015, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On Sat, Jul 11, 2015 at 5:25 PM, Michael Hewitt <michael@hewitts.us> wrote:
Alternate proposal: # You could in-line this if you want to. def limit(low, n, high): """Limit a number to be within certain bounds""" return min(low, max(n, high)) def keep_moving_gravity(self): self.y = limit(0, self.y + self.gravity, height - 1) There are precisely two references to self.y (one reading, one writing), and one reference to self.gravity. The global identifier height needs no declaration, because it's not being assigned to. Instead of doing three operations (increment, then check against zero, then check against height), it simply does one: a bounded increment by gravity. Bad code is not itself an argument for a language change. Sometimes there's an even better alternative :) ChrisA
Chris Angelico writes:
That was my first reaction.
Bad code is not itself an argument for a language change. Sometimes there's an even better alternative :)
If you're a language wonk, it's obviously better, true (well, I'm a wannabe wonk so I say that and cross my fingers for luck :-). But if you're a very new and possibly very young programmer (both meaning you have little experience abstracting in this way) who's basically scripting your way through the problem, defining an "internal" function to be used once looks like throwing the garbage in the garage through a window onto the lawn. I think this is going to be be one of those features that "scripters"[1] and "programmers" evaluate very differently. Personally, I'm -1 but that says more about my proclivities than about the proposal. :-) Steve Footnotes: [1] Sorry if that sounds pejorative. It's not intended to. I tried to find a better term but failed.
Let me state my argument more succinctly. If 'self.' is a good thing, then *all* Python variable references should always be explicitly prefixed by their scope -- 'global.', 'local.', and 'self.'. Why does it make more sense to not require explicit scoping of global variables, which are far more dangerous, while requiring explicit class scoping when nothing is more natural than for a method to refer to variables within its own class? This is totally backwards. If anything, the opposite should be true. 'global.' should be required for *all* global references, of which there should be very few in well-written, modular code, and 'self.' should not be required for class references because of course methods are going to naturally refer to variables within their class. Keep in mind that the proposed design explicitly specifies the class variable scoping at the top of each method, so that anyone reading the method can simply look at the top of the method to find out which variables are class variables. On Sat, Jul 11, 2015 at 12:25 AM, Michael Hewitt <michael@hewitts.us> wrote:
On Sat, Jul 11, 2015 at 5:49 PM, Michael Hewitt <michael@hewitts.us> wrote:
How many times do you call on standard library functions? Those are almost always global references. Either you're looking for something directly from the builtins (eg len, max, range), or you import a module at the top of your file and then use that (eg math.sin, logging.info), in which case the module reference is itself a global of your own module. So, no. Globals are extremely common - just not often reassigned. ChrisA
On Jul 11, 2015, at 00:49, Michael Hewitt <michael@hewitts.us> wrote:
Let me state my argument more succinctly. If 'self.' is a good thing, then *all* Python variable references should always be explicitly prefixed by their scope -- 'global.', 'local.', and 'self.'.
If I were designing a new pythonesque language, I think I might well add something like that for when you need to disambiguate from the default, and then get rid of the global statement. In fact, if it weren't for the obvious huge backward compat problems, I might even go for a suggestion to do that in Python. Even for closure variables, I kind of like the look of "nonlocal.x = 3", although it's not _as_ compelling as "global.x = 3" to me. But the idea that self is a more important default than local, and we should therefore have SLEGB instead of LEGB for unqualified lookups, and self for unqualified assignments instead of local? Definitely not. Creating new locals is something I do in half my functions and methods; creating new attributes is something I rarely do outside of __init__ methods. I've used plenty of languages that don't require declarations, and I've never found one whose default rules made me as happy as Python's LEGB/L. It sort of works in languages where classes have a predefined set of attributes, but even there I don't like it as much; I always end up naming one set or the other with an underscore prefix or suffix or some other marker which is just "self." in a disguise that fools my tools.
On Sat, Jul 11, 2015 at 8:02 PM, Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
Want it in Python? No problem. You can't have "global.x" because it's a keyword, but... globl = SimpleNamespace() def use_globals(): globl.x += 1 return globl.y If you want it, it's there, but I wouldn't bother with it for constants - including functions, which are globals just the same as any other. We do NOT need this kind of enforced adornment for all names. ChrisA
On Jul 11, 2015, at 03:13, Chris Angelico <rosuav@gmail.com> wrote:
But that doesn't give me what I want. The whole point is to continue to use the existing default LEGB rules for lookup (which is much more common), but to mark global assignments (where you want to differ from the default of local assignments) on the assignment statement itself, instead of function-wide. Using a different namespace obviously fails at the former, so it's like using a sledgehammer as a flyswatter. (I suppose you _could_ use global.const instead of const with this change, but there'd never actually be a reason to do so, unless you intentionally shadowed the global with a local and wanted to access both, and that's a silly thing to do and trivial to avoid, even in auto-generated code.)
Which is why I suggested it might be good only for global assignments (and nonlocal assignments), not for all names. Global assignments are much rarer than global lookups and local assignments, and marking them at the point of assignment would make it explicit that you're doing something uncommon. If you keep your functions small enough, it's rarely a serious issue that you have to look upward to notice that the x=5 isn't creating a local variable, but I still think it might be better (again, in a new pythonesque language--I don't seriously want to change Python here) to remove the issue.
On Sat, Jul 11, 2015 at 8:52 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
But that doesn't give me what I want. The whole point is to continue to use the existing default LEGB rules for lookup (which is much more common), but to mark global assignments (where you want to differ from the default of local assignments) on the assignment statement itself, instead of function-wide. Using a different namespace obviously fails at the former, so it's like using a sledgehammer as a flyswatter.
Oh, I see what you mean. My apologies, I thought you wanted adornment on all usage. There had at one point been a proposal to allow "global NAME = EXPR" to mean both "global NAME" and "NAME = EXPR", but I don't know that it ever took off. What you can do, though, is repeat the global declaration on every assignment: def func(x): if not _cached: global _cached; _cached = expensive() _cached[x] += 1 return _cached[x] Given that there'll often be just the one such assignment anyway (as in this example), it won't be a big problem. This is perfectly legal, although it's worth noting that it does trigger a SyntaxWarning (name used prior to global declaration). It's not perfect, but it does allow you to put the word "global" right next to the assignment. ChrisA
On Sat, Jul 11, 2015 at 03:02:23AM -0700, Andrew Barnert via Python-ideas wrote:
Fortunately, Michael has not suggested that. Michael has suggested optional syntax to explicitly declare attributes. He has not suggested to add attributes to the existing implicit lookup order. If "spam" is declared with "self spam", then it must be an attribute. Not a local, nonlocal, global or builtin. If "eggs" is *not* likewise declared, then it *cannot* be an attribute, and the same implicit lookup rules that Python already uses will continue to apply. -- Steve
You are confusing scoping with attribute access. 'self' is not a lexical scope. In a way, if you squint just right, it resembles a dynamic scope (or would under your proposal). But Python isn't elisp, and we don't want to have dynamic scoping. I.e. you'd like bare variables to be (sometimes) scoped to the namespace of the instance eventually created somewhere outside of the class definition (quite likely only created under runtime dependent conditions). In contrast, actual Python is far simpler... all variables are lexically local when defined, unless explicitly declared to have a different and specific *lexical* scope. On Jul 11, 2015 12:58 AM, "Michael Hewitt" <michael@hewitts.us> wrote:
On Sat, Jul 11, 2015 at 08:23:39AM -0700, David Mertz wrote:
I believe you are misunderstanding either dynamic scoping or Michael's proposal. In dynamic scoping, the scope of variables depends on the call chain. So if you write: def spam(): print(x) and then *call* it from function eggs(), spam gets x from the scope of eggs. This is nothing like Michael's proposal.
self is always an instance created outside of the class definition, under runtime dependent conditions. You are describing every instance of every class. You can't create an instance of class Spam *inside the class definition* of Spam, because the class doesn't exist yet: class Spam: x = Spam() # doesn't work
That's not correct. If it were, this would fail with NameError or UnboundLocalError: s = "hello world" def func(): print(s) func() -- Steve
On Sat, Jul 11, 2015 at 10:21 AM, Steven D'Aprano <steve@pearwood.info> wrote:
It's not *exactly* dynamic scope, hence "resembling."
In dynamic scoping, the scope of variables depends on the call chain.
class Foo(): def __init__(self, val): self.val = val if random() < .5: a, b = Foo(1), Foo(2) else: a, b = Foo(2), Foo(1) What's the value of the attribute .val in the namespace 'a' after this code runs? You're right that this is always true of instances, that they are *dynamically* created at runtime. C.f. "resembling". I didn't claim that the proposal changes the scoping *semantics* of Python, per se. But right now, we have this convenient *syntactic* marker that .val is going to live in the namespace whose place is held in the definition by the name 'self'. Under his proposal, readability suffers because we no longer have that marker on the variable itself.
Take a look at what I wrote. 's' is *defined* in the enclosing scope of the function definition (i.e. probably the module scope; although perhaps your code is copied from some other nested scope, which would make 's' nonlocal rather than global). Module scope is also "lexical locality".
Michael Hewitt <michael@hewitts.us> writes:
That's a pity. You can choose a different word if you like.
Another way to say that is that the author must *explicitly communicate*, to the reader, the namespace of each name within the function scope. don't make the mistake of attempting to optimise time spent typing in code, versus time spent comprehending the code as a reader. The latter far outweighs the former, and is the preferred target for optimisation.
With respect, I doubt that the time spent on that is anywhere near the time which would be spent trying to diagnose bugs caused by implicit namespaces. You're aware of the cost in writing explicit names, because you're paying it now. You are, I testify from painful experience in languages other than Python, saving a much greater amount of time in hunting bugs caused by ambiguously-written code.
I share your abhorrence, that would be an unwarranted step. Who is advocating taking that step? No-one in this thread that I can see. If someone advocates “require prefixing of all Python [names] with ‘self.’, ‘global.’, or ‘local.’” within my earshot, I'll join you in criticising the foolishness of such an idea.
You haven't presented anything compelling in support of that. The latter doesn't follow at all from the former.
Python requires explicit declaration of the namespace for names. That protects me from ambiguities that would otherwise be very common in other people's code. I appreciate that and do not want it threatened. -- \ “I distrust those people who know so well what God wants them | `\ to do to their fellows, because it always coincides with their | _o__) own desires.” —Susan Brownell Anthony, 1896 | Ben Finney
On Sat, Jul 11, 2015 at 6:33 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
Not quite true; Python requires explicit declaration of names when they're bound to, but is quite happy to do a scope search (local, nonlocal, global, builtin) for references. But the rules are fairly simple. Aside from the possibility that someone imports your module and sets module.len to shadow a builtin, everything can be worked out lexically by looking for the assignments. ChrisA
On Sat, Jul 11, 2015 at 06:38:34PM +1000, Chris Angelico wrote:
No it doesn't. It only requires an explicit declaration of names when you don't wish to use the default *implicit* rule that any name you bind to is a local. Accessing a local is always implicit. You cannot declare locals at all (apart from function parameters). You just bind to a name, and Python implicitly treats them as local. Accessing nonlocals and globals may be implicit or explicit, depending on whether you use a global or nonlocal declaration. Accessing builtins is implicit, unless you import builtins and write "builtins.len" (say), which we hardly ever do. In Python, most variables (or name bindings, if you prefer) are implicitly scoped. It is rare that they are explicitly scoped as global, and when they are, that's usually a code smell. ("Global variables considered harmful.") The same applies to attribute access: we normally don't explicitly read from a particular scope. That goes against the principle of inheritence. When you look up "self.attr", you don't know whether the attribute returned will come from the instance __dict__, the class, or a superclass, the scope is implied by the history and type of the instance itself. To say nothing of descriptors like property, or methods. That's about as implicit as you can get. A naive reading of the Zen would suggest that, explicit being better than implicit (what, always? under all circumstances?), Python must be a pretty crap language, it has got so many implicit semantics... In contrast, the new rule suggested is *explicit*. You explicitly declare that a name belongs to the scope: self spam, eggs, cheese declares that spam, eggs and cheese are members of self. That's good enough for nonlocals and globals. (By the way, I used to prefix all my global variables with "g", to be explicit that they were global. That stage in my development as a programmer didn't last very long. Fortunately, I was never silly enough to prefix all my locals with "l".) Ben has agreed that it would be harmful to have to explicitly scope each and every name access: if not builtins.len(nonlocals.x + locals.y): raise builtins.ValueError(globals.ERROR_MSG) I trust that everyone agrees with this point. So it seems that explicit is *not* always better than implicit. So why do we behave as if the Zen of Python is some source of ultimate truth? The Zen is not supposed to be a thought-terminating cliche. As Terry Reedy wrote a few years ago: "People sometimes misuse Tim Peter's Zen of Python points. He wrote them to stimulate thought, not serve as a substitute for thought, and certainly not be a pile of mudballs to be used to chase people away." When you read a line of code in isolation: spam = eggs + cheese there is no hint, no clue, as to which of these are globals, nonlocals, locals, or even builtins. And yet we cope with the ambiguity, and I don't hear people claiming that we need to explicitly tag names with their scope, as we do with attributes. So what makes attributes so special that we have to break the rules that apply to all other variables? No tags needed: builtins, globals, nonlocals, locals. Tags needed: attributes. This isn't a rhetorical question, but this post is long enough, and I daresay half my readers have tuned out a few paragraphs ago, so I'll take my answer to the question to a new post. -- Steve
On Sun, Jul 12, 2015 at 1:07 AM, Steven D'Aprano <steve@pearwood.info> wrote:
Sorry, that was sloppily worded. I was making the point that Python does _not_ require declarations when names are referenced, but in the process implied that Python _does_ require them when they're bound to, which as you say is not always the case. But it is still true that Python requires explicit declarations _only_ when names are bound to. In any case, I was arguing against a position which nobody actually held, due to a misunderstanding of a previous post. We're all in agreement that the search path is a Good Thing when referencing names. (Side point: This is true of a lot of other search paths, too. Create explicitly, reference implicitly. The command path on Unix or Windows, the PostgreSQL schema search path, the Python module search directories (sys.path), they're all looked up by unqualified name; but when you create something, you usually have to say exactly where it gets put. Sometimes there's a default (Postgres lets you implicitly put things into the first location on the search path, which is what you most commonly want anyway), sometimes not even that (creating a file without a path name will put it in the current directory, which on Unix is not in $PATH).) ChrisA
On Sun, Jul 12, 2015 at 01:07:56AM +1000, Steven D'Aprano wrote:
The short answer is, sometimes they are special, and sometimes they aren't. Implicit self is a much-requested feature, and not just in Python. Eiffel, for example, uses the "Current" keyword, and it is sometimes optional. Swift has implicit member access as well: var x = MyEnumeration.SomeValue x = .AnotherValue https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift... And yet C++ which has implicit "this", people regularly end up prfixing their attributes with a pseudo namespace, "m_..." (for member). I have come to the conclusion that this is not just personal preference. I now believe that where you stand on this question will, to some degree, depend on the type of code you are writing. If you are writing "enterprisey" heavily object oriented code, chances are you are dealing with lots of state, lots of methods, lots of classes, and you'll need all the help you can get to keep track of where that state lives. You will probably want explicit self for every attribute access, or a pseudo-self naming convention like m_ in C++, to help keep it straight in your head. *Understanding the code* is harder than writing it in the first place, so having to write a few extra selfs is a negligible cost with a big benefit. Attributes are special because they are state, and you have lots of state. But look at Michael's example code. That's real code too, it's just not enterprisey, and there are many Python programmers who don't write enterprisey code. They're beginners, or sys admins hacking together a short script, or editing one that already exists. For them, or at least for some of them, they have only a few classes with a little bit of state. Their methods tend to be short. Although they don't have much state, they refer to it over and over again. For these people, I believe, all those explicit selfs do is add visual noise to the code, especially if the code is the least bit mathematical or if there are well-known conventions that are being followed: class Vector: def abs(self): return sqrt(x**2 + y**2 + z**2) # versus return sqrt(self.x**2 + self.y**2 + self.z**2) We're told that programs are written firstly for the human readers, and only incidentally for the computer. I expect that most people, with any knowledge of vectors, would have understood that the x, y, z in the first return must refer to coordinates of the vector. What else could they be? The selfs are just noise. If we are writing for human readers, sometimes we can be too explicit. Or to put it another way: If we are writing text for human readers who will read that text written by us, sometimes we can be too explicit in our writing for those same readers, causing a decrease in readability, which is an undesirable outcome. I don't intend to defend "Do What I Mean" attribute inference. I don't believe that is practical or desirable in Python. But there's a middle ground: Michael's suggestion, where we can explicitly declare that certain names are attributes of self, and thereby decrease the visual noise in that method. If you're thinking about enterprisy 50- or 100-line methods, this solution probably sounds awful. Every time you see a variable name in the method, you have to scroll back to the top of the method to see whether it is declared as a self attribute or not. And there are too many potential attributes to keep track of them all in your head. And I agree. But that sort of code is not the code that would benefit from this. Instead, think of small methods, say, ten or fifteen lines at most, few enough that you can keep the whole method in view at once. Think of classes with only a few attributes, but where you refer to them repeatedly. Maybe *you* don't feel the need to remove those in-your-face selfs, but can you understand why some people do? In recent years, Python has gained some nice new features and batteries aimed at the advanced programmer, such as async etc. This, I believe, is one which may assist programmers at the less advanced end. They have no need for awaitables and static type checking, but they sure would like less visual noise in the methods. -- Steve
On Jul 11 2015, Steven D'Aprano <steve-iDnA/YwAAsAk+I/owrrOrA@public.gmane.org> wrote:
Thanks for that excellent post. I hope it'll cause some people to reconsider. Although there seems to be a flood of objection mails, most of them seem more instintive than rational to me. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
On Sat, Jul 11, 2015 at 12:10 PM, Nikolaus Rath <Nikolaus@rath.org> wrote:
This is a great example of why the proposal is a bad one. Yes, not using magic makes a one-line function slightly longer (and even slightly less readable). But I also don't want to have to guess about WHICH 'x' or 'y' or 'z' is the one being used in calculation of Cartesian distance. Sure, an obvious implementation of a Vector class probably has x, y, z attributes of self. The example was rigged to make that seem obvious. But even then, I don't really know. Maybe the z direction of the vector is stored as a class attribute. Maybe the class expects to find a global definition of the z direction. Sure, keeping the z direction somewhere other than in self is probably foolish if you assume "Vector" means "generic vector". What if the class was called "RestrictedVector"? Would you know without reading the full class and docstring exactly in what respect it is "restricted"? E.g. are you sure it's not "restricted in the z dimension"? As someone else points out, if you WANT local variables in a method, you are welcome to use them. E.g.: def times_matrix(self, matrix): x, y, z = self.x, self.y, self.z # Many more than one line of implementation # ... stuff with matrix indexing and referencing x # etc. return result_matrix No one stops you now from giving local names to values stored in the instance within a method body. But when you do so, you KNOW 30 lines later that they are local names, even after the "local-looking name is actually an attribute" declaration has scrolled away. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
On Sat, Jul 11, 2015 at 12:18 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Actually I was taught to use "this" everywhere if I can. But look at Michael's example code. That's real code too, it's just not
I disagree that we really need to distinguish what consituttes enterprisey code. In fact it is a bad idea to think there is even such notion because people should express code in the cleanest and most intuitive way possible. Even a beginner can and should benefit from explicitness. I am sure everyone here have read enterprisey code and know that enterprisey code is not really enterprisey code. Complexity is a different discussion, and does not justify why someone would want to be less explicit or more explicit. That's same argument why can't we have make init a reserved class method, why have __init__? I can come up with a bunch of other arguments why Python language should do Y instead of X to make code less visually noisy. We cannot appeal to everyone's need if the visual noise is such a no deal in performance and in learning a language. Sure people can write "self" like this: def regular_function(elf, self): # self is just some Python object... elf.name = 'foo' self.name = 'bar' But this is still clear to beginner that hey this is just a regular function, self in this case is some kind of object.... Anyway, when I was a student, scoping was a very popular question among my peers when they first learn a new language. On Sat, Jul 11, 2015 at 12:04 PM, Michael Hewitt <michael@hewitts.us> wrote:
I still -1 on the dot prefix. We might as well adopt $ in that case. "dot" is a poor choice. It is one of the most easily missed character to type. And again I don't see the benefit of having self. and $ co-exist. We should choose one way, but obviously this cannot be the case because we need backward compatibility. On Sat, Jul 11, 2015 at 3:41 PM, David Mertz <mertz@gnosis.cx> wrote:
John Wong writes:
I don't think "unintuitive" is what is meant by "enterprisey code". I suspect that what is meant is large objects that have slews of attributes that need to be initialized, with a large variety of conventions for constructing defaults. If your code needs to consist mostly of long sequences of attribute assignments followed by returning the result of a method call, I see nothing wrong with writing it as a long sequence of assignments followed by a method call.
On 12 July 2015 at 05:41, David Mertz <mertz@gnosis.cx> wrote:
Perhaps that's an answer that could be pushed more heavily? Q: My method is drowning in self references, how can I make it more readable? A: Bind referenced attributes to local names at the beginning of the method, and write them back to instance attributes at the end of the method. For example, rather than writing: class ObjectInMotion: def keep_moving_gravity(self): self.y += self.gravity self.y = max(self.y, 0) self.y = min(self.y, height - 1) We can write: class ObjectInMotion: def keep_moving_gravity(self): y = self.y + self.gravity y = max(y, 0) y = min(y, height - 1) self.y = y This approach is then conveniently amenable to factoring out helper functions that are independent of the original class definition: def calculate_next_location(current, gravity, height): next_location = current + gravity next_location = max(next_location, 0) next_location = min(next_location, height - 1) return next_location class ObjectInMotion: def keep_moving_gravity(self): self.y = calculate_next_location(self.y, self.gravity, height) I like this angle, as it encourages thinking about mutating operations on instances as a "read, transform, write" cycle, rather than multiple in-place mutations (although the latter may of course still happen when the attributes being manipulated are themselves mutable objects). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12 July 2015 at 01:04, Nick Coghlan <ncoghlan@gmail.com> wrote:
<snip>
I prefer this particular style. Following object-oriented code means keeping track of state. In any non-trivial method this approach makes it easier to see what state serves as additional input to the method and what state is changed as output of the method. This is part of the implicit "signature" of a method on top of its input arguments and return values so it's good to separate it out from any internal calculations. Also modifying state in place is inappropriate for objects being used in a "physics" situation as the motivating examples does: def keep_moving_gravity(self): self.y += self.gravity self.y = max(self.y, 0) self.y = min(self.y, height - 1) The problem is that this method simultaneously calculates the new position and overwrites the old one (in a non-invertible way). In a program where there is only one variable that might be fine. However if we need to detect collisions with other objects then this won't work. Also if the velocity/acceleration of this object depends on e.g. the position of some other object then we end up with order-dependent physics: if I update ball1 first and then ball2 I get different results than I would if I call the update methods in the reverse order. Similarly if you write something like this: def update(self, dt): self.vy += self.gravity * dt self.y += self.vy * dt Then the result depends on the order of the two lines of code in the method. It should really be something like: def update(self, dt): # read y, vy = self.y, self.vy # calculate new values from old new_vy = vy + self.gravity * dt new_y = y + vy * dt # Using vy not new_vy on RHS # update state atomically self.y, self.vy = new_y, new_vy A better general approach is that each object reports what velocity it thinks it should have: def get_velocity(self, system_state): return (0, self.gravity) # Assuming 2D Then a controller can pass the current state of the system to each object and ask what velocity it has and then update all objects simultaneously checking for and resolving collisions etc. as it does so. Building the update logic into every class means that every class needs to be changed in order to redesign anything in the main physics loop (to add collision detection, variable timestep etc). -- Oscar
On 7/11/2015 3:41 PM, David Mertz wrote:
or def abs(v): return sqrt(v.x**2 + v.y**2 + v.z**2)
Localization, which is not limited to self attributes, does two things: it removes the need to continually type 'object.x'; it makes the remaining code run faster. I would be interested to know how many faster local references are needed to make up for the overhead of localization. -- Terry Jan Reedy
Terry Reedy wrote:
If you access the attribute just twice, that's enough for localisation to yield a speedup. Local variable access is just that much faster than attribute lookup. $ python3 -V Python 3.4.3Terry Reedy wrote:
If you access the attribute just twice, that's enough for localisation to yield a speedup. Local variable access is just that much faster than attribute lookup. $ python3 -V Python 3.4.3 $ python3 -m timeit -s "class C: pass" -s "c = C();c.x=1" "c.x;c.x" 10000000 loops, best of 3: 0.106 usec per loop $ python3 -m timeit -s "class C: pass" -s "c = C();c.x=1" "x=c.x;x;x" 10000000 loops, best of 3: 0.0702 usec per loop $ python -V Python 2.7.3 $ python -m timeit -s "class C(object): pass" -s "c = C();c.x=1" "c.x;c.x" 10000000 loops, best of 3: 0.105 usec per loop $ python -m timeit -s "class C(object): pass" -s "c = C();c.x=1" "x=c.x;x;x" 10000000 loops, best of 3: 0.082 usec per loop regards, Anders
My stance on this: that's the responsibility of the Python interpreter not the one of the Python programmer. Reminds me of the string concatenation issue of older Python versions: - https://wiki.python.org/moin/PythonSpeed/PerformanceTips#String_Concatenatio... - https://wiki.python.org/moin/PythonSpeed/PerformanceTips#Avoiding_dots... On 12.07.2015 17:11, Anders J. Munch wrote:
On 24 Jul 2015, at 16:22, Sven R. Kunze <srkunze@mail.de> wrote:
My stance on this: that's the responsibility of the Python interpreter not the one of the Python programmer.
It’s just one of the tricks you can micro-optimise code when needed. The important bit is *when needed*, this trick (and simular ones) should IMHO only be used when benchmarking shows that you have a problem that is solved by it and not proactively because these tricks tend to make code less readable. Ronald
On Jul 11 2015, David Mertz <mertz-vlcHsuTvavqeZLLa646FqQ@public.gmane.org> wrote:
So how do you know if z is a class or an instance attribute if you write "self.z" instead of "z"?
Maybe the class expects to find a global definition of the z direction.
With the proposal, the above would actually read def abs(self): self x, y, z return sqrt(x**2 + y**2 + z**2) so it is obvious that z is not a global but an attribute of self.
As Steven has so nicely written in the mail that I responded to: ,---- | If you are writing "enterprisey" heavily object oriented code, chances | are you are dealing with lots of state, lots of methods, lots of | classes, and you'll need all the help you can get to keep track of where | that state lives. You will probably want explicit self for every | attribute access, or a pseudo-self naming convention like m_ in C++, to | help keep it straight in your head. *Understanding the code* is harder | than writing it in the first place, so having to write a few extra | selfs is a negligible cost with a big benefit. Attributes are special | because they are state, and you have lots of state. | | But look at Michael's example code. That's real code too, it's just not | enterprisey, and there are many Python programmers who don't write | enterprisey code. They're beginners, or sys admins hacking together a | short script, or editing one that already exists. For them, or at least | for some of them, they have only a few classes with a little bit of | state. Their methods tend to be short. Although they don't have much | state, they refer to it over and over again. | [...] | If you're thinking about enterprisy 50- or 100-line methods, this | solution probably sounds awful. Every time you see a variable name in | the method, you have to scroll back to the top of the method to see | whether it is declared as a self attribute or not. And there are too | many potential attributes to keep track of them all in your head. | | And I agree. But that sort of code is not the code that would benefit | from this. Instead, think of small methods, say, ten or fifteen lines at | most, few enough that you can keep the whole method in view at once. | Think of classes with only a few attributes, but where you refer to them | repeatedly. Maybe *you* don't feel the need to remove those in-your-face | selfs, but can you understand why some people do? `---- Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Sure, and this exists right now as an option: def abs(self): x, y, z = self.x, self.y, self.z return sqrt(x**2 + y**2 + z**2) The small number of characters saved on one first line isn't worth the extra conceptual complexity of learning and reading the next construct.
I don't buy it. I don't want a language construct that is meant to self-destruct as soon as people's methods grow past 30 lines (yes, I know it wouldn't literally do so, but there is a pretty small threshold beyond which it turns from making "code golf" easier to actively harming readability).
On 07/11/2015 04:38 AM, Chris Angelico wrote:
I think some don't realise the names in a class block are not part of the static scope of the methods defined in that same class block. The methods get the static scope the class is defined in, but that excludes the names in the class block. If a class inherits methods defined in another module, those methods get the static scope where they were defined, and the methods local to the child class get a completely different static scope. But usually it's not a problem, thanks to "self". ;-) Cheers, Ron
On 11 July 2015 at 18:33, Ben Finney <ben+python@benfinney.id.au> wrote:
That's not the way I read Michael's proposal. I read his proposal as aiming to cut down on visual *noise* when *reading*. It's worthwhile to compare the different examples in terms of "characters conveying useful information": def keep_moving_gravity(self): self.y += self.gravity self.y = max(self.y, 0) self.y = min(self.y, height - 1) Here, self is repeated 7 times: 28 characters. Discounting indentation and line breaks, the whole function is only 96 characters long, so almost a third of the function definition consists of the word "self". With Michael's proposal, that changes to: def keep_moving_gravity(self): self y, gravity y += gravity y = max(y, 0) y = min(y, height - 1) Total character length is now 79 characters, with 15 characters devoted to the "self y, gravity" declarative element. That's a worthy reduction in visual scoping noise (to less than 20%), but it's come at the cost of losing actual signal: there's no longer a local marker on the references to "y" and "gravity" to say they're instance variables rather than local variables. That's also still worse than the best current code can already do (without breaking the "self" convention) which is to assign a frequently accessed object to a single character variable name: def keep_moving_gravity(self): s = self s.y += s.gravity s.y = max(s.y, 0) s.y = min(s.y, height - 1) That keeps all of the relevant attribute lookup signal, and is only 14 characters of scoping noise (8 for the "s = self", 6 for the single character object references) out of 86 total characters. Finally, an "implied reference to first parameter" for attribute lookups inside functions offers the most minimalist proposal I can think of that would still be easy to read from a semantic perspective: def keep_moving_gravity(self): .y += .gravity .y = max(.y, 0) .y = min(.y, height - 1) We've reduced the function length to only 72 characters, and it's 100% signal. The only thing we've lost relative to the original is the 6 explicit references to "self", which are now implied by looking up an attribute without specifying a source object. If we *did* do something like that last example (which I'm not convinced is a good idea, given that the "n = name" trick works for *any* frequently referenced variable, whether inside a function or not), we'd need to think seriously about the implications for implicit scopes, like those created for generator expressions and container comprehensions. At the moment, their first argument is the outermost iterable, which would become accessible within the expression body if there was a syntax permitting implied references for attribute lookups. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Nick Coghlan <ncoghlan@gmail.com> writes:
I read [Michael Hewitt's] proposal as aiming to cut down on visual *noise* when *reading*.
Okay. In response to that, then: Michael appears to want most of those references to entirely omit the explicit namespace. The desire to entirely remove explicit namespaces to distinguish names in a function, I don't sympatise with. Those explicit namespaces make the code much more readable. I don't know what Michael means by “clean”; if it is a simple “fewer characters”, that's not strongly correlated with easier-to-read code. Especially because readable code *also* requires clarity and rapid comprehension – including disambiguation – of the writer's intent. For those purposes, many times the better solution involves writing significantly *more* characters than the strict minimum. So arguments merely leaning on “fewer characters” don't impress me, and I hope they don't impress many others. As for simply choosing a shorter name:
It's worthwhile to compare the different examples in terms of "characters conveying useful information":
Given that “self”, while merely a convention, is now such a strong convention that it is hard-coded into many tools, I argue that “self” conveys much *more* information than a different shorter name (such as “s”). The latter will tend to require rather more effort to comprehend the writer's intent, and to that extent is less readable. -- \ “The right to use [strong cryptography] is the right to speak | `\ Navajo.” —Eben Moglen | _o__) | Ben Finney
On 07/11/2015 05:12 AM, Nick Coghlan wrote:
This works now... def keep_moving_gravity(self): y = self.y + self.gravity y = max(y, 0) self.y = min(y, height - 1) I don't think the self comes up as frequently as it may seem in well written code. And in the above, self is written once, but the other names y and gravity are repeated again. So the gain isn't as great as it may seem at first. What would this do? def __init__(self, red, blue, green): self red, blue green red = red blue = blue green = green If the names are long, it would take more characters than the equivalent version using self. Cheers, Ron
On 11 July 2015 at 17:25, Michael Hewitt <michael@hewitts.us> wrote:
Alternative proposal: def keep_moving_gravity(self): .y += .gravity .y = max(.y, 0) .y = min(.y, height - 1) The main objection folks have to the declarative proposal is the fact that there's nothing obvious at the point of reference to indicate whether we're manipulating a local variable or an instance variable. I can speak from experience in saying that there's a reason the "m_*" prefix notation for C++ member variables is popular: it makes C++ method implementations much easier to read when you can tell at a glance if a line is working with an instance member or a local variable. With the language not providing that separation by default, folks added it by convention. An "implied attribute reference" proposal would be different: it could build on the same mechanism that powers zero-argument super to make it possible to say "if I reference an object attribute in a function without saying which object I'm referring to, then I mean the first parameter". This should work cleanly for standalone functions, class methods, instance methods, etc, as the compiler already keeps track of the necessary details in order to implement PEP 3135 (https://www.python.org/dev/peps/pep-3135/#specification) The main downside is that a leading dot isn't as good a visual indicator as a dot appearing between two other characters. That could potentially be alleviated with a double-dot notation: def keep_moving_gravity(self): ..y += ..gravity ..y = max(..y, 0) ..y = min(..y, height - 1) The downside of *that* is it might make people start thinking in terms stepping up scopes, rather than referring to the first parameter. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jul 11, 2015 1:40 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
Assuming the parser could be made to handle this (which feels like a big stipulation), this variation would deal with the non-explicit dynamic scoping bug magnets. It might violate the "looks like grit on Tim's screen" principle, but it is explicit. I'd only be -0 or -0.5 on this idea. Since we have Unicode though, how about: •y += •gravity Or ∆y += ∆gravity Guaranteed no parser ambiguity, and some symbols are bigger than grit. In fact, maybe we could get the Unicode Consortium to add a glyph that looked like 'self.' To make it stand out even better.
I am officially dropping my original proposal in favor of Nick's. Using a single '.' prefix to reference class variables is brilliant. It has the added benefit of scoping auto-completion within IDEs, which is incredibly helpful for beginners and veterans alike. As an aside, I have learned that long functions are bad form (reference Robert Martin's Clean Code series - #3 Functions). Using short functions with descriptive names has revolutionized code readability at my company. Incidentally, it also mitigates concerns about distinguishing locals from class variables. Additionally, I would caution against allowing a lesser used language feature (decorators) to drive the design of a more common feature (field references in methods). I want to thank you folks for helping to shape one of the most beautiful languages I have encountered. I apologize for the hit-and-run, but I can see that being a part of this discussion is not good for my health, causing me to send emails at 1AM and stew about the issue all night, so I will need to withdraw. My primary reason for exploring Python was as a 'first language' for my son and also as a potential option for future introductory programming courses that I might teach. Except for 'self' redundancy, it is a nearly ideal first language. Hopefully my feedback has been useful. Michael On Sat, Jul 11, 2015 at 1:40 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 11/07/2015 08:25, Michael Hewitt wrote:
Yes, as I already have.
Wrong, as Ben Finney has already pointed out. You'll also have to wade up and down any large methods to ensure that you distinguish local variables from instance variables. Frankly I see nothing in this proposal at all, so I'm moving from -1 to the -1000 somebody else gave it in the early hours of the mornig, I'm sorry but I forget who that was. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On Fri, Jul 10, 2015 at 6:31 PM, Michael Hewitt <michael@hewitts.us> wrote:
I will give it a month after something like this goes into the language for style guides to appear that will recommend prefixing all member variables with a triple underscore to distinguish them from the locals.
Hello, On Fri, 10 Jul 2015 15:31:28 -0700 Michael Hewitt <michael@hewitts.us> wrote:
Even the language which is bag of warts - JavaScript - has essentially banned usage of its "with" statement: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements... . And the reason for this is (as the red box on that page says) that it interferes with readability, maintainability, and performance. And yet you propose to add essentially the same to Python. If you have troubles explaining why "self" is needed to kids, I'd suggest going along the lines of why there's capital letter at the start of sentence, full stop at the end, and wh hmn lnggs hv vwls, vn thgh ts pssbl t rd wtht thm.
-- Best regards, Paul mailto:pmiscml@gmail.com
On Sat, Jul 11, 2015 at 10:06 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
Hebrew and Arabic manage without vowels. English manages (almost) without diacriticals. Hungarian (I think) manages without verb tenses. Chinese and Japanese can manage without punctuation, although these days they usually use it. And Python manages without declared variables, which is why 'self.x = self.y' is completely different from C++ and family. But that also means that it's different from the JavaScript 'with' block, because the "self x, y" declaration is explicit about exactly which names are scoped that way. This wouldn't have that problem. However, I'm not sure it would be all that useful. Also, the current definition means that the first parameter magically becomes a keyword during the parsing of that function, which is extremely odd. I'm not seeing huge value in this, given that the declaration means yet another place to repeat all your attribute names; the only way I could imagine this being smoother is if you could make your declaration at class scope, and then it applies to _all_ the functions defined in it - but that wouldn't solve the problems either. ChrisA
On 07/10/2015 03:31 PM, Michael Hewitt wrote:
This suggestion is fully backward compatible with existing Python code, but would eliminate the need to pollute future Python methods with copious 'self.' prefixes, thereby improving both readability and maintainabilty.
I disagree. Having a method with nothing but plain variables, plus a "scoping" line towards the top, will cause more work in keeping track of which are instance variables and which are local variables. Besides that, what happens when you create a function outside a class, and then add it to a class? class Blah: pass def a_func(self, a, b): self c, d ... Will that work? - Yes seems silly in the case of non-method functions - No seems artificially restrictive -- ~Ethan~
On Fri, Jul 10, 2015 at 03:31:28PM -0700, Michael Hewitt wrote:
At first, I was all "not another poorly thought out implicit self proposal!", but then I read it and thought, "you know, of all the implicit self proposals I've read, this is the first one that I might be able to get behind". It's clever. Possibly too clever. You cleverly avoid needing to introduce a new keyword to the language by using the name of the first parameter as the pseudo-keyword. I like that, but I think it may be a little to radical for the conservatives in the Python community. We tend to suffer from a sort of anti-"not invented here" syndrome: unless something has been tried and tested in at least one other language, and preferably a dozen, we don't want to know about it. It would help your case if you can show a language that already has this feature. Personally, I don't think of "self" as pollution at all. It's nice and explicit and helps readability. But if people wanted to avoid using it, and I can think of the odd case here and there where I might want to do so, I think an explicit declaration is a decent way to go.
You say "same as", I presume that this is a compile-time transformation that you write "x = 5" and the compiler treats it as "self.x = 5". So it doesn't matter whether x is a property or other descriptor, it will resolve the same as it currently does. I can see one (horrible) corner case: suppose you have code like this: def spam(self): self self self = self My guess is that this ought to be banned, as it's not clear when self refers to the self local variable and when it refers to the implicit self.self. It might also help your case to convince people that implicit attribute references are not as bad as they might seem. Can you give a brief survey of languages with implicit attribute references, and how they deal with the ambiguity of "attribute or variable"? -- Steve
Steven D'Aprano <steve@pearwood.info> writes:
Personally, I don't think of "self" as pollution at all. It's nice and explicit and helps readability.
+1. All the complaints that I see about “pollution” or “extra work” or etc., seem IME to be accompanied by a dislike of Python's “explicit is better than implicit” principle. Since I think that principle is essential to Python's readability and maintainability, I think that removing explicit ‘self’ would tangibly *harm* readability and maintainability of Python code. -- \ “I bet one legend that keeps recurring throughout history, in | `\ every culture, is the story of Popeye.” —Jack Handey | _o__) | Ben Finney
-1000 This looks like an absolutely terrible anti-feature. It makes all code less readable, and violates the principle of locality (albeit, `global` and `nonlocal` can also be declared relatively far away from the use of those scoped variables too). On Fri, Jul 10, 2015 at 3:31 PM, Michael Hewitt <michael@hewitts.us> wrote:
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
-1e200. I have to deal with implicit 'this' enough in C++ at the risk of writing "bad style" or something like that. It has bitten before. Until I started following C++ style guides, I always put 'this->' in front of every variable but still had to deal with the accidental member reference when you meant something else. I also like the fact that Python lets you name constructor arguments the same way as members, e.g.: class X: def __init__(self, x, y): self.x = x self.y = y You can do the same in C++, but compilers with -Wall will complain unless you do this: class X { public: X(int x_, int y_): x{x_}, y{y_} {} ... } which is just ugly. On July 10, 2015 5:31:28 PM CDT, Michael Hewitt <michael@hewitts.us> wrote:
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi. Steven D'Aprano <steve@pearwood.info> writes:
Personally, I don't think of "self" as pollution at all. It's nice and explicit and helps readability.
+ 1 as well I am definitely in the conservative camp (I don't know who else but I am). Let's stick to Zen of Python. * I see no real use case why I would write self x,y instead of self.x = 1, self.y = 2. This reminds me of Javascript var x,y. * While this is not exactly like Javascript's "this", I can see the resemblance, and no thanks. * This change will be confusing to everyone reading Python code. We have to stick to real readability, not some rare . We should not introduce this kind of change to say "we can do X in two ways, and most people will write in the old convention ANYWAY but be hold there is a second geeky way to do the same thing." Let's reserve the idea that self x where now x is scoped to self .... reserve this idea to just nonlocal and global - I personally haven't found a use case for nonlocal and global in my own work but that's just my opinion. Thanks. John On Fri, Jul 10, 2015 at 10:42 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
On 11.07.2015 00:31, Michael Hewitt wrote:
-1 on this. How would I know that x is "bound" to self later on in the method without scanning the whole method body for a possible reference to self.x ? As Python programmer, you default to assume that x = 5 refers to a local variable assignment (globals aren't used much, and when they are, the global definition is usually written as first statement in a function/method). If we'd have something like: with self: x = 5 y = 6 as in Pascal, this would be explicit and it's also clear that there's special scoping going on in the body of the with statement block. I still wouldn't like this much, but at least it follows explicit is better than implicit. Overall, I don't believe much in keystroke optimizations - editors provide all the help you need these days to avoid typing too much, while still allowing you to use descriptive identifiers throughout your program. And that results in much better readability than any scoping tricks ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source
::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Sat, Jul 11, 2015 at 02:53:51PM +0300, Joonas Liik wrote:
It's actually taken from Pascal, where it works quite well due to the necessity of explicit declarations of all variables and record fields. There's even a Python FAQ about it. So don't worry, Python won't get this construct. -- Steve
M.-A. Lemburg wrote:
the global definition is usually written as first statement in a function/method).
The same thing applies to the proposed declaration. However, globals are usually given longish and descriptive names, making it easy to spot them and know what they refer to. Both locals and instance attributes, on the other hand, often have very short and cryptic names, so having them both appear with no prefix would be very confusing. -- Greg
participants (26)
-
Alexander Belopolsky -
Anders J. Munch -
Andrew Barnert -
Ben Finney -
Chris Angelico -
David Mertz -
Ethan Furman -
Greg Ewing -
John Wong -
Joonas Liik -
Joseph Jevnik -
M.-A. Lemburg -
Mark Lawrence -
Michael Hewitt -
Nick Coghlan -
Nikolaus Rath -
Oscar Benjamin -
Paul Sokolovsky -
Ron Adam -
Ronald Oussoren -
Ryan Gonzalez -
Serhiy Storchaka -
Stephen J. Turnbull -
Steven D'Aprano -
Sven R. Kunze -
Terry Reedy