on 12/3/2006 7:54 PM Bill Janssen wrote:
>> Implementations are used to make Method Dispatching more flexible by
>> allowing a class to claim that it acts like another class/type even
>> though it is not derived from that class/type.
>
> I'm not sure just what this adds over the simple "change_
> I agree with you, but it makes it *very* difficult to write properly
> behaving cooperative super calls. In fact, if one inherits at any point
> from object, one must necessarily use the following pattern in every
> class:
>
> try:
> _method = super(cls, obj).method
> except AttributeError:
"Thomas Wouters" <[EMAIL PROTECTED]> wrote:
> On 12/6/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Thomas Wouters" <[EMAIL PROTECTED]> wrote:
> > > You forget that that's actually what super() is for. It does the right
> > thing
> > > in the case of MI (and every other case, in fact :-)
> >
On 12/6/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
"Thomas Wouters" <[EMAIL PROTECTED]> wrote:
> On 12/6/06, Jan Grant <[EMAIL PROTECTED]> wrote:
> > On Mon, 4 Dec 2006, Ben Wing wrote:
> >
> > > as a result, i imagine there's a strong urge to just hardcode the
name
> > > of the parent
> >
"Thomas Wouters" <[EMAIL PROTECTED]> wrote:
> On 12/6/06, Jan Grant <[EMAIL PROTECTED]> wrote:
> > On Mon, 4 Dec 2006, Ben Wing wrote:
> >
> > > as a result, i imagine there's a strong urge to just hardcode the name
> > > of the parent
> > ^^
> >
> > > -- super.meth(args) calls the su
> FWIW, Zope has a set of these things for sequences and mappings that
> have stood up reasonably well (done as interfaces, but same idea).
> See http://svn.zope.org/Zope3/trunk/src/zope/interface/common/ .
> Maybe that can help your effort.
Thanks, Gary. Interesting effort. I'll study i
On Dec 6, 2006, at 2:09 PM, Bill Janssen wrote:
...an argument that I appreciate, even though it mixes use cases for
implementation and documentation in a way that I personally don't
care for. That's fine.
You conclude:
> Another
> problem is that the basic Python types are somewhat poorly u
On 12/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I would also like to point out again, though, that the mechanism I've
> proposed (wrapping generic functions to create interfaces) actually
> supports (or can be made to support, using appropriate convenience
> functions) all the use cases tha
On 12/6/06, Jan Grant <[EMAIL PROTECTED]> wrote:
On Mon, 4 Dec 2006, Ben Wing wrote:
> as a result, i imagine there's a strong urge to just hardcode the name
> of the parent
^^
> -- super.meth(args) calls the superclass method `meth'
^^
Pyt
At 02:58 PM 12/6/2006 -0600, Guido van Rossum wrote:
>On 12/5/06, Phillip J. Eby <[EMAIL PROTECTED]> 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. Whi
On 12/5/06, Phillip J. Eby <[EMAIL PROTECTED]> 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'
> Compared to ABCs, interfaces can also describe contracts that can be
> fulfilled with any object--not just class instances, but classes
> themselves, and functions.
Sure, and I appreciate that. But classes and functions are both
instances of types, and thus can have extra types mixed into t
On Wed, 6 Dec 2006, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Dec 6, 2006, at 5:24 AM, Jan Grant wrote:
>
> > PS. IF generic functions (operators) could be sensitive to return types
> > and IF python6k supported a complex type inference mechanism (possibly
> >
Jan Grant <[EMAIL PROTECTED]> wrote:
> On Wed, 6 Dec 2006, Jan Grant wrote:
>
> > def foo(d: sqlDriver):
> > s = "select template goes here" % (param1, param2)
> > r = d.query(s)# do the Right Thing
>
> Suppose for a moment that % used like this returns, not a string, but an
> object th
On Dec 6, 2006, at 4:20 AM, Jan Grant wrote:
> On Mon, 4 Dec 2006, Bill Janssen wrote:
>> Jim Jewett writes:
...
>>> (1) Interfaces can be placed on a separate (presumably light-
>>> weight)
>>> inheritance hierarchy.
...
>> And I don't really
>> see how it's lighter-weight -- can you explain t
> (people who do interpolation tend to expect dynamic lexical scoping, not
> static
> object binding...)
After thinking a bit about it, you are right. Or more precisely, "inline"
interpolation with literals is mainly useful for quick-and-dirty scripts
rather than full-blown apps.
(this "quick-an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 6, 2006, at 7:04 AM, Fredrik Lundh wrote:
> btw, note that you can get the same behaviour with today's Python:
>
> s = I("some string here with ", variable, " in it")
>
Or even
s = I('some string here with $variable in it')
or some day
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 6, 2006, at 5:24 AM, Jan Grant wrote:
> PS. IF generic functions (operators) could be sensitive to return
> types
> and IF python6k supported a complex type inference mechanism (possibly
> including automatic coercion), then one might be able
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 6, 2006, at 5:02 AM, Ka-Ping Yee wrote:
I agree with where Ka-Ping is headed...
> Where does this design constraint take us?
>
> One possibility it suggests is that the interpolation function could
> be generic, allowing the formatting templat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 6, 2006, at 4:36 AM, Jan Grant wrote:
> On Mon, 4 Dec 2006, Barry Warsaw wrote:
>
>> After several years of use, I'm strongly +1 for this feature in some
>> form or another.
>
> I think it's a terrible idea in almost every form.
>
>> There shou
Antoine wrote:
> s = i"some string here with {variable} in it"
>
> The Interpolation object captures the format string, as well as a dict of
> the needed variables from the current locals and globals (here, the
> "variable").
I'm not sure I can think of a way to explain to a new Python programmer
> Or perhaps simpler, a new kind of string literal would construct an
> Interpolation object:
Hmm, so Jan proposed something similar in the meantime. Sorry for the noise.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mail
> On Wed, 6 Dec 2006, Ka-Ping Yee wrote:
> and "%" is overloadable on the basis that the return type is determined
> to be compatible with "some_type_that_signals_sql_interpolation". Those
> are some mighty big "IF"s though, and you could still concoct cases
> where things would break :-)
Or perha
Ka-Ping Yee's suggestion of overriding the interpolation builtin (or
let's say, the "%" operator used for formatting) means there might be
another way to do this using GFs: let's say that the following
illustrative snippet is still desirable -
On Wed, 6 Dec 2006, Jan Grant wrote:
> def foo(d:
On Wed, 6 Dec 2006, Ka-Ping Yee wrote:
[well-articulated point made]
Thank-you: I agree with pretty much everything you say. It's an
interesting question to ask, "can one construct a convenient
interpolation mechanism that uses the appropriate application quoting
mechanisms where necessary?"
On Wed, 6 Dec 2006, Jan Grant wrote:
[regarding string interpolation]
> I think it's a terrible idea in almost every form.
[...]
> The reason _why_ I think it's such a bad idea is the above statement
> just doesn't gel with practical experience. Google will find plenty of
> reading material if you
On Mon, 4 Dec 2006, Ben Wing wrote:
> as a result, i imagine there's a strong urge to just hardcode the name
> of the parent
^^
> -- super.meth(args) calls the superclass method `meth'
^^
Python supports multiple inheritance, unlike Java; the
On Mon, 4 Dec 2006, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Dec 4, 2006, at 5:08 AM, Ben Wing wrote:
>
> > i see in PEP 3101 that there's some work going on to fix up the string
> > formatting capabilities of python. it looks good to me but it still
> > does
On Mon, 4 Dec 2006, Bill Janssen wrote:
> Jim Jewett writes:
> > On 12/3/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > > Implementations are used to make Method Dispatching more flexible by
> > > > allowing a class to claim that it acts like another class/type even
> > > > though it is not der
29 matches
Mail list logo
