"is" and ==

[Grant Edwards]

Re: c[:]()

On 2007-06-01, Warren Stringer <warren@muse.co mwrote:

>python-ideas lists are the correct forum for those issues,
>though you will of course get all sorts of opinions on c.l.py.

>
Oh well. Perhaps I can relax and actually write functioning
code ;-) What do you mean by 'c.l.py'?

comp.lang.pytho n: the Usenet news group in which this
discussion is taking place.

--
Grant Edwards grante Yow! Is it clean in other
at dimensions?
visi.com

[Erik Max Francis]

Re: c[:]()

Warren Stringer wrote:

As mentioned a while back, I'm now predisposed towards using `do(c)()`
because square brackets are hard with cell phones. The one mitigating factor
for more general use, outside of cell phones, is speed.

The speed at which you can type code is almost _never_ a valid reason to
make something brief. Code gains readability from verbosity. (That can
be taken too far, of course, but that certainly doesn't apply here.)

Either way, something like `do(c)()` to do what you want is easily
implementable in Python, and always has been. Same thing with your
`c()` or `c[:]()` solutions (though the latter makes no semantic sense);
just use custom sequence types.

The questions about implementing a working c[:]() are:
1) Does it break anything?
2) Does it slow anything down?
3) Could it speed anything up?
4) Does it make code easier to read?
5) What question(s) did I forget to ask?

You keep sticking the slice in there. That still makes no sense.

The fundamental reason it does not make logical sense to make a list
callable (which would then call its elements) is that lists can contain
objects that aren't callable. So then, if you want lists to be
callable, the question becomes, what should it do with the elements that
aren't callable? Choke on the first one? Ignore them? Abort entirely
and not call any of them?

This kind of a design question can go every possible way depending on
what particular application you're using the calling syntax for, so the
proper design question from a language perspective is not to choose any.
If you want a callable sequence (which calls its elements and has any
or all of the above behaviors), it is _trivial_ to make one. There is
no need for support for this, because what it should do is not clear.

I use `c[:]()` because it is unambiguous about using a container

There are containers that don't support slicing (a stack, for instance),
so you're not using the right terminology here. If you do mean general
containers, then your slicing violates duck typing since it effectively
enforces a constraint that may not be desired. _If_ one were to have
callable containers, then callable containers should be usable in _any_
context in which an object is called, not just ones where slices were done.

If you intend `c[:]()` to have different semantics than `c()` -- it
isn't clear from your comments whether you mean it to or not, but you
keep nonsensically mentioning the slicing notation -- then you're
_really_ out in left field. Now that requires operations to behave
differently in different contexts, which is a huge can of worms and
rapidly makes code unreadable.

In short, your repeated use of `c[:]()` indicates a fundamental
misunderstandin g about Pythonic style _and_ substance.

>If you're not willing to do that, but still insisting that `c[:]()`
>makes sense, then perhaps it would be more advisable to learn more about
>Python rather than try to suggest profound changes to the language and
>its conventions.

>
You're right. At the same time, version 3 is coming up soon. There is a
short window of opportunity for profound changes.

Soon isn't all that soon. Furthermore, it is very unlikely that someone
is going to be able to suggest profound and useful changes to Python
without first being familiar with it. So stabbing in the dark is not
going to be very constructive for either learning Python, or suggesting
useful improvements. That's just the way the ball bounces, unfortunately.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
To endure what is unendurable is true endurance.
-- (a Japanese proverb)

[Erik Max Francis]

Re: c[:]()

Warren Stringer wrote:

`c[:]()` is unambiguous because:
>
def c(): print 'yo'
>
c() # works, but
c[:]() # causes:
>
Traceback (most recent call last)...
c[:]() # causes:
TypeError: unsubscriptable object
>
There are many `c()` to be found in the wild and no `c[:]()`, thus
unambiguous. To be honest, I wasn't sure, until testing this, just now.

>>c = 'not quite'
>>c[:]

'not quite'

>>c[:]()

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: 'str' object is not callable

You also seem to be under the impression that `x[:]()` is somehow
special syntax that is treated differently than `y = x[:]; y()`. It is not.

Besides, _ambiguity_ was never the problem. _Functionality_ is the problem.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
To endure what is unendurable is true endurance.
-- (a Japanese proverb)

[Warren Stringer]

RE: c[:]()

Warren Stringer wrote:

>

As mentioned a while back, I'm now predisposed towards using `do(c)()`
because square brackets are hard with cell phones. The one mitigating

factor

for more general use, outside of cell phones, is speed.

>
The speed at which you can type code is almost _never_ a valid reason to
make something brief. Code gains readability from verbosity. (That can
be taken too far, of course, but that certainly doesn't apply here.)

There is code that you type which persists and code that you type from a
command line. Two completely different idioms. A credo inside the cell phone
game industry is that you lose half your audience with each menu keystroke.
That's how precious keystrokes are.

What may be confusing is speaking about both idioms at once.

<snip>

In short, your repeated use of `c[:]()` indicates a fundamental
misunderstandin g about Pythonic style _and_ substance.

Please define Pythonic. Is this like a certain US senator who defined porn
as "I know it when I see it."

28 years ago, I wrote a hierarchical DBMS that used lexical indentation. 15
years ago I wrote a multimedia script language that used lexical indentation
and automatic garbage collection - it was deployed on millons of clients. 2
years ago I hand coded every line of the Python 2.2 BNF into another style
of language description. Up until last month, I had tokenized a subset of
said definition in C++, using templates to manage cardinality. Recently, I
decided to forgo the C++ parser and am now rewriting it in Python. This is a
risk. So, what hoop does one jump though to earn that oh so coveted
"pythonic" merit badge?

Your other post responds with working examples. So, I'll jump over to that
one.

[Warren Stringer]

RE: c[:]()

Warren Stringer wrote:

>

`c[:]()` is unambiguous because:

def c(): print 'yo'

c() # works, but
c[:]() # causes:

Traceback (most recent call last)...
c[:]() # causes:
TypeError: unsubscriptable object

There are many `c()` to be found in the wild and no `c[:]()`, thus
unambiguous. To be honest, I wasn't sure, until testing this, just now.

>

>>c = 'not quite'
>>c[:]

'not quite'

>>c[:]()

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: 'str' object is not callable

Interesting example. By extension
#-------------------------

>>def c(): print 'yo'

....

>>c

<function c at 0x00B867F0>

>>c(bad)

Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'bad' is not defined
#-------------------------

Both your example and mine show well formed and ill formed statements at the
command line.

You also seem to be under the impression that `x[:]()` is somehow
special syntax that is treated differently than `y = x[:]; y()`. It is
not.

No; I was under the impression that `x[:]()` didn't work and the reason why
it didn't work wasn't obvious.

I like your use case. Am I correct in assuming that `y = x[:]; y()` is NOT
to be found in working code? If that is the case, then nothing gets broken.
It would be instructive to have a use case where enabling c[:]() would break
existing code.

Besides, _ambiguity_ was never the problem. _Functionality_ is the
problem.

Ambiguity is one of many parameters. It was a problem with another poster. I
wish I had McConnel's Code Complete book handy. Let's see ... a search
yields: debugging, testing, performance, portability, design, interfaces,
style, and notation.

My use case is this:

do(orchestra(sc ore)).pickle()
do(orchestra(co nductor)).seque nce()

And so now, that I can, I am happy. Life is good. Time to sleep.

[Marc 'BlackJack' Rintsch]

RE: c[:]()

In <mailman.8525.1 180689629.32031 .python-list@python.org >, Warren Stringer
wrote:

I like your use case. Am I correct in assuming that `y = x[:]; y()` is NOT
to be found in working code? If that is the case, then nothing gets broken.
It would be instructive to have a use case where enabling c[:]() would break
existing code.

What does "enabling c[:]()" mean? Do you expect after "enabling it"
``c()`` and ``c[:]()`` to be different for the same list or tuple `c`?

My use case is this:
>
do(orchestra(sc ore)).pickle()
do(orchestra(co nductor)).seque nce()

This isn't a use case unless you also say what the involved objects are
and what semantic you expect from this source snippet. Just guessing,
but might the following do what you want without the need to make lists
and tuples callable?

def do(iterable, func):
for item in iterable:
func(item)

do(orchestra(sc ore), pickle)
do(orchestra(co nductor), sequence)

Ciao,
Marc 'BlackJack' Rintsch

[Marc 'BlackJack' Rintsch]

RE: c[:]()

In <mailman.8524.1 180689593.32031 .python-list@python.org >, Warren Stringer
wrote:

>Warren Stringer wrote:
>>

As mentioned a while back, I'm now predisposed towards using `do(c)()`
because square brackets are hard with cell phones. The one mitigating

>factor

for more general use, outside of cell phones, is speed.

>>
>The speed at which you can type code is almost _never_ a valid reason to
>make something brief. Code gains readability from verbosity. (That can
>be taken too far, of course, but that certainly doesn't apply here.)

>
There is code that you type which persists and code that you type from a
command line. Two completely different idioms. A credo inside the cell phone
game industry is that you lose half your audience with each menu keystroke.
That's how precious keystrokes are.
>
What may be confusing is speaking about both idioms at once.
>
<snip>
>

>In short, your repeated use of `c[:]()` indicates a fundamental
>misunderstandi ng about Pythonic style _and_ substance.

>
Please define Pythonic. Is this like a certain US senator who defined porn
as "I know it when I see it."

Yes you are right, "pythonic" is not a hard fact. But one indicator is
consistency and no surprising behavior if possible. And that your
insisting on ``c[:]()`` instead of just ``c()`` seems to indicate you want
a change that is quite surprising. It would mean that a slice of a list
returns an other type with the __call__ method implemented.

28 years ago, I wrote a hierarchical DBMS that used lexical indentation. 15
years ago I wrote a multimedia script language that used lexical indentation
and automatic garbage collection - it was deployed on millons of clients. 2
years ago I hand coded every line of the Python 2.2 BNF into another style
of language description. Up until last month, I had tokenized a subset of
said definition in C++, using templates to manage cardinality. Recently, I
decided to forgo the C++ parser and am now rewriting it in Python. This is a
risk. So, what hoop does one jump though to earn that oh so coveted
"pythonic" merit badge?

Grok The Zen of Python (``import this`` at the interpreter prompt)?
Write "pythonic" code?

I don't see how writing other languages and Python parsers and translators
into other representations tells you much about the spirit and idiomatic
*usage* of a language. Your proposal is not about syntax, it's about
semantics. ``obj[:]()`` is basically syntactic sugar for:
``obj.__getitem __(slice(None)) .__call__()`` and you want a change in the
implementation of `list.__getitem __()` and `tuple.__getite m__()`.

Ciao,
Marc 'BlackJack' Rintsch

[Duncan Booth]

Re: c[:]()

Grant Edwards <grante@visi.co mwrote:

[Please quit saying "a container" if you mean lists and tuples.
"A container" is way too general. There most probably _are_
containers for which c() does not fail.]

One example of such a container is any folderish content in Zope:
subscripting gets you the contained pages, calling renders the default
view.

[Carsten Haese]

RE: c[:]()

On Fri, 2007-06-01 at 02:19 -0700, Warren Stringer wrote:

There is code that you type which persists and code that you type from a
command line. Two completely different idioms. A credo inside the cell phone
game industry is that you lose half your audience with each menu keystroke.
That's how precious keystrokes are.

Then why do have your users typing code into a cell phone?

--
Carsten Haese

http://informixdb.sourceforge.net

[Carsten Haese]

RE: c[:]()

On Fri, 2007-06-01 at 08:39 -0400, Carsten Haese wrote:

On Fri, 2007-06-01 at 02:19 -0700, Warren Stringer wrote:

There is code that you type which persists and code that you type from a
command line. Two completely different idioms. A credo inside the cell phone
game industry is that you lose half your audience with each menu keystroke.
That's how precious keystrokes are.

>
Then why do have your users typing code into a cell phone?

_.replace("do", "do you")

self.drink(coff ee)

--
Carsten Haese

http://informixdb.sourceforge.net

[Grant Edwards]

Re: c[:]()

On 2007-06-01, Carsten Haese <carsten@uniqsy s.comwrote:

On Fri, 2007-06-01 at 02:19 -0700, Warren Stringer wrote:

>There is code that you type which persists and code that you type from a
>command line. Two completely different idioms. A credo inside the cell phone
>game industry is that you lose half your audience with each menu keystroke.
>That's how precious keystrokes are.

>
Then why do have your users typing code into a cell phone?

I've decided the guy is trolling. Most of what he says is just
nonsense.

--
Grant Edwards grante Yow! Xerox your lunch
at and file it under "sex
visi.com offenders"!

[Grant Edwards]

Re: c[:]()

On 2007-06-01, Warren Stringer <warren@muse.co mwrote:

I like your use case. Am I correct in assuming that `y = x[:];
y()` is NOT to be found in working code?

No, you may not assume that.

If that is the case, then nothing gets broken. It would be
instructive to have a use case where enabling c[:]() would
break existing code.

I've already explained such a use case.

You still seem to be operating under the delusion that c[:] is
somehow different than c.

--
Grant Edwards grante Yow! I'm imagining a surfer
at van filled with soy sauce!
visi.com

[dackz]

Re: c[:]()

This discussion has gone in more circles than Earth has gone 'round
the Sun, but it seems you should consider the following:

1) Sequences and functions serve fundamentally different purposes in
Python. One is for containing objects, the other is for executing an
action. (And yes, I'm aware that these concepts can differ in other
contexts. But we're talking about Python.)

2) It seems--at least to me--a bit dubious to change an entire general
purpose programming language to suit a very limited--and frankly
strange--use case.

3) You'd probably be better off making a very simple and concise
domain specific language.

You could do whatever you want with syntax--in the case of a cell
phone, I would think the less punctuation you have, the better. Your
main goal seems to be speed or ease of input, so perhaps a very
abbreviated syntax would be more important than being able to read the
code as if it were English, as is the case in Python--the tradeoff
here being more time spent reading documentation and more time spent
learning syntax. You also might stand to benefit from this move if you
ever decide to implement this software in something other than Python.

Specifically, not requiring parentheses for function calls would
probably be a nice start, and very short built-in names might also be
helpful. Again, this is a tradeoff between readability and speed of
input.

You'd also have to spend more time implementing a parser of some sort.
This could very well outweigh any benefits involved, depending on your
time frame.

But to reiterate the most obvious point: in your context, [:] is just
notation for copying a sequence, so c[:]() would have *exactly* the
same effect as c(). If it helps, you can think of [:] being just like
writing .copy() for dictionaries: it makes a shallow copy, nothing
more. Now think about that while remembering that sequences and
functions serve different purposes in Python and thus have different
semantics. There's a reason this isn't implemented in Python: it would
be confusing beyond belief at first sight. And there's already
perfectly good syntax for this: "for func in funcs: func()"

Being able to write code quickly on a cell phone is not a goal of
Python. That's your goal.

On 5/30/07, Warren Stringer <warren@muse.co mwrote:

I want to call every object in a tupple, like so:
>
#------------------------------------------
def a: print 'a'
def b: print 'b'
c = (a,b)
>

>>c[:]() # i wanna

TypeError: 'tupple' object is not callable
>

>>c[0]() # expected

a

>>c[:][0] # huh?

a

>[i() for i in c] # too long and ...huh?

a
b
[None,None]
#------------------------------------------
>
Why? Because I want to make Python calls from a cell phone.
Every keystroke is precious; even list comprehension is too much.
>
Is there something obvious that I'm missing?

[Warren Stringer]

RE: c[:]()

And that your

insisting on ``c[:]()`` instead of just ``c()`` seems to indicate you want
a change that is quite surprising. It would mean that a slice of a list
returns an other type with the __call__ method implemented.

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.

Grok The Zen of Python (``import this`` at the interpreter prompt)?

I think this is incredibly cool.

Write "pythonic" code?

Probably not yet; I'm still learning - I have yet to perfect my silly walk.

http://grampyshouse.net/cliches/images/sillywalk.jpg

[Warren Stringer]

RE: c[:]()

[Please quit saying "a container" if you mean lists and tuples.

"A container" is way too general. There most probably _are_
containers for which c() does not fail.]

>
One example of such a container is any folderish content in Zope:
subscripting gets you the contained pages, calling renders the default
view.

Cool. Could you point me to some example code?