The whitespaceless frontend

[Stelios Xanthakis]

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

 

[bearophileHUGS]

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

 

[DH]

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.

 

[Chris Smith]

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

 

[Stelios Xanthakis]

Hi,

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.

 

[bearophileHUGS]

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

 

[Sybren Stuvel]

(e-mail address removed) 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

 

[Dennis Lee Bieber]

Some people like and use them often (like those ones coming from
Pascal-like languages, etc), some other people (like those coming from

Original Pascal, as a teaching language, didn't have separate
compilation either -- nesting was the only way to modularize stuff.
--

 

[Edward Elliott]

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

 

[Sion Arrowsmith]

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.

 

[Edward Elliott]

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.

 

[Chris Mellon]

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.