Re: [Python-3000] Two proposals for a new list-like type: one modest, one radical

[Raymond Hettinger on treelist being added to the collections module] >> In practice, the code for BList is somewhat complex, and its desirability >> and performance in actual applications is unproven. >> Fortunately, Py2.6 is still a long way off. My recommendation is that you >> release it righ

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Jeffrey, is there any way you can drop the top of the tree and going > straight from Number to Complex -> Real -> Rational -> Integer? These > are the things that everyone with high school math will know. Backing up a bit, what kinds of typ

Re: [Python-3000] Generic function PEP won't make it in time

At 08:49 PM 4/25/2007 -0700, Guido van Rossum wrote: >Then how do you explain the popularity of zope.interfaces in both the >Zope and the Twisted world? In a word: adaptation. (Caveat: it's been a while since I looked at very much of Twisted, and even longer for Zope; but ISTR that Twisted hardl

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Wed, 25 Apr 2007 20:40:14 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> > wrote: > >At 06:40 PM 4/25/2007 -0400, Jean-Paul Calderone wrote: > >>On Wed, 25 Apr 2007 18:10:23 -0400, Jim Jewett <[EMAIL PROTECTED]> > >>wrote: > >> >The curr

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote: > Sure. Below is a slightly modified example from the doctest: > > >>> class AbstractCar(AbstractBaseClass): # inherit from AbstractBaseClass > to make something abstract > ... @Abstract > ... def Drive(self,x): pass > >

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > From the PEP, it seems there are two purposes for > these proposed ABCs: > > 1) To document what is meant when we say that something > is a "sequence", "mapping", etc. > > This could be done simply by writing documentation. There > is no need for

Re: [Python-3000] Generic function PEP won't make it in time

References to __call__ in my post should have been to __init__. Apologies for the error. -Emin On 4/25/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote: On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I'm confused. Can you show a simple example of something that can be

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Greg Ewing <[EMAIL PROTECTED]> wrote: Emin.shopper Martinian.shopper wrote: > If you believe that there exist data structures or algorithms where a > meaningful unit test takes many minutes or hours, I wouldn't be worried about spending minutes to save hours later. OK, but I wou

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: I'm confused. Can you show a simple example of something that can be checked at definition time? Sure. Below is a slightly modified example from the doctest: class AbstractCar(AbstractBaseClass): # inherit from AbstractBaseClass to ma

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On Wed, 25 Apr 2007 20:40:14 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >At 06:40 PM 4/25/2007 -0400, Jean-Paul Calderone wrote: >>On Wed, 25 Apr 2007 18:10:23 -0400, Jim Jewett <[EMAIL PROTECTED]> >>wrote: >> >The current ABC proposal is to use isinstance as the test; Jeffrey >> >Yaskin's

Re: [Python-3000] Generic function PEP won't make it in time

Emin.shopper Martinian.shopper wrote: > If you believe that there exist data structures or algorithms where a > meaningful unit test takes many minutes or hours, I wouldn't be worried about spending minutes to save hours later. As for unit tests taking hours -- I'm skeptical. Do you know of alg

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

Jeffrey Yasskin wrote: > If you write a function that can take > an arbitrary ring, it should Just Work on a python int, or any other > Complex subclass, There's no reason it shouldn't "just work", unless it's being anal and trying to make sure it's been given things of what it considers to be the

Re: [Python-3000] Generic function PEP won't make it in time

Paul Moore wrote: > My point was that as far as I am aware, > Guido's current position on ABCs is that they are, and will remain, > optional - people like myself (and Greg, from the sound of it) who > don't want to derive from ABCs will not be penalised by being excluded > from anything in the Pyth

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 04:43 PM 4/25/2007 -0700, Guido van Rossum wrote: > >This is a very good point. Perhaps we can come up with a way to make > >isinstance and issubclass into something like GFs (without requiring > >the whole GF machinery). > > > >I'll think

Re: [Python-3000] Generic function PEP won't make it in time

Emin.shopper Martinian.shopper wrote: > Imagine you have a program that takes a long time to run. If you use > duck-typing or similar ideas you may watch the program run for hours or > days and then raise an AttributeError or NotImplemented error because a > derived class didn't implement a req

Re: [Python-3000] Generic function PEP won't make it in time

Paul Moore wrote: > OTOH, in Greg's case maybe he should just not bother inheriting from > the ABC. From what I hear, that shouldn't cause him any problems > ("duck typing isn't going away" is the message I've heard). Of course, > it's difficult to be sure without specific examples (on either side

Re: [Python-3000] ABC PEP -- dropping set.clear

On 4/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 4/25/07, guido.van.rossum <[EMAIL PROTECTED]> wrote: > > +implementation.) **Open issues:** Forcing every mutable set > > +to implement this may be a pain for such a fairly > > +non-essential method. Perhaps just drop

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

At 06:40 PM 4/25/2007 -0400, Jean-Paul Calderone wrote: >On Wed, 25 Apr 2007 18:10:23 -0400, Jim Jewett <[EMAIL PROTECTED]> wrote: > >The current ABC proposal is to use isinstance as the test; Jeffrey > >Yaskin's numbers PEP highlighted the weakness there with a concrete > >example. > > > >If you n

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

At 04:43 PM 4/25/2007 -0700, Guido van Rossum wrote: >This is a very good point. Perhaps we can come up with a way to make >isinstance and issubclass into something like GFs (without requiring >the whole GF machinery). > >I'll think about it some more. __special__ methods are how Python currently

[Python-3000] ABC PEP -- dropping set.clear

On 4/25/07, guido.van.rossum <[EMAIL PROTECTED]> wrote: > +implementation.) **Open issues:** Forcing every mutable set > +to implement this may be a pain for such a fairly > +non-essential method. Perhaps just drop it? There are also comments worrying that an abstract imp

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

At 06:10 PM 4/25/2007 -0400, Jim Jewett wrote: >I suspect Phillip will say that we really need to make the ABCs >generic functions... Nope; they're *already* generic functions: hash(), len(), iter(), various operator.* functions, and I believe we're adding next(). I've got nothing to add to tha

Re: [Python-3000] Need help completing ABC pep

On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/21/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > [PEP 3119] > > > > * "Should we also implement the issubset and issuperset methods found > > > > on the set type in Python 2? As these are just aliases for __le__ and > > > > __ge__, I'm te

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

This is a very good point. Perhaps we can come up with a way to make isinstance and issubclass into something like GFs (without requiring the whole GF machinery). I'll think about it some more. --Guido On 4/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > The current ABC proposal is to use isinsta

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > I'm sure everyone is already aware of the behavior of the classImplements > and directlyProvides functions available in zope.interface, which exactly > satisfy this use-case in the interface world. Don't be so sure; I wasn't (aware, that

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote: > On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > IIUC, Emin's framework requires you to explicitly declare any class as > > abstract that has abstract methods. > > I believe that is an easily fixable implementation

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > ... If we insist that built-in types are immutable ... They > could write things like > class MyFloat(float, DivisionRing): pass > but this would be fairly painful. Worse than that once you get 3rd parties involved. try: from gmpy im

Re: [Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On Wed, 25 Apr 2007 18:10:23 -0400, Jim Jewett <[EMAIL PROTECTED]> wrote: >The current ABC proposal is to use isinstance as the test; Jeffrey >Yaskin's numbers PEP highlighted the weakness there with a concrete >example. > >If you need to an abstraction less powerful than an existing ABC, >you're o

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Jim Jewett <[EMAIL PROTECTED]> wrote: On 4/25/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote: > I think a bigger issue is whether to check at definition time or check at > instantiation time. It seems to me the former has the benefit of catching > errors earlier and po

Re: [Python-3000] Need help completing ABC pep

(Forgot to answer this promptly.) On 4/21/07, Jim Jewett <[EMAIL PROTECTED]> wrote: [PEP 3119] > > > * "Should we also implement the issubset and issuperset methods found > > > on the set type in Python 2? As these are just aliases for __le__ and > > > __ge__, I'm tempted to leave these out." [Bre

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote: > I think a bigger issue is whether to check at definition time or check at > instantiation time. It seems to me the former has the benefit of catching > errors earlier and potentially saving time. I don't immediately see the >

[Python-3000] ABC PEP isinstance issue Was: PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

The current ABC proposal is to use isinstance as the test; Jeffrey Yaskin's numbers PEP highlighted the weakness there with a concrete example. If you need to an abstraction less powerful than an existing ABC, you're out of luck; you can't just assert that the existing class is already sufficient,

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: IIUC, Emin's framework requires you to explicitly declare any class as abstract that has abstract methods. I believe that is an easily fixable implementation issue, which I would be happy to remedy. I think a bigger issue is whether to

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > class MonoidUnderPlus(Abstract): Is this useful? Just because two things are both Monoid instances doesn't mean I can add them -- they have to be part of the same Monoid. By the time you do assert isinstance(a, MonoidUnderPlus)

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > "Emin.shopper Martinian.shopper" <[EMAIL PROTECTED]> wrote: > > On 4/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > > If your unit tests take hours to run, then you aren't going to get > > > anything useful from the ABC requirements for

Re: [Python-3000] Generic function PEP won't make it in time

"Emin.shopper Martinian.shopper" <[EMAIL PROTECTED]> wrote: > On 4/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > If your unit tests take hours to run, then you aren't going to get > > anything useful from the ABC requirements for hours either (unless you > > are pre-instantiating everything

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: > On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Jeffrey, is there any way you can drop the top of the tree and going > > straight from Number to Complex -> Real -> Rational -> Integer? These > > are the things that everyone with h

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: If your unit tests take hours to run, then you aren't going to get anything useful from the ABC requirements for hours either (unless you are pre-instantiating everything you are going to use during program execution, in which case this coul

Re: [Python-3000] Fixing super anyone?

From: "Guido van Rossum" <[EMAIL PROTECTED]> > class E(D): pass > > print E().f() > > This prints DDBCA which surely isn't right. > > Sounds like the classic bug in such attempts. Yep - missing overridden methods tend to either do the above, or end up in infinite recursion. My bytecode hacking v

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Paul Moore <[EMAIL PROTECTED]> wrote: > On 25/04/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote: > > I disagree. I think that B&D-ish enforcement of ABCs is the most important > > feature of an ABC (with the option of being able to turn off enforcement on > > a per-class b

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Jeffrey, is there any way you can drop the top of the tree and going > straight from Number to Complex -> Real -> Rational -> Integer? These > are the things that everyone with high school math will know. I think yes, if you can confirm tha

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > Please remember that this isn't about Java style type checking and > verification during compilation. This is, strictly speaking, ABC > checking on object instantiation, method invocation, and possibly even > argument verification. This isn

Re: [Python-3000] Generic function PEP won't make it in time

"Emin.shopper Martinian.shopper" <[EMAIL PROTECTED]> wrote: > On 4/25/07, Calvin Spealman <[EMAIL PROTECTED]> wrote: > > > > It sounds like you just need better unit tests. > > Only if you believe you can unit test everything within a few seconds. If > you believe that there exist data structures

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Calvin Spealman <[EMAIL PROTECTED]> wrote: It sounds like you just need better unit tests. Only if you believe you can unit test everything within a few seconds. If you believe that there exist data structures or algorithms where a meaningful unit test takes many minutes or hours,

Re: [Python-3000] Suggested PEP 3108 addition

On 4/25/07, Collin Winter <[EMAIL PROTECTED]> wrote: > I'd like to propose that the bsddb185 module be added to PEP 3108's > list of modules slated for removal. Reasons to kill it: > > - The module isn't built by default; manual tweaking of setup.py is required. > > - The following scare-paragraph

Re: [Python-3000] Two proposals for a new list-like type: one modest, one radical

On 4/25/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote: > On 4/25/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > In practice, the code for BList is somewhat complex, and its desirability > > and performance in actual applications is unproven. > > Fortunately, Py2.6 is still a long way off. M

Re: [Python-3000] Fixing super anyone?

On 4/24/07, Steven Bethard <[EMAIL PROTECTED]> wrote: > class Super(object): > def __init__(self, type, obj=None): > if isinstance(obj, Super): > obj = obj.__obj__ > self.__type__ = type > self.__obj__ = obj > def __get__(self, obj, cls=None): > i

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Collin Winter <[EMAIL PROTECTED]> wrote: > The following things mean absolutely nothing to me: > > - Monoid > - MonoidUnderPlus > - Group > - Ring > - Semiring > - Field > > So, most of the terminology in the PEP. > > I can see use-cases for this level of formalism, but I'm a strong -1

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

Josiah Carlson wrote: > I really do understand wanting to be able to ask "is operation X > supported for values Y and Z", but is this really necessary for numbers? It's not required for ordinary people who deal with ints and floats. Python is pushing into the scientific market. The math guys need

Re: [Python-3000] Generic function PEP won't make it in time

On 4/25/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote: > I disagree. I think that B&D-ish enforcement of ABCs is the most important > feature of an ABC (with the option of being able to turn off enforcement on > a per-class basis). > > Imagine you have a program that takes a long tim

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

On 4/25/07, Collin Winter <[EMAIL PROTECTED]> wrote: > I can see use-cases for this level of formalism, but I'm a strong -1 > on making any part of the stdlib effectively off-limits for people > without advanced math degrees. Why can't this be shipped as a > third-party module? I agree. That last

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

[bcc'ing numpy-discussion. Comments should probably try to stay on the python-3000 list.] On 4/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > Are the base number operations in Python all that difficult to > understand? Do we really need to add mathematical formalism into > Python's type syste

[Python-3000] Suggested PEP 3108 addition

I'd like to propose that the bsddb185 module be added to PEP 3108's list of modules slated for removal. Reasons to kill it: - The module isn't built by default; manual tweaking of setup.py is required. - The following scare-paragraph is included at the bottom of http://docs.python.org/lib/module-

Re: [Python-3000] Two proposals for a new list-like type: one modest, one radical

On 4/25/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > In practice, the code for BList is somewhat complex, and its desirability and > performance in actual applications is unproven. > Fortunately, Py2.6 is still a long way off. My recommendation is that you > release it right away as a third

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

The following things mean absolutely nothing to me: - Monoid - MonoidUnderPlus - Group - Ring - Semiring - Field So, most of the terminology in the PEP. I can see use-cases for this level of formalism, but I'm a strong -1 on making any part of the stdlib effectively off-limits for people without

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

[bcc'ing numpy-discussion. Comments should probably try to stay on the python-3000 list.] On 4/25/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > Are the base number operations in Python all that difficult to > understand? Do we really need to add mathematical formalism into > Python's type syste

Re: [Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

"Jeffrey Yasskin" <[EMAIL PROTECTED]> wrote: > Here's a draft of the numbers ABCs PEP. The most up to date version > will live in the darcs repository at > http://jeffrey.yasskin.info/darcs/PEPs/pep-3141.txt (unless the number > changes) for now. Naming a PEP about numbers 3.141 seems cute, but of

Re: [Python-3000] An introduction to ABC's

Emin.shopper Martinian.shopper wrote: > On 4/25/07, *Neal Norwitz* <[EMAIL PROTECTED] > > wrote: > > You can get similar functionality by using tools such as pychecker. > PyLint and pyflakes may also have this functionality. > > > I like PyLint and pychecker a lot

Re: [Python-3000] Fixing super anyone? (redux)

> But I haven't figured out how to do that yet... It turns out to be easier than I thought, and it avoids changing the object __class__, which is ugly. class _super(property): def __init__(self): property.__init__(self, self.get_super, None, None) def get_sup

Re: [Python-3000] Generic function PEP won't make it in time

On 25/04/07, Emin.shopper Martinian.shopper <[EMAIL PROTECTED]> wrote: > I disagree. I think that B&D-ish enforcement of ABCs is the most important > feature of an ABC (with the option of being able to turn off enforcement on > a per-class basis). OK. We can agree to disagree. My point was that as

Re: [Python-3000] Fixing super anyone?

I mucked around with this, and here is my version: class _super(property): def __init__(self): property.__init__(self, self.get_super, None, None) def get_super(self, klass): def dong(obj): class wrapper: def _

Re: [Python-3000] Fixing super anyone?

On 4/25/07, Calvin Spealman <[EMAIL PROTECTED]> wrote: > Jim, you said you'd take a crack "if no one else volunteers", so > perhaps I will, if you didn't have your heart set on it. I would like > more opportunities to contribute and this wouldn't be a terribly long > PEP for my first foray into wri

Re: [Python-3000] An introduction to ABC's

On 4/25/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: You can get similar functionality by using tools such as pychecker. PyLint and pyflakes may also have this functionality. I like PyLint and pychecker a lot, but the funtionality is not similar. Both take a lot longer to run (at least longer

Re: [Python-3000] Generic function PEP won't make it in time

I disagree. I think that B&D-ish enforcement of ABCs is the most important feature of an ABC (with the option of being able to turn off enforcement on a per-class basis). Imagine you have a program that takes a long time to run. If you use duck-typing or similar ideas you may watch the program ru

Re: [Python-3000] Fixing super anyone?

On 4/25/07, Steven Bethard <[EMAIL PROTECTED]> wrote: > On 4/24/07, Steven Bethard <[EMAIL PROTECTED]> wrote: > > On 4/24/07, Calvin Spealman <[EMAIL PROTECTED]> wrote: > > > I must have miscopied then because it worked perfectly here. Yes, I > > > meant to have the _superdesc defined inside the me

[Python-3000] PEP 31XX: A Type Hierarchy for Numbers (and other algebraic entities)

Here's a draft of the numbers ABCs PEP. The most up to date version will live in the darcs repository at http://jeffrey.yasskin.info/darcs/PEPs/pep-3141.txt (unless the number changes) for now. Naming a PEP about numbers 3.141 seems cute, but of course, I don't get to pick the number. :) This is my

Re: [Python-3000] Generic function PEP won't make it in time

On 25/04/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Do we really need to have B&D-ish enforcement of abstract > method implementation? It doesn't seem pythonic to me. > I might want to leave some methods of an ABC unimplemented > because I'm not intending to use them. I'd be annoyed if > I were pr