469,645 Members | 1,557 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,645 developers. It's quick & easy.

Almost keywords

Once in a while I feel free to write about less defined things, saying
mostly wrong things. This post is mostly chat, if you aren't
interested please ignore it.

Python is fit enough for newbie programmers, but some of its
characteristics can confuse them still, like the variables referenced
by name (that can be solved with a language that gives the illusion of
always manging values), the finite nature of floating point numbers
(that may be partially solved with interval arithmetic used in a smart
way, even if it may end being quite slower than Python floats), the
case sensitivity of all the language (in natural languages the case is
often irrelevant), the absence of rational numbers from integer
divisions, the code formatting precision required by significant
indentations, the "artificial" difference between lazy and eager
things, the silly syntax of tuples, some problems with closures that
partially come from automatic creation of variable names, many
inconsistencies present in the standard library, etc. Python 3.0
solved some of those problems, especially the smaller ones (for
example the "nonlocal" keyword workaround, etc).

If you take a look at the Python newsgroup, you can see that newbies
there do many similar mistakes all the time. A language fit for
newbies can adapt itself to avoiding those most common mistakes (but
today Python is becoming larger and more complex, more fit for real
programmers and less for programming newbies. This may be inevitable
in the evolution of a a language with commercial success). One of the
mistakes you see often is the rebinding of built-in things, like map,
list, etc. (Python 3.0 again turns some of those names into keywords,
avoiding part of those problems).

So you can see code like this that may lead to bugs in programs
written by newbies:
list = [x*x for x in range(100)

A possible way to avoid such bugs is to turn all those names like
"list", "map", "filter", "self", etc into keywords. But this may have
some disadvantages (well, I think I'd like to have "self" as keyword,
seen how all Python books strong suggest to not use a name different
from "self"). An intermediate solution is to change Python so that it
allows you to rebind those half-keywords only of you want it and you
know what you are doing, with a kind of comment at the top of the

# rebinding = True
This allows you to do:
list = [x*x for x in range(100)]

By default rebinding is False, so this produces a SyntaxError:
list = [x*x for x in range(100)]

This may be a silly idea. Designing a good syntax for a language isn't
easy at all.

Note that a widely used Scheme implementation, DrScheme, implements
various sub-languages fit for newbies or almost-newbies or low-
experienced programmers. What is possible for experts can be a syntax
error for newbies. I don't like this feature much, I like more
freedom, but for purely learning purposes it may have its place. So
what I have said regarding the "almost keywords" isn't a totally new
idea :-)

Jul 21 '08 #1
1 973
be************@lycos.com wrote:
A possible way to avoid such bugs is to turn all those names like
"list", "map", "filter", "self", etc into keywords. But this may have
some disadvantages (well, I think I'd like to have "self" as keyword,
seen how all Python books strong suggest to not use a name different
from "self").
I'm not convinced by making 'self' a keyword. Forcing the first argument of
a method to be named 'self' fails for many reasons (e.g.
classmethod/staticmethod) so I don't really see a benefit to making it
special in any way.

For the other names though, this would have the advantage of allowing the
compiler to optimise access to builtins which should provide a slight speed
improvement and I think would also make life easier for some
implementations (especially things like 'locals()').

A half-way house would be to generate a warning for any use of a name which
masks one of the reserved builtins, but only optimise lookups in scopes
where no such masking is seen by the compiler: this would prevent you
overriding builtins by injecting a name into the global namespace from
outside a module but not otherwise break existing code.

Of course any of this would break some existing code and therefore isn't
going to happen.
Jul 21 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Nel | last post: by
14 posts views Thread by Jason Heyes | last post: by
2 posts views Thread by google | last post: by
2 posts views Thread by dw | last post: by
5 posts views Thread by Digital.Rebel.18 | last post: by
9 posts views Thread by Nenad Loncarevic | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.