On 11/05/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> I'm now even more of the opinion that this is too
> complicated for Python's first generic function system.
> "If it's hard to explain, it's probably a bad idea."
Hmm. My view is that it *is* simple to explain, but unfortunately
Phillip's explan
On 5/10/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:59 AM 5/11/2007 +1200, Greg Ewing wrote:
> >Phillip J. Eby wrote:
> >>As I said above (and in the PEP), *all* before and after methods
> >>are always called, unless an exception is raised somewhere along the way.
> >> "Before" methods
On 5/10/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > 3128 (BList) -- I'll leave this for Raymond Hettinger to review.
>
> After looking at the source, I think this has almost zero chance for replacing
> list(). There is too much value in a simple C API, low space overhead for
> small list
> Thanks for taking time to review my code.
You welcome. And thanks for the continuing development effort.
> Did you look through the PEP as well?
Yes.
> In fact, I am half way done with implementing the change so
> that small BLists are memory efficient.
As the code continues to evolve, I'l
Georg Brandl schrieb:
> This is a bit late, but it was in my queue by April 30, I swear! ;)
> Comments are appreciated, especially some phrasing sounds very clumsy
> to me, but I couldn't find a better one.
This was now accepted by Guido and checked in. Thanks for all the
comments!
Georg
___
At 09:46 AM 5/11/2007 -0400, Jim Jewett wrote:
>As much as it seems clear once you understand ... it isn't, if only
>because it is so unexpected. I think it needs an example, such as
>
> class A: ...
> class B(A): ...
>
>Then register before/after/around/normal methods for each, and show
>
At 12:05 AM 5/11/2007 -0400, Jim Jewett wrote:
>So we're mostly in agreement, but I had also wanted to leave out importString.
>
>I know it can seem simpler to treat everything as an object, and not
>worry about where the type switches from package to module to instance
>to attribute. I see it use
On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> PEP: 3124
> Title: Overloading, Generic Functions, Interfaces, and Adaptation
Ok, one more try at simplifying things. How about you just drop the sections:
"Before" and "After" Methods
"Around" Methods
Custom Combinations
As
At 10:57 AM 5/11/2007 -0600, Steven Bethard wrote:
>On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > PEP: 3124
> > Title: Overloading, Generic Functions, Interfaces, and Adaptation
>
>Ok, one more try at simplifying things. How about you just drop the sections:
>
> "Before" and "After
On 5/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:57 AM 5/11/2007 -0600, Steven Bethard wrote:
> >On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > PEP: 3124
> > > Title: Overloading, Generic Functions, Interfaces, and Adaptation
> >
> >Ok, one more try at simplifying things.
On 5/11/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:46 AM 5/11/2007 -0400, Jim Jewett wrote:
> >As much as it seems clear once you understand ... it isn't, if only
> >because it is so unexpected. I think it needs an example, such as
> > class A: ...
> > class B(A): ...
> >Then
At 01:27 PM 5/11/2007 -0400, Jim Jewett wrote:
>So how is an Around method any different than a full concrete
>implementation? Just because it has higher precedence, so it can win
>without being the most specific?
Yep.
>Could you drop the precedence stuff from the core library, and just have
>
On 5/11/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 11/05/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > I'm now even more of the opinion that this is too
> > complicated for Python's first generic function system.
> > "If it's hard to explain, it's probably a bad idea."
>
> Hmm. My view is that
On 5/11/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Newly developed code always faces an uphill battle when compared to
> mature open-source.
As it should. :-)
> End-users (everyday Python programmers) need to be understand the
> performance intuitively and have a clear understanding of wh
> I haven't used the python.org wiki before. If you point me to the
> right place put a link to a BList page, I'd be happy to create one.
> Somewhere under UsefulModules?
That would be a good place:
http://wiki.python.org/moin/UsefulModules
Raymond
__
Phillip J. Eby wrote:
> At 12:05 AM 5/11/2007 -0400, Jim Jewett wrote:
>> So we're mostly in agreement, but I had also wanted to leave out
>> importString.
>>
>> I know it can seem simpler to treat everything as an object, and not
>> worry about where the type switches from package to module to in
Phillip J. Eby wrote:
> you can register your types with other people's
> generic functions, or other people's types with your generic
> functions,
There's still a possibility of conflict even then. Fred
registers one of Mary's types with his generic function,
which he feels entitled to do becau
On 10/05/2007 3.24, Greg Ewing wrote:
>> using multiple processes cause some
>> headaches with frozen distributions (PyInstaller, py2exe, etc.), like those
>> usually found on Windows, specifically because Windows does not have fork().
>
> Isn't that just a problem with Windows generally? I don
On 10/05/2007 5.38, Josiah Carlson wrote:
>>> using multiple processes cause some
>>> headaches with frozen distributions (PyInstaller, py2exe, etc.), like those
>>> usually found on Windows, specifically because Windows does not have fork().
>> Isn't that just a problem with Windows generally?
Eric V. Smith wrote:
> Benji York wrote:
>> zope.interface also allows "lazy" imports using string versions of
>> module names in specific circumstances where circular dependencies are
>> common.
>
> Could you give an example of that? I'm familiar with zope.interface,
> but not with this featu
Daniel Stutzbach wrote:
> I actually don't think it will be that bad, since list operations go
> through one thin API. I just need to redirect the API in listobject.h
> and I'm mostly done.
Some of that API consists of macros that index directly
into the list. Currently those are O(1) and inline
Giovanni Bajo wrote:
> cygwin's fork() is mature, but I don't think it's easy to extract from
> cygwin.
> Moreover, there would be license issues since fork() is GPL. Doing another
> implementation from scratch is going to be hard.
Also it doesn't sound very efficient compared to a
real unix f
Phillip J. Eby wrote:
> At 01:27 PM 5/11/2007 -0400, Jim Jewett wrote:
>>If there are two registrations for the same selection criteria, how
>>can the user resolve things?
But what if there's *already* an @around method being
used? Then you need an @even_more_around method. Etc
ad infinitum?
--
G
23 matches
Mail list logo
