Talin wrote:
> Phillip J. Eby wrote:
>> At 09:59 AM 12/5/2006 -0600, Guido van Rossum wrote:
>>> My point is that an interface can *document* (at least in English) a
>>> "contract" about the invariants between operations. While I'm not into
>>> enforcing or verifying such contracts, I'm very intere
Jim Jewett wrote:
> On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
>> While this is more verbose than sticking an 'if' into the original
>> sendmail(), note that it can also be added by a third party, via:
>
>> overload smtpblib.SMTP.sendmail(
>> self, from_addr, to_addrs:
Collin Winter wrote:
> On 8/15/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
>> On 8/15/06, Collin Winter <[EMAIL PROTECTED]> wrote:
>>> 1) Static analysis tools (pychecker, optimising compilers, etc) must
>>> be able to use the annotations
>> As in any example given so far, the annotations would
The more examples I see of the 'py' and 'site' top level namespaces, the
less I like them. Let's dispose of 'site' first; it's been common to
show examples like:
from gui import wx
However, wx currently, and presumably for the forseeable future, lives
in site packages, so we'd actually h
Barry Warsaw wrote:
> On Thu, 2006-04-27 at 10:08 -0700, Aahz wrote:
>> -0
>>
>>
>>While I hate the way it looks, I never have gotten mixed up about the
>>order of arguments since switching to ''.join(l).
Me too on all counts including the -0.
>
>
> Which is why
>
> EMPTYSTRING = ''
>
> ..
Let me update my original thought experiment in a way that (I think)
preserves the current behaviour while also requiring strict dominance.
Let's imagine for a second that we have two new types at the top of the
hierarchy. I'll call them Ultimate and Penultimate. So the inheritance
tree goes l
Here's a little thought experiment:
What would happen if 'a+b' was just syntactic sugar for
'operator.add(a,b)', where operator.add was a generic
function, instead of the current magic dance involving
__add__ and __radd__.
Neglecting the fact that it would break all Python co
This is just a little update on my rewrite of pprint. I've continued to
clean up and optimize this. If anyone wants to look at it, I've updated
the code here:
http://members.cox.net/~tim.hochberg/pprint2.py
[The changes are probably not signifigant enough to justify another
posting of t
Guido van Rossum wrote:
> On 4/10/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
>
>>On 4/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>
>>>A completely separate issue is what kind of objects Seq, Index and
>>>Text would be; but that's a discussion we have separate from the
>>>syntactic discussi
Guido van Rossum wrote:
> On 4/10/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
>
>>Every so often Guido talks about adding optional typing to python.
>>
>>Adaptation may offer the cleanest way to do this.
>>
>>
>>Turning
>>
>>def fn(a, b, c="default"): ...
>>
>>into any of
>>
>>def fn(Seq a,
Guido van Rossum wrote:
> On 4/9/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
>>Rather than having you scroll all through this long message/file, I'll instead
>>place all the examples up here at the top. Assuming that you save this as
>>pprint2.py, you should
Guido van Rossum wrote:
> On 4/8/06, Talin <[EMAIL PROTECTED]> wrote:
>
>>You know, on the one hand, I've been reading this thread, and I'm
>>excited about the possibility of generic functions (dynamic dispatch,
>>duckaplex-typing, whatever you want to call it), but at the same time
>>I kind of wo
"""This is my attempt to rewrite pprint.py to be based on protocols. Or
overloading or specialization or whatever they end up being called ;-). My
first attempt only touched about 20 lines of the original pprint and
probably
had 90% of the usability gain that this one does, but for some reason I
Walter Dörwald wrote:
>Guido van Rossum wrote:
>
>
>
>>On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>
>>
>>>But might closes off one route we could take if we're adapting to
>>>something that must provide more than one function/method (i.e. an
>>>interface) and we'd like to have the
Nick Coghlan wrote:
> One issue with generic functions and adaptation as currently being discussed
> (and something Tim mentioned a while back), it that it is very focused on
> dispatching based solely on obj.__class__.__mro__.
>
> That's all well and good, but (to use an example of Tim's), supp
Walter Dörwald wrote:
> Guido van Rossum wrote:
>
>
>>On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>
>>>The problem with this is that it looks in the base protocol only if the
>>>the class can't be found in the registry of the subprotocol. This mean
>>>that an adapter from the subprotoco
Guido van Rossum wrote:
[TAHs simple pprint customization example snipped]
>>
>>Nice!
>>
>>I expect that with another dozen lines of code I could make custom
>>pretty printers possible, although the way the customization happens
>>might be a little kludgy. I'll look into it.
>
>
> Neat indeed.
Walter Dörwald wrote:
> Guido van Rossum wrote:
>
>> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>
>>> Guido van Rossum wrote:
>>>
>>>> On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>>>>
>>>>>
Guido van Rossum wrote:
>On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
>
>>Walter Dörwald wrote:
>>
>>
>>>What's still missing IMHO is a way for an adapter to defer to the next
>>>adapter in the chain, i.e. something like:
&g
Walter Dörwald wrote:
> Guido van Rossum wrote:
>
>> Fascinating ideas in this thread!
>>
>> I spent some time blogging about this on artima:
>> http://www.artima.com/weblogs/viewpost.jsp?thread=155123
>>
>> I have to write my slides for a talk about Py3K later today, but I'll
>> be back. In the m
Ian Bicking wrote:
> Alex Martelli wrote:
>
>>As for the % operator, I never liked it -- either a builtin function,
>>or even better a method of string objects, is going to be much more
>>readable (and my preference would be to have it take optional
>>positional arguments, corresponding to {
Nick Coghlan wrote:
> Tim Hochberg wrote:
>
>>I like this version. The naming seems an improvement and the
>>default_adapter seems like a worthy addition. I do keep wondering if
>>there's some reason for a user of Protocol to call candidate_keys
>>directly or
Nick Coghlan wrote:
> Tim Hochberg wrote:
>
>>So after all of that, I think my conclusion is that I wouldn't refactor
>>this at all, at least not yet. I'd add support for multiple registration
>>and possibly spell adapt as __call__, otherwise I'd leave it
Guido van Rossum wrote:
> #!/usr/bin/python2.4
>
> """An example of generic functions vs. adaptation.
>
> After some face-to-face discussions with Alex I'm presenting here two
> extremely simplified implementations of second-generation adaptation
> and generic functions, in order to contrast and
Guido van Rossum wrote:
>On 4/4/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
>(Could you not change the subject each time? Or if you do, could you
>assume the reader hasn't necessarily read your previous posts? For
>gmail users like me, each subject change start
Considering generic function in combination adaption led to one more
small change in the Protocol implementation that I'm playing with, and
all of the sudden I'm left with something that I could actually use.
What I realized was that you could factor out the part that potentially
has a lot of
Phillip J. Eby wrote:
> At 11:03 PM 4/3/2006, Ian Bicking wrote:
>
>>Guido van Rossum wrote:
>>
>>>On 4/3/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
>>>
As an alternative to adaptation, I'd like to propose generic functions.
I think they play much the same role, except they are much simp
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>
>>In this case, it makes far more sense to me to move the adapter
>>registration out to the individual protocols.
>
>
> That would alleviate some of my concerns as well. This
> seems more Pythonic: Namespaces are one honking... etc.
>
>
>>In a glor
Michael Chermside wrote:
>Tim Hochberg writes:
>
>
>>In this thread, Alex has been advocating adaption where types are
>>adapted to protocols: T->P adaption for short. By contrast, my two
>>sample implementations have involved Protocol->Protocol adaptio
Nick Coghlan wrote:
[SNIP]
>
> Tim Hochberg wrote:
>
>>In this thread, Alex has been advocating adaption where types are
>>adapted to protocols: T->P adaption for short. By contrast, my two
>>sample implementations have involved Protocol->Protocol adaption
Talin wrote:
[...]
> For example, the suggestion of testing each member of a module with
> "is_module" is fine - except that a newbie programmer's first attempt to
> write "is_module" is probably going to be "isinstance( value, module )"
> which won't work because the word "module" isn't bound to
7;ll include the module docstring below.
Regards,
-tim
"""adaption -- the worlds fourth most naive implementation of adaption
Based on some post one python-dev-3000 on April 1st, 2006. Alex
Martelli's being
one of the main ones. Idiocies are all atributable to me (Tim Hochberg)
In this thread, Alex has been advocating adaption where types are
adapted to protocols: T->P adaption for short. By contrast, my two
sample implementations have involved Protocol->Protocol adaption where
objects that implement a certain protocol are adapted to another
protocol: P->P adaption f
Talin wrote:
> Just a few things that have wanted while doing python
> programming. Maybe some of these are already doable
> or are already on someone's wish list...
Some of these are already pretty easy to do. Perhaps you should
explain what's inadequate about the current solutions. For
example:
Alex Martelli wrote:
[SNIP a bunch or erudite stuff.]
>
>
> Here is a simple reference implementation of adaptation under all of
> these simplifying assumptions:
>
> _global_registry = {}
>
> def register_adapter(T, P, A, registry=_global_registry):
> registry[T, P] = A
>
> def adapt(t
Benji York wrote:
> Aahz wrote:
>
>>On Fri, Mar 31, 2006, Alex Martelli wrote:
>>
>>
>>>Once in a while, I'm moved to sing this refrain again, but thanks to
>>>the ensuing discussion I'm soon reminded that there are many more
>>>gratifying activities I could pursue instead -- repeated beating
36 matches
Mail list logo
