Mailman 3 July 2004 - Python-Dev

RE: [Python-Dev] decimal API
by mcherm2＠mcherm.com July 6, 2004

July 6, 2004

Facundo writes: > I'm +1 to enable some by default: DivisionByZero, DivisionUndefined, > Overflow, InvalidOperation, ConversionSyntax and > DivisionImpossible are my > proposal, but it's my taste and know nothing about numbers > usability... Here are my thoughts, just as untutored as yours. I'm working primarily from hursley's spec here... Signal Should it raise by default? And why? ------ ------------------------------------ Clamped Yes - … [View More]

2 1

Python Bug day this Saturday
by A.M. Kuchling July 6, 2004

July 6, 2004

[This is intended to take place after 2.4alpha1 is released. Are we on track for an alpha1 release this week? The fact that there's still no resolution for the function decorator question is a bit worrying.] The second Python Bug Day is coming soon: Saturday, July 10, 2004. What's a bug day? ================= Participants meet in an IRC channel and collaboratively go through the Python bug database, fixing and closing bugs as they go. It's a good way to contribute to Python and learn … [View More]

4 3

excuse me
by barry＠python.org July 6, 2004

July 6, 2004

wrong calculation! (see the attachment!)

1 0

RE: [Python-Dev] PEP 276 (simple iterator for ints)
by Chermside, Michael July 6, 2004

July 6, 2004

Andrew Koenig writes: > I happened to look at PEP 276 and was struck by the thought > that PEP 276 is > really an implementation of the well-known set-theoretic > construction of the > natural numbers that defines each natural number as the set > of all smaller > ones. In other words, it defines 0 as the empty set, 1 as > the set whose > only element is 0, 2 as the set whose elements are 0 and 1, and so on. Interesting. I suppose that could be added as an extra … [View More]

10 9

RE: [Python-Dev] Improved super/autosuper
by Delaney, Timothy C (Timothy) July 5, 2004

July 5, 2004

Delaney, Timothy C (Timothy) wrote: > OK - super raises. super_raise goes away, and there is no equivalent > for not raising. If people want that, they can subclass :) OK - I've updated the recipe to reflect this change. It makes the code a *lot* cleaner - it's almost readble now. I also discovered that I'd missed an infinite recursion bug (which I'd been explicitly guarding against ... but then managed to mess up). Tim Delaney

1 0

RE: [Python-Dev] Improved super/autosuper
by Delaney, Timothy C (Timothy) July 5, 2004

July 5, 2004

guido(a)python.org wrote: >>> class A (autosuper): >>> >>> def __init__ (self, a, b): >>> print 'A.__init__' >>> print a, b >>> self.super(a, b) >>> >>> def test (self, a, b): >>> print 'A.test' >>> print a, b >>> self.super(a, b) >>> >>> class B (A): >>> >>> … [View More]

1 0

RE: [Python-Dev] Improved super/autosuper
by Delaney, Timothy C (Timothy) July 5, 2004

July 5, 2004

guido(a)python.org wrote: >> The current `super` implementation was always (as I understood it) >> meant to be an interim solution until a better syntax could be >> determined. > > Fair enough, although I doubt that I said it that way -- I believe I > simply said something like "and here's how you can do 'super' using > descriptors." Hmm - thought I'd seen it in various conversations online (as opposed to in the intro doc). Oh well ... > I haven't … [View More]downloaded that to test it thoroughly, and the code is way > too hairy to understand easily, so I'm just asking here: how sure are > you that it always does the right thing? There are some seriously > nasty edge cases for super, including making sure you always follow > the MRO correctly. Yeah - it's somewhat hairy at the moment. I'd like to simplify it further (it's better than it was ...). I came across a number of edge cases while implementing this that are dealt with. I definitely can't claim that I'm 100% sure that it does the right thing - haven't developed a full test suite for it yet (obviously) - this was something I've done in a couple of hours of "spare time" in the last couple of days. Mainly I wanted to get it out to the wider community to see if it was worthwhile pursuing further - and for other people to pick apart and criticise. > Just as important is not having to hardcode the method (and you > support that as well). But that requires using sys._getframe() or > other nastiness to find the method name. Yeah - I meant to mention that (I did in the Cookbook). Yes, it uses sys.getframe() :( >> It's also backwards-compatible. > > Sure, although I'm not sure I understand in what sense. I guess you > mean it doesn't define new keywords? No new keywords, doesn't impinge on the existing use of super. If it's implemented correctly (yet to be proven ;) existing uses of super and this can be used side-by-side, even in the same method. >> Would there be any interest in doing further work on this with the >> aim of getting it into the core? > > Hmm... I'd rather work on a syntactic approach so the compiler can > generate the appropriate call to the current super built-in. That would be preferable. Although I do like having super be a property on the instance - it makes method calls on super consistent with everything else. I'd see this as a property on `object` in that case. Initially I wasn't passing self, but just finding it from the stack frame. I'd actually gone away from that approach though before I remembered that wouldn't work with psyco anyway :) >> BTW, I've made a couple of design choices which I'm not sure about. >> Specifically, I've made `self.super` *not* throw an AttributeError >> when no base class has the attribute - this simplifies dealing with >> mixin classes (since you can just blindly put the self.super call >> in). > > This is clearly wrong. If your code doesn't even know whether there's > a base class method or not, I doubt that you understand your base > class well enough to be able to extend it. Introducing a new method > should be clearly different from overriding an existing one > (conceptually)! The more I think about it, the more it should be that the default should be to throw exceptions. The rationale behind not throwing attribute exceptions is primarily mix-in classes - they can't know where in the MRO they're going to be - whether or not their attributes are going to interfere with other classes in the MRO. However, the more I think about it, the less examples I can think of where it would be a good thing to do. >> I've included a second property `super_raise` for when you want the >> exception. Most of my usage works better without the exception >> (since everything resolves back to object, and it doesn't have many >> methods ...). But I'd like other people's opinion on which is >> preferable. > > You've got mine. :-) OK - super raises. super_raise goes away, and there is no equivalent for not raising. If people want that, they can subclass :) Thanks for the comments Guido. I think I'll let it soak for a while and see what other people think about it. Tim Delaney [View Less]

1 0

Improved super/autosuper
by Delaney, Timothy C (Timothy) July 5, 2004

July 5, 2004

The current `super` implementation was always (as I understood it) meant to be an interim solution until a better syntax could be determined. I've submitted a recipe to the Cookbook for an improved super/autosuper which allows using syntax like: class A (autosuper): def __init__ (self, a, b): print 'A.__init__' print a, b self.super(a, b) def test (self, a, b): print 'A.test' print a, b self.super(a, … [View More]

2 2

RE: [Python-Dev] decimal API
by Batista, Facundo July 5, 2004

July 5, 2004

[Tim Peters] #- Note that I've suggested that some trap-enable flags should be set by #- default for Python: those for invalid operation, divide by 0, and #- overflow. So, in my mind (unsullied by reality <wink>): (a) #- conversion of a nonsense string already signals invalid-operation; #- and, (b) because the invalid-operation trap-enable flag is set by #- default in Python, it also already raises an exception. We don't have nothing enabled by default: >>> import Decimal &… [View More]

1 0

RE: [Python-Dev] decimal API
by Batista, Facundo July 5, 2004

July 5, 2004

[Raymond Hettinger] #- So, my question for the group is whether to: #- #- * leave it as-is #- * raise a ValueError just like float('abc') or int('abc') #- * raise an Invalid Operation and return a quiet NaN. I'll go for leaving it as-is: >>> import Decimal >>> d = Decimal.Decimal('rdd') >>> d Decimal("NaN") >>> Decimal.getcontext().trap_enablers[Decimal.ConversionSyntax] = True >>> d = Decimal.Decimal('rdd') Traceback (most recent call last): … [View More]

1 0