> >> c[:] holds many behaviors that change dynamically.
> >
> > I've absolutely no clue what that sentence means. If c[:] does
> > behave differently than c, then somebody's done something
> > seriously weird and probably needs to be slapped around for
> > felonious overriding.
I'm still a bit ne
Wildemar Wildenburger wrote:
> This may be a nice
> idea for the Next Overwhelming Programming Escapade (Codename: NOPE)
> ...
> You may want to elaborate on the "new way to think about names". Maybe
> you have a point which I just don't see.
Is it considered pythonic to LOL?
Nietzsche would lov
Quotes out of context with mistaken assumptions, now follow:
> So c[:]() -- or the more recent go(c)() -- executes all those
> behaviors.
>
> No it doesn't. See below.
> >
> > If c[:]() works, the so does this, using real world names
> >
> > orchestra[:].pickle()
> > orchestra[c
> > What?!? I started this thread.
> >
> No you didn't. Your original post was a reply to a message whose subject
> line was 'Re: "is" and ==', and included the header
>
> In-Reply-To: <[EMAIL PROTECTED]>
You're right, thanks.
> >> I think the fundamental mistake you have made is to convince you
> > I did not hijack another thread
>
> You really did. In the first message you sent, we see the following
> header:
>
> > In-Reply-To: <[EMAIL PROTECTED]>
...
Damn! I suck. Outlook as a newsreader sucks. I need to use something else.
> I retyped the code you posted in the first pos
_call__ create any extra indirection? If yes,
then I presume that `do(c)()` would be slower the `c[:]()`. I am writing
rather amorphous code. This may speed it up.
4) I posit yes. Am I missing something? What idiom does would c[:]() break?
This correlates with whether `c[:]()` breaks the language d
Steve Holden Wrote
> The general rule in Python is that you provide the right objects and
> expect error tracebacks if you do something wrong. So I don't really see
> why you feel it's necessary to "[be] unambiguous about using a
> container" when you don't appear to feel the same about its contain
> Warren Stringer wrote:
>
> > `c[:]()` is unambiguous because:
> >
> > def c(): print 'yo'
> >
> > c() # works, but
> > c[:]() # causes:
> >
> > Traceback (most recent call last)...
> > 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 spee
> 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
> > [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, calli
Thanks, Dakz for taking the time to reply:
> This discussion has gone in more circles than Earth has gone 'round
> the Sun, but it seems you should consider the following:
Yes, I've been feeling a bit dizzy
> 1) Sequences and functions serve fundamentally different purposes in
> Python. One is f
Gabriel wrote:
> I begin to think you are some kind of Eliza experiment with Python
> pseudo-knowledge injected.
Tell me more about your feelings that I am an Eliza experiment with Python
with pseudo knowledge injected.
Thanks for the code example.
--
http://mail.python.org/mailman/listinfo/pyt
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
>
Oops, forgot to cut and paste the point, to this:
> > - 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()
> Anyway, the code below defines a simple "callable" list; it just calls
> each contained item in turn. Don't bother to use [:], it won't work.
>
> py> class CallableList(list):
> ... def __call__(self):
> ... for item in self:
> ... item()
> ...
> py> def a(): print "a"
> ...
> py> d
> "Marc 'BlackJack' Rintsch" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> || Warren Stringer wanted to call the functions just for the side effects
> | without interest in the return values. So building a list of return
> | values which
Roland Puntaier [mailto:[EMAIL PROTECTED]
> Warren, can you please restate your point.
Hey Roland, where were you a few days ago ;-) I think most suggestions were
valid, in their own context. Only yesterday, was I finally able to get it in
perspective, so here goes:
There are two idioms: a domain
': .' means ': ...' (its an outlook thing)
--
http://mail.python.org/mailman/listinfo/python-list
Here is what I would like to do:
#
a = Tr3() # implements domain specific language
a.b = 1# this works, Tr3 overrides __getattr__
a.__dict__['b'] = 2# just so you know that b is local
a[b] = 3
Am still trying to hook a NameError exception and continue to run. After a
few more hours of searching the web and pouring over Martelli's book, the
closest I've come is:
>>> import sys
>>> def new_exit(arg=0):
... print 'new_exit called'
... #old_exit(arg)
...
>>> def hook(type, value, tb
> Yes. Python doesn't have restartable exceptions. Perhaps you would like
> to take a look at CL or Smalltalk?
>
> Jean-Paul
Hmmm, I wonder if anyone suggest to Philippe Petit, as stepped out 110
stories off the ground, that perhaps he would like to take a look at a
different tightrope?
Oddly
Alia Khouri Write
> I have been waiting for this ages and it's finally happened! Python
> meet Live, Live meet Python!
Wow. This is very cool; thanks for the announcement!
> I rushed to update http://wiki.python.org/moin/PythonInMusic but lo
Thanks for this link, as well. Very useful.
--
Josiah Carlson wrote:
> >>> foo = type(foo)(foo.func_code, d, foo.func_name, foo.func_defaults,
> foo.func_closure)
Wow! I've never seen that, before. Is there documentation for `type(n)(...)`
somewhere? I did find a very useful "Decorator for Binding Constants, by
Raymond Hettinger", that uses t
Hey Josiah,
I just spent a couple hours with your example, and it explains a lot. Some
of your interactive session got garbled, so am reposting your
merged_namespace example, with tweaks:
#-
def merged_namespace(*ns):
try:
__builti
Hi Eric,
You make a compelling argument for underscores. I sometimes help a visually
impaired friend with setting up his computers.
I'm wondering about the aural output to you second example:
link.set_parse_action(emit_link_HTML)
Does it sound like this:
link dot set under parse under action
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
oster)
...
\~/
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:python-list-
> [EMAIL PROTECTED] On Behalf Of Carsten Haese
> Sent: Wednesday, May 30, 2007 12:55 PM
> To: python-list@python.org
> Subject: Re: c[:]()
>
> On Wed, 2007-05-30 at 11:48 -0700, Warren Stringer wrote:
> &g
; [EMAIL PROTECTED] On Behalf Of Brian van den Broek
> Sent: Wednesday, May 30, 2007 3:00 PM
> To: python-list@python.org
> Subject: Re: c[:]()
>
> Warren Stringer said unto the world upon 05/30/2007 05:31 PM:
> > Hmmm, this is for neither programmer nor computer; this is f
python list.
Cheers,
\~/
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:python-list-
> [EMAIL PROTECTED] On Behalf Of Dustan
> Sent: Wednesday, May 30, 2007 4:14 PM
> To: python-list@python.org
> Subject: Re: c[:]()
>
> On May 30, 5:37 pm, "Warre
Oops! guess I should have tested my rather hasty complaint about executable
containers. This is nice:
def a(): return 'b'
def b(): print 'polly! wakey wakey'
c = {}
c['a'] = b
c[a()]() #works!
c[a()]() is a switch statement with an amorphous selector- very handy in its
own right. But, using a()
Hey Douglas,
Perhaps I was being too abstract? Here goes:
,---
| def selector():
|...
|return funcKey #get down get down
|
| def func():
|...
| funcSwitch = {}
| funcSwitch[funcKey] = func
| ...
| funcSwitch[selector()]()
even more intere
On Behalf Of Mikael Olofsson
> Sent: Thursday, May 31, 2007 1:52 AM
> To: python-list@python.org
> Subject: Re: c[:]()
>
> Warren Stringer wrote:
> > I want to call every object in a tupple, like so:
> > [snip examples]
> > Why? Because I want to make Python call
Hey Marc,
> > [d() for d in c]
>
> If you are using the list comprehension just for the side effect of
> calling `d` then consider this bad style. You are building a list of
> `None` objects just to have a "cool" one liner then.
Yep, you're right
> for func in funcs:
> func()
>
> Becaus
> >
> > But that still isn't as simple or as direct as:
> >
> > c[:]()
>
> Why do you always use a _copy_ of c in your examples? As long
> as you're wishing, why not just
>
> c()
Oh hey Grant, yes, I misunderstood your question for a bit. I thought you
meant the difference between List compr
Perhaps a foot pedal? Hmmm
My two cellphones don't like underbars very much. And the shift key -- while
much easier -- still is cumbersome. If outlook didn't autocaps on me, this
message would be in all lowercase. In fact, when communicating with friends
from outlook, to their sms, I take the
> How is it more expressive? In the context you're concerned
> with, c[:] is the exactly same thing as c. You seem to be
> worried about saving keystrokes, yet you use c[:] instead of c.
>
> It's like having an integer variable i and using ((i+0)*1)
> instead of i.
Nope, different.
c[:] holds
37 matches
Mail list logo
