Greg Ewing wrote:
> Talin wrote:
>> A different approach would be to say that the class decorator can
>> overload the '__setattr__' method on the class itself during class
>> creation:
>
> But it doesn't work that way -- class attributes don't
> go through __setattr__ during class creation. They
Greg Ewing wrote:
> Talin wrote:
>
>> From my point of view, both 'with' and generator expressions are
>> limited, special-case solutions to a general problem - the desire to
>> be able to use and manipulate unnamed blocks of code as first-class
>> objects.
>
> I don't think it's as simple as
Talin wrote:
> I expect to see a series of special-case syntactical work-arounds that
> compensate for the lack of such a feature.
yeah, because the "special-case syntactical work-arounds" are care-
fully designed to be *usable* for a well-defined group of *practical*
problems. it's about HCI,
On 11/17/06, Talin <[EMAIL PROTECTED]> wrote:
> # Create a callback timer
> alarm = Timer()
> alarm.SetDuration( 100, Timer.Milliseconds )
>
> upon alarm:
>print "It's time to get up, silly-head!"
>
> print "Alarm has been set!"
Why invent a new special case syntax - t
Phillip J. Eby wrote:
> Only the discussion several months ago, where I tried to show that you
> could treat all functions as extensible, by using extensible functions to
> define them.
/snip many useful references/
thanks. more than enough to keep me busy over the weekend ;-)
has anyone loo
Fredrik Lundh wrote:
> Talin wrote:
>
>> I expect to see a series of special-case syntactical work-arounds that
>> compensate for the lack of such a feature.
>
> yeah, because the "special-case syntactical work-arounds" are care-
> fully designed to be *usable* for a well-defined group of *pract
> However, this special-case approach is flawed in this example, because
> its use is so narrow. If you think about it for a minute, you
> immediately start to imagine all of the things that 'upon' ought to deal
> with that it doesn't.
> For example, it has no way to deal with error
> callbacks;
A
Hi,
George Sakkis wrote:
> On 11/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Are you going to propose similar
>> changes for all standard de-facto interfaces, like sequences,
>> mappings, files etc.?
>
> No, I won't (at least not for now ;-)). Notice however that most
> user-defined seq
Talin wrote:
> Greg Ewing wrote:
>> Talin wrote:
>>> A different approach would be to say that the class decorator can
>>> overload the '__setattr__' method on the class itself during class
>>> creation:
>> But it doesn't work that way -- class attributes don't
>> go through __setattr__ during cl
Antoine wrote:
>> However, this special-case approach is flawed in this example, because
>> its use is so narrow. If you think about it for a minute, you
>> immediately start to imagine all of the things that 'upon' ought to deal
>> with that it doesn't.
>> For example, it has no way to deal with e
"Talin" wrote:
> Hmmm, a single syntax that handles both async callbacks, async errors,
> and switch/case constructs...maybe this would be more useful than I
> thought ... :)
done much BASIC programming lately ?
___
Python-3000 mailing list
Python
On 11/17/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
>
> > Only the discussion several months ago, where I tried to show that you
> > could treat all functions as extensible, by using extensible functions to
> > define them.
>
> /snip many useful references/
>
> thanks. mo
- Forwarded message from Antti Louko <[EMAIL PROTECTED]> -
Date: Fri, 17 Nov 2006 08:25:03 +0200
From: Antti Louko <[EMAIL PROTECTED]>
Subject: Python bytes object
To: [EMAIL PROTECTED]
Python bytes object is useful.
I would add bitwise logical operations. They would be most useful in
cr
Fredrik Lundh wrote:
> it's about HCI, not CS.
+1 QOTF.
Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.p
Sounds good to me -- I don't have this need myself but it seems to fit
well. I'm looking forward to a patch. :-)
On 11/17/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> - Forwarded message from Antti Louko <[EMAIL PROTECTED]> -
>
> Date: Fri, 17 Nov 2006 08:25:03 +0200
> From: Antti Lo
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> *To me* you have this backwards. The function-object creation code is
> executed *before* the call that passes that object. This is true whether
> it is placed before, as above, or nested within, as you and Tomer pref
On 11/16/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> but here's some abuse that I couldn't help chuckling
> over. No need to even bother constructing a class, but don't forget that
> 'return locals()' at the end! (not that I'm advocating its [ab]use,
> just something that made me smile)
>
> -
Greg Ewing wrote:
> George Sakkis wrote:
>
> > And for two, not everyone feels comfortable with duck typing. People
> > who consider (for better or for worse) isinstance() safer than
> > hasattr()/getattr() would be accomodated too.
>
> The trouble is that building things into the core to
> "acco
Fredrik Lundh wrote:
> Talin wrote:
>
>> I expect to see a series of special-case syntactical work-arounds that
>> compensate for the lack of such a feature.
>
> yeah, because the "special-case syntactical work-arounds" are care-
> fully designed to be *usable* for a well-defined group of *pract
On 11/17/06, Talin <[EMAIL PROTECTED]> wrote:
Fredrik Lundh wrote:
> Talin wrote:
>
>> I expect to see a series of special-case syntactical work-arounds that
>> compensate for the lack of such a feature.
>
> yeah, because the "special-case syntactical work-arounds" are care-
> fully designed to
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> Sounds good to me -- I don't have this need myself but it seems to fit
> well. I'm looking forward to a patch. :-)
If I remember correctly, 2.5 was supposed to have binascii.long2b() and
binascii.b2long() which would have converted a long integer t
Steven Bethard wrote:
> Of course, this is almost exactly what the class statement does under
> the covers.
That 'almost' you have there covers some pretty significant differences though.
> The important points in the code above are the ``MAKE_FUNCTION`` and
> ``CALL_FUNCTION`` from the class sta
Bill Janssen wrote:
> The use of standard base types (interfaces)
> is basically a communications mechanism that lets functionality
> designers easily tell users of their functionality what's needed.
But it's a blunt tool, because it arbitrarily lumps
together sets of functionality that often are
Talin wrote:
> How is it that
> people are so hostile to something that I, and apparently others, find
> so useful?
I don't think it's hostility so much as a weary feeling
that this discussion is revisiting something that's been
hashed over many times before with no satisfactory
result.
If ther
Talin wrote:
> Hmmm, a single syntax that handles both async callbacks, async errors,
> and switch/case constructs...maybe this would be more useful than I
> thought ... :)
>
> Now, can we figure out how to handle arguments to the code block...?
PEP 343 already gives you an answer to this quest
Greg Ewing writes:
> > Checking for some textual attributes of a
> > type
>
> Now you're talking about LYBL, which is generally
> considered an anti-pattern in Python. APIs should
> be designed so that you don't need to test for the
> presence of features.
So you join me in wanting to make the us
26 matches
Mail list logo
