Jim Jewett wrote:
>> Sorry, but that was about as informative as a "+1" vote.
>
> I found it a bit more specific on two points:
>
> What I (mis?)read was:
>
> (1)
> PJE: Interfaces rely on buyin; they end up accidentally creating
> walled gardens. Generic Functions make fewer demands, so they st
I will make only one more comment and then ill drop my comments
without direct questions.
On 11/25/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Hm. The double colon rubs me the wrong way (Perl and/or C++). But
> apart from that, if this is the solution, I'm not sure the problem
> you're tryin
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/22/06, Jonathan LaCour <[EMAIL PROTECTED]> wrote:
> > Phillip J. Eby wrote:
> > > In essence, interfaces turn libraries into "frameworks", but generic
> > > functions turn frameworks into libraries. I didn't really discover
> > > th
On 11/23/06, Dave Anderson <[EMAIL PROTECTED]> wrote:
> Interfaces
> ==
> iter_interface = interface(iter) # class-based interface
> file_open_close_inter = interface(file.open, file.close) # method interface
[ strings were also treated differently ]
Are you keying off the dot in the nam
At 07:03 PM 11/25/2006 -0500, Jim Jewett wrote:
>I had thought that you (Bill), (along with PJE) were assuming that the
>generic function or interface itself would serve to distinguish the
>namespace. Instead of
>
> class A(object):
> def magic_meth_foo(self, ...):
>
>I would write
>
>
Jim Jewett wrote:
> There isn't usually any need for a third namespace, unless you are
> using another huge framework, such as Zope or Peak.
Even then, there isn't a problem unless you want to
multiply inherit from two classes that clash. I can't
remember ever encountering such a problem with
__s
On 11/22/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > yeah, namespaces are such a useless thing. let's put everything in one
> > big flat namespace, so we don't have to wonder where things are.
> Pardon me? That's what we've got now, isn't it? That's why we have
> to do that ugly and hard-to
> "contract" is a better term, IMO, since it's already used in CS (as in
> Eiffel), and describes the situation more correctly: *behavior* rather
> than *signature*.
> "ability" just doesn't seem right to me: my class is not *able* to be a
> set,
> it *behaves* like a set. it follows the set contra
"Kay Schluehr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Seems like we need more formal procedures for writing test than
> application code. This also solves the problem of expense of
> "verification" of typeclasses/concepts/abilities that need to be done
> just once for a cla
Le samedi 25 novembre 2006 à 21:32 +0200, tomer filiba a écrit :
> "contract" is a better term, IMO, since it's already used in CS (as in
> Eiffel),
> and describes the situation more correctly: *behavior* rather than
> *signature*.
> "ability" just doesn't seem right to me: my class is not *abl
i'd suggest using the term "contract" instead of abilities or interfaces.
they way BDFL described it [1], abilities specify more than mere method
signatures -- they go as deep as how the implementation should implement
the desired behavior.
http://mail.python.org/pipermail/python-3000/2006-Novembe
Greg Ewing schrieb:
>Gustavo Niemeyer wrote:
>
>
>>Are you arguing that
>>pretty much every approach being discussed is bad and
>>we should instead implement something magically
>>transforming types?
>>
>>
>
>No, I'm questioning the need to do anything at all.
>I don't see a big problem that
12 matches
Mail list logo
