Andre Engels wrote:
> > I am not insisting on anything. I use ``c[:]()`` as shorthand way of
> saying
> > "c() for c in d where d is a container"
> >
> > Having c() support containers seems obvious to me. It jibes with duck
> > typing. Perhaps the title of this thread should have been: "Why don't
> > containers quack?"
> >
> > A change is surprising only if it breaks something. I still haven't seen
> any
> > code that breaks by making such a change. Seeing such code would teach a
> > great deal.
>
> I think it very much bites duck typing. Currently, if I try to execute
> a string or a list or whatever, I get:
>
> TypeError: 'str' object is not callable
>
> But under your proposed semantics, suppose a is a list with some
> executable and some non-executable elements. What should
>
> a()
>
> now give? It cannot be a TypeError, because a list (in your semantics)
> is callable. Whatever error it gives, and whether or not the preceding
> executables are executed first, it will not be an existing error
> acting the way it normally does ...
Since `a()` translates to `a() for a in b` then the error would be the exact
same `TypeError: 'str' object is not callable`
> - there is no Python error for "you
> cannot do this with this object, but you can do it with other objects
> of the same type".
Yes there is:
#------------------------
def yo(): print "yo"
def no(): print blah
yo()
no()
Starting Python debug run ...
yo
Traceback (most recent call last):...
NameError: global name 'blah' is not defined
#------------------------
> And that does not seem to be a case of "We have
> never needed it yet" - the join method seems to have been specifically
> tailored so that no such error is needed.
The join example is pretty cool - I want to study it a bit more - maybe I'm
missing your point?
There are two domain discussions, here:
1) is c[:]() is a good idea for python
2) is c[:]() a good idea in general
Where c[:]() symbolizes [c() for c in a]
In my opinion:
1a) might break something in Python 2.x -
1b) may or may not be a good idea for Python 3K
2a) is a great idea for a specific range of applications
2b) should attempt to coincide with existing idioms
Pragmatically speaking:
I'm not interested in 1a because it may break something. There may be an
edge case where catching a `TypeError: 'str' object is not callable` may
change the behavior of existing code.
I am somewhat interested in 1b but intend to lurk on the python.ideas and
python3k lists before entering a discussion. I tend to shy away from
proposing changes from ignorance. This is QUITE DIFFERENT from asking WHY
something works a certain way. Consider people who ask dumb questions, like
me, to be an opportunity to discover what isn't obvious.
I am intensely interested in 2a. Specifically visual music performances over
the web. I have spent 7 full years and my life's savings on developing a
platform. This particular application will involve millions of simultaneous
events that get passed around as objects. Two of those years have been spent
on developing a domain specific language that needs a very fast `c[:]()` --
which relates to 1b.
I am very interested in 2b. The two most inspiring languages to me are
Python and Occam (a now defunct language Transputers) Both use lexical
indentation. Although I am building a domain specific language I want make
it seamlessly integrate with Python. So that a 12-year-old may start by
patching performances, but ultimately, she may become inspired in writing
python script.
So, this thread has been of keen interest to me, mostly because of 2b. 1b is
of interest because extending Python with C has historically required
separate distributions between various versions of 2.x
So, Andre, you and others have a point, in regards to 1a. I find your post
particularly interesting, because it points out some history with join,
which helps me better understand how to approach 2b.
It wasn't my intent to ruffle feathers, but that in its own regard is
instructive, both in the topic, at hand, and in regard to the Python
community.
Meanwhile, I have written very little code, in the last couple days. It
means that I've taken everyone's suggestions very seriously, often leading
me to blogs and blogs of blogs. Looking back, there have been a couple of
helpful suggestions that I didn't respond to directly. So, for them, my
apologies and thanks!
For now, I am out of here!
Cheers,
\~/
--
http://mail.python.org/mailman/listinfo/python-list
