__brace__ (PEP?)

[James Stroud]

Hello All,

If "__call__" allows anobject() and "__getitem__" allows anobject[arange], why
not have "__brace__" (or some other, better name) for anobject{something}.
Such braces might be useful for cross-sectioning nested data structures:

anary = [[1,2,3],[4,5,6]]

anary{2} ==> [3,6]


or for a list of dictionaries:

alod = [{"bob":1,"ted":2,"carol":3},{"bob":4,"ted":5,"carol":6}]

alod{"ted"} ==> [2,5]


or, heck, a dictionary of lists:

adol = {"bob":[1,2,3],"carol":[4,5,6],"alice":[7,8,9]}

adol{1} ==> {"bob":2, "carol":5, "alice":8}


Though I positively can not see what is wrong with this suggestion, I am sure
this will raise more than a few objections. Please bash my naivete publicly
on the list.

Some preemptive observations

1. on syntactic ambiguity (i.e. "braces already used")

[] ==> used for both list and getitem (both for dict AND list)
() ==> used for tuple, callable, grouping

2. on functional ambiguity (i.e. "function not implicit"):

Q. What exactly does it mean to call an instance of class MyClass?
A. Whatever the author of MyClass wanted it to mean.

etc.

Also, if this exists already, I apologize because I have not seen it in any
Python code before and I wouldn't know what to call it for googling.

James


--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

 

[Roy Smith]

why not have "__brace__" (or some other, better name)
for anobject{something}. Such braces might be useful for
cross-sectioning nested data structures:

This seems like a pretty esoteric operation to devote a bit of syntax to.
It doesn't seem like something people want to do very often.

 

[James Stroud]

This seems like a pretty esoteric operation to devote a bit of syntax to.
It doesn't seem like something people want to do very often.

Similar to __call__, I don't think that this syntax would be neccessarily
devoted to any particular operation. I'm simply offering cross-sectioning as
a potential and intuitive operation that would benefit from a shortcut. The
main point is that using braces after a name is not defined right now and I
think that they could be put to good use.

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

 

[Roy Smith]

Similar to __call__, I don't think that this syntax would be neccessarily
devoted to any particular operation. I'm simply offering cross-sectioning as
a potential and intuitive operation that would benefit from a shortcut. The
main point is that using braces after a name is not defined right now and I
think that they could be put to good use.

James

One of the nice things about Python is that the syntax is relatively
simple, and words are generally favored over punctuation. There's lots of
punctuation which is not currently used, but that doesn't mean it's a good
idea to go off inventing meanings for it. I supposed we could have:

foo->bar ==> foo.__arrrow__(bar)
foo$bar ==> foo.__dollar__(bar)
foo#bar ==> foo.__hash__(bar)
foo::bar ==> foo.__scope__(bar)

and so on down the list of non-alphanumeric characters, but the result
wouldn't be anything most of us would recognize as Python.

 

[Kay Schluehr]

foo->bar ==> foo.__arrrow__(bar)
foo$bar ==> foo.__dollar__(bar)
foo#bar ==> foo.__hash__(bar)
foo::bar ==> foo.__scope__(bar)

I'm strongly in favor for the arrow ( but with two "r" only ). The
question is simply: for what?

and so on down the list of non-alphanumeric characters, but the result
wouldn't be anything most of us would recognize as Python.

After many sleepless nights reading all the comments and flames about
@decorators I finally came up using them.

Ciao,
Kay

 

[Roy Smith]

I'm strongly in favor for the arrow ( but with two "r" only ). The
question is simply: for what?

I'm confused. You're strongly in favor of a piece of punctuation even
though you don't have any idea what it might be used for?

 

[Kay Schluehr]

I'm confused. You're strongly in favor of a piece of punctuation even
though you don't have any idea what it might be used for?

Shurely I was joking. I could imagine a few purposes most likely arrows
of some category. That's what You depicted using the "==>" arrow, that
translates some infix operator expression into it's method description.
Arrows are some kind of 2-tuples that express a transition and which
are "left-exact" i.e. there must be at most a right value to some left
value.

Example:

(foo->bar) -> foo.__arrow__(bar)

This is a recursive definition of the arrow which could be further
expanded:

((foo->bar) -> foo.__arrow__(bar)) ->
foo.__arrow__(bar).__arrow__(foo.__arrow__(bar))

etc.

But something intrigues me and that is the prevalence of "foo" above
"bar" i.e. the preimage above the image. I would like to see that one
starts with the binary relation as the primary concept. A relation
should be instantiated by two classes. Let be Rel(A,B) some relation
created from classes A and B. The instances of Rel(A,B) would be arrows
from A to B depicted as arrow diagrams:

foo->bar -> rel.__arrow__(foo,bar)

There is no absolute meaning of the arrow foo->bar, because it reflects
only the particular relation instance rel.

Besides this I guess Guido wants to use the arrow in the context of
"optional static type declarations" for declaring the return type. I
don't like this optional static stuff but the arrow is playing a role
also in this proposal.

Ciao,
Kay