Modifying the {} and [] tokens

[Michael Chermside]

Geoff Howland writes:
> This post begins to read as an insult here, and continues.  My
> incredible gall at thinking something may be better if it was changed
> and wanting to try it!  I should be pelted with rocks for speaking the
> name Jehova.

Step back a sec... I didn't find Christos's comments "insulting", and
I'm sure they weren't intended that way. You've asked a legitimate
question: "Can I change the behavior of the objects created by literal
{}, [], "", and ''?". The answer to that question was, "Only if you
modify the Python interpreter (written in C)."

Now there are a few places you could go from here. One is that you
could take the advice of a few folks here and check out Ruby. It's
another language which is a lot like Python in many ways, but it's
most significant difference is that it DOES allow programmers to do
EXACTLY the kind of thing that you are asking for.

Another thing you could do would be to explain what it is that you
are trying to achieve, and ask people on this list to suggest
alternative approaches that WILL work in Python. Perhaps they'll
say you need to write "Q({...})" in place of "{...}" everywhere and
that will fix your problem. Or maybe there's some clever metaclass
trick that will help out. If you want to go this route you should
try to describe what problem you are trying to solve (eg: "My
developers all come from a Pascal background, and they keep trying
to use + and - with dicts as if they were sets."). And then keep an
open mind about the responses you receive: some will be off-the-mark
and won't fix your problem, but others will be out-of-the-box and
WILL fix your problem, just not in the way you had expected.

The third approach would be for you to ask questions about WHY the
things you wanted don't work in Python. It's NOT an accident, or
just that we haven't gotten around to it yet, these were deliberate
design decisions. Perhaps once you hear the reasoning you'll find
it doesn't apply to what you're doing, or perhaps you will decide
that Python as-designed makes sense after all.

Since you've already started asking some approach-three style
questions, I will see if I can answer them:

> [] + [] is allowed.  Right?
> 
> {} + {} is not allowed.

That's because it's not clear what to do with {1:'a'} + {1:'b'}.
Should it result in {1:'a'}? {1:'b'}? {1:['a','b']}? An exception?
All of these make sense for different applications, and so Guido
decided to prohibit the whole thing and provide specific methods
like {}.update() as needed.

> len([]) is allowed.
> 
> [].len() is not allowed.

Yes it is. It's just spelled a little funny. Try "[].__len__()" 
instead.

> Why?  I respect Guidos decsions, Python needs a strong leader to make
> them and it got where it is (great language) by having him and the
> rest of the community help out in this regard.

Well, I don't think so. If Guido wants to do it one way but the
community consensus is that another way is better, then I think that
Guido should shut up and go with the community. Guido's personal
strength is that his approaches very often turn out to make great
sense, but sometimes only after you've been trying it for a while,
and NOTHING ever makes sense to ALL users.

> Is now no one allowed to say "hey, I think this should be done, and
> I'd like to make it happen to give it a try"?

It's not only allowed, it's encouraged! Python is open source, so you
can just grab a copy and try out your ideas. You can even try talking
someone else into helping you try them out. Submit a patch, and it
might get accepted. Write a PEP (no coding skill required) and you
might recruit others to write it for you. An extreme example is
Stackless Python. YEARS ago, Christian Tismer wanted to try a very
different approach to managing the call stack in Python. His changes
never got accepted into the core, but now Stackless exists as a
separate distribution. And although it took a while, I'd say that
now Christian probably favors that approach (sorry Christian if I'm
mis-channeling you here): cPython's approach has some advantages
(eg: portability), and Stackless has others (eg: microthreads).


> >With all due respect, Geoff, if this stuff is really important to you,
> >use Ruby.
> 
> Yes, throw the heathen into another language.  I'm not good enough for
> this one.
> 
> I find this attitude really insulting.

It wasn't intended that way. Seriously... Python *INTENTIONALLY*
prohibits you from doing what you are asking for. Ruby is a similar
language that allows, even encourages it. That's worth pointing out --
and maybe worth checking out. But as Christos said "with all due
respect" -- he's presuming that you ARE serious here and DO want
these features, and he's suggesting one way of getting them.

-- Michael Chermside