Re: The whitespaceless frontend
Edward Elliott [EMAIL PROTECTED] wrote: If compactness is all you want, shorten self to s. Personally I like 'me' as it's both shorter and more vernacular: def do_GET (me): me.send_response (200, ok) Absolutely. I've written quite a lot of code (which I wasn't expecting anyone else to maintain) using 'I' for the same reasons. Plus, it's even shorter in terms of characters (if not keystrokes), stands out reasonably well, and for how I read it makes for better English grammar (eg I.send_response(...) -- I guess it depends on whether you're doing the mental transformation of method call to message passing). I stopped doing this when I started (a) maintaining other people's Python code, and having them maintain mine and (b) using editors whose Python syntax highlighting coloured self as special. Readability counts wins over a couple of extra characters. -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ ___ | Frankly I have no feelings towards penguins one way or the other \X/ |-- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
Sion Arrowsmith wrote: Absolutely. I've written quite a lot of code (which I wasn't expecting anyone else to maintain) using 'I' for the same reasons. Plus, it's even shorter in terms of characters (if not keystrokes), stands out reasonably well, and for how I read it makes for better English grammar (eg I.send_response(...) -- I guess it depends on whether you're doing the mental transformation of method call to message passing). I didn't like 'I' because: 1. i don't like caps except for constants (which it sorta is, i guess) 2. it's too close to 'i' which is standard for temporary loop variables 3. the bad grammar (for message passing) is all the fun! I stopped doing this when I started (a) maintaining other people's Python code, and having them maintain mine and (b) using editors whose Python syntax highlighting coloured self as special. Readability counts wins over a couple of extra characters. Sadly, tis true. Which makes me wish they'd just hard-coded 'self' for the damn thing in the first place. Nothing worse than knowing what you're missing. -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
On 4/26/06, Edward Elliott [EMAIL PROTECTED] wrote: Sion Arrowsmith wrote: Absolutely. I've written quite a lot of code (which I wasn't expecting anyone else to maintain) using 'I' for the same reasons. Plus, it's even shorter in terms of characters (if not keystrokes), stands out reasonably well, and for how I read it makes for better English grammar (eg I.send_response(...) -- I guess it depends on whether you're doing the mental transformation of method call to message passing). I didn't like 'I' because: 1. i don't like caps except for constants (which it sorta is, i guess) 2. it's too close to 'i' which is standard for temporary loop variables I picked up a tip when I was working with C++ with regards to these sort of indexes (which I don't use so much in Python anyway, but...) and now use ii, jj etc instead of just i. A single i is harder to pick out an (because of how common i is in English) pretty much impossible to search for. On the other hand, searching for (or highlighting, with an appropriate editor) all instances of ii is much more productive. 3. the bad grammar (for message passing) is all the fun! I stopped doing this when I started (a) maintaining other people's Python code, and having them maintain mine and (b) using editors whose Python syntax highlighting coloured self as special. Readability counts wins over a couple of extra characters. Sadly, tis true. Which makes me wish they'd just hard-coded 'self' for the damn thing in the first place. Nothing worse than knowing what you're missing. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
Hi, [EMAIL PROTECTED] wrote: but maybe instead of the global.name something to refer to the upper namespace (that can be the global one or the namespace of the function that contains this one) can be more general: upper.x = 1 upper.upper.x = 1 Well, people have been trying to come up with a way to solve the nested scopes restrictions. This may work, but in my opinion nested functions are not so important and I wouldn't spend any time to improve them. Usually you can do anything with classes (and method makes that easier). If we say that closures were invented so that we will avoid the extra typing in cases like def f (self): x = lambda self=self: return self.foo () and beyond that perhaps it is a sign that we should rethink our design we can accept the limitations of python's closures. I think that making self a reserved word that can be used only for its usual purpose can be positive. I agree. EPL does not have shoot-self-in-the-foot protections yet, but it will :) The $ and method statement seem interesting too, but the first is a little perlish (but Ruby has something similar, and people like it), and the method statement look a little redundant. I think the $ can be acceptable (Mostly to reduce typing), even if it doesn't look very nice. '$' is perlish and rubyish (and I got it from ruby indeed). It's the cost of a dynamic language :) In static languages we know at compile-time whether a symbol is local, instance or global. In dynamic languages where scopes are modified when the program runs we have to type something. '$' being unused seems like a good choice. method is good not only because we avoid the extra typing in the definition, but also because -after experiments- it seems that restricting the use of $ in methods, will simplify some confusing cases. For example, what happens in: def foo (cls): def bar (self): return $x # what's that? cls.x or self.x? While now, when you see $ you know it refers to the instance of the method. And nested methods in methods are very rare. Bye, Stelios - sorry for the delayed reply. Unexpected easter vacation. -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
Stelios Xanthakis: in my opinion nested functions are not so important and I wouldn't spend any time to improve them. Usually you can do anything with classes Some people like and use them often (like those ones coming from Pascal-like languages, etc), some other people (like those coming from C-like languages like Java) use them rarely and like classes more. Python can choose to have just one way to solve such problems, or to support both kinds of people. At the moment I think it tries to please both kind of programmers. '$' being unused seems like a good choice. It's less explicit than self. but it's shorter, this improves typing, and allows to produce more compact code: return .join([Graph(, repr($o), , , repr($nodeData), )]) Instead of: return .join([Graph(, repr(self.o), , , repr(self.nodeData), )]) But note that every time you want to add a new piece of syntax you must think if the same syntax can be more useful for more common tasks (like string substitution/templating, in this situation). - sorry for the delayed reply. Unexpected easter vacation. No problem. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
[EMAIL PROTECTED] enlightened us with: Some people like and use them often (like those ones coming from Pascal-like languages, etc), some other people (like those coming from C-like languages like Java) use them rarely and like classes more. Python can choose to have just one way to solve such problems, or to support both kinds of people. At the moment I think it tries to please both kind of programmers. If a function X needs a lot of data from the calling function Y, and it is called only from Y, I tend to implement it as an inner function of Y. I like classes a lot, but sometimes I simply want the easiest and cleanest solution. Sybren -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
[EMAIL PROTECTED] wrote: It's less explicit than self. but it's shorter, this improves typing, and allows to produce more compact code: return .join([Graph(, repr($o), , , repr($nodeData), )]) Instead of: return .join([Graph(, repr(self.o), , , repr(self.nodeData), )]) It also creates a special case. Object attributes are generally accessed as obj.foo, while $foo only works from within obj. There are more tradeoffs involved than just compactness and syntax gestalt. If compactness is all you want, shorten self to s. Personally I like 'me' as it's both shorter and more vernacular: def do_GET (me): me.send_response (200, ok) As an added bonus, you get to channel Cookie Monster when you program. :) c = Cookie (good enough) # for me -- http://mail.python.org/mailman/listinfo/python-list
The whitespaceless frontend
It had to happen :) http://pyvm32.infogami.com/EPL Seriously, this is not so much about the whitespace as for the new features, which might interest people who are thinking about new features. More specifically, methods and the $ operator are really great and seem to solve the problem with having to type self. all the time. The new syntax has been tested in core libraries of pyvm. Feedback is welcome, but preferably not in c.l.py because indentation can be a dangerous topic :) Cheers, Stelios -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
This seems nice: global.x = 1 is the same as global x x = 1 but maybe instead of the global.name something to refer to the upper namespace (that can be the global one or the namespace of the function that contains this one) can be more general: upper.x = 1 upper.upper.x = 1 I think that making self a reserved word that can be used only for its usual purpose can be positive. The $ and method statement seem interesting too, but the first is a little perlish (but Ruby has something similar, and people like it), and the method statement look a little redundant. I think the $ can be acceptable (Mostly to reduce typing), even if it doesn't look very nice. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
Stelios Xanthakis wrote: It had to happen :) http://pyvm32.infogami.com/EPL Seriously, this is not so much about the whitespace as for the new features, which might interest people who are thinking about new features. More specifically, methods and the $ operator are really great and seem to solve the problem with having to type self. all the time. The new syntax has been tested in core libraries of pyvm. Feedback is welcome, but preferably not in c.l.py because indentation can be a dangerous topic :) Very nice work. Lotta good ideas (of course that will never show up in in standard python, but who cares). I would mention though if you had used end for block delimiters (like ruby) instead of curly braces, there would be no conflict with dictionary literals. I made such a parser for another project. Just my opinion but end looks a bit cleaner too than curly braces. Now if only you could make python 100 times faster, too. -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
On 4/15/06, Stelios Xanthakis [EMAIL PROTECTED] wrote: It had to happen :) Did it? http://pyvm32.infogami.com/EPL Seriously, this is not so much about the whitespace as for the new features, which might interest people who are thinking about new features. More specifically, methods and the $ operator are really great and seem to solve the problem with having to type self. all the time. The new syntax has been tested in Exactly what is the problem with having to type self all the time? -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
Stelios == Stelios Xanthakis [EMAIL PROTECTED] writes: Stelios It had to happen :) http://pyvm32.infogami.com/EPL Stelios Seriously, this is not so much about the whitespace as Stelios for the new features, which might interest people who are Stelios thinking about new features. More specifically, methods Stelios and the $ operator are really great and seem to solve Stelios the problem with having to type self. all the time. Stelios The new syntax has been tested in core libraries of pyvm. Stelios Feedback is welcome, but preferably not in c.l.py because Stelios indentation can be a dangerous topic :) Stelios Cheers, Stelios Stelios I submit that this kind of work will make generated code a lot easier. There is this perverse joy I take in writing polyglot code, but I wouldn't want to consider, say, some kind of UML model-driven python code generator--the significant whitespace that's so dandy on the human eye would be un-fun for non-trivial code. Props, Chris -- http://mail.python.org/mailman/listinfo/python-list
