Re: [Python-Dev] Decimal returning NotImplemented (or not)
Guido van Rossum wrote: No, the reason is that if we did this with exceptions, it would be liable to mask errors; an exception does not necessarily originate immediately with the code you invoked, it could have been raised by something else that was invoked by that code. The special value NotImplemented must pretty much originate directly in the invoked code, since the implementation guarantees that e.g. a+b can never *return* NotImplemented: if a.__add__(b) and b.__radd__(a) both return NotImplemented, TypeError is raised. That makes sense - although for that reasoning, a TypeError subclass that the binary operation machinery promotes to a standard TypeError would seem to work too (with the advantage of also raising at least some sort of exception when the method is called directly) You went on to great lengths later about how it's less natural in Python to return an error value, but I disagree. I've written a lot of code like this and it's quite natural to write things like this: def __add__(self, other): if not isinstance(other, ThisClass): return NotImplemented return ...implementation of self + other... It wasn't so much this part that struck me as ugly, as the subsequent usage of the methods directly in the Decimal Context implementation. The inconsistency of the interface was the main irritation. All of the methods that implemented standard binary operations returned NotImplemented on an argument error, while other methods raised TypeError directly. So for some methods Context was checking the return value and raising TypeError, but for others it was just making the call. The mixture of the two styles didn't look nice :) If you want to factor out the type check, it makes just as much sense to define a Boolean function: def __add__(self, other): if not self.acceptableArgument(other): return NotImplemented ...etc... I'm considering an approach that involves the simple wrapper function: def raiseIfNotImplemented(func, message): def wrapper(*args, **kwds): result = func(*args, **kwds) if result is NotImplemented: raise TypeError(message) return result After rewriting _convert_other and all the binary special methods to return NotImplemented for bad arguments (as you suggest), the wrapper above can be used to provide alternate functions that raise the TypeError instead (making it easy to provide a consistent API for use by Context). Obviously, such a strategy makes this a 2.5 only solution, as it involves adding methods. A potentially-2.4-compatible solution is the one I used in 'friendly decimal' which simply duplicates the code of the above wrapper wherever it is needed by Decimal or Context. I'm guessing this wasn't caught before 2.4 was released because most people reviewing the code were more interested in correct computations than into correct integration in the Python framework. This is quite likely to be true :) Although I find it interesting that string objects share the same characteristic of not respecting __rop__ when it is provided by another class that is not a subclass of string. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev Summary for 2005-02-01 through 2005-02-14 [draft]
Here are sample summaries of two skipped threads. If anyone has
comments, criticisms, or rotten tomatoes, let me know.
---
Replacing list of constants with tuple of constants
---
Skip Montanaro noticed that Raymond Hettinger had made a number of
library checkins replacing lists with tuples in constructs like ``for
a in [1, 2, 3]:`` and ``if a in [1, 2, 3]:``. He agreed with the
motivation (the peephole optimizer can convert a tuple of constants
into a single constant, eliminating construction time), but questioned
hardcoding the optimization. Instead, he suggested teaching the
optimizer about throwaway lists in ``for`` and ``if`` statements.
Guido agreed with the sentiment. Raymond accepted the suggestion, and
checked in code to implement it.
Contributing threads:
- `list of constants - tuple of constants
http://mail.python.org/pipermail/python-dev/2005-February/051442.html`__
---
Complex I/O problem
---
Neal Becker asked why the result of printing a ``complex`` is not an
acceptable input to constructing a complex. For example, ``print
complex(2,2)`` yields ``'(2+2j)'``; but ``complex('(2+2j)')`` throws a
``ValueError``.
A. M. Kuchling responded that many types, including ``str`` and
``file`` share this behavior, and that in any event, parsing string
representations is a job more suited to ``eval`` than to classes
themselves.
Guido `reiterated the rules`_ for ``str()`` (used by ``print``) and
``repr()``. Since both ``complex.__str__`` and ``complex.__repr__``
pass the ``eval()`` test, he pronounced it fine.
.. _reiterated the rules:
http://mail.python.org/pipermail/python-dev/2005-February/051390.html
Contributing threads:
- `complex I/O problem
http://mail.python.org/pipermail/python-dev/2005-February/051388.html`__
--
Tim Lesher [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Outdating import.c 2.241
I just mistakenly checked in import.c; I have outdated this checkin (cvs admin -o 2.241 import.c). If you happened to have checked-out import.c in-between, don't be surprised if the version numbers go backwards. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Outdating import.c 2.241
Martin v. Löwis [EMAIL PROTECTED] writes: I just mistakenly checked in import.c; I have outdated this checkin (cvs admin -o 2.241 import.c). If you happened to have checked-out import.c in-between, don't be surprised if the version numbers go backwards. Oh! Oops. python-checkins sorts before python-dev... Cheers, mwh -- Remember - if all you have is an axe, every problem looks like hours of fun.-- Frossie -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Useful thread project for 2.5?
Florent Guillaume recently wrote a valuable addin for Zope: http://www.zope.org/Members/nuxeo/Products/DeadlockDebugger When a Zope has threads that are hung, this can give a report of Python's current state (stack trace) across all threads -- even the ones that are hung (the deadlocked threads don't have to cooperate). The same flavor of thing would (of course) be handy outside of Zope too -- debugging deadlocked Python threads is a PITA regardless of context. Florent's DeadlockDebugger in turn builds on an external C threadframe module: http://www.majid.info/mylos/stories/2004/06/10/threadframe.html Folding the functionality of that (or similar functionality) into the core would, IMO, be a valuable addition for 2.5, and would make an excellent intro project for an aspiring contributor interested in how threads work in CPython (what this module does is conceptually simple). It belongs in the core because it's not safe to chase the tstate chain without holding pystate.c's internal head_mutex lock (holding the GIL isn't enough -- it's normal practice to call PyThreadState_Delete() while not holding the GIL). I'd do it myself (and maybe I will anyway), but this really would make a good (finite; conceptually simple) project for someone who wants to gain Python developer experience. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Useful thread project for 2.5?
At 04:01 PM 3/4/05 -0500, Tim Peters wrote: Florent's DeadlockDebugger in turn builds on an external C threadframe module: http://www.majid.info/mylos/stories/2004/06/10/threadframe.html Folding the functionality of that (or similar functionality) into the core would, IMO, be a valuable addition for 2.5, and would make an excellent intro project for an aspiring contributor interested in how threads work in CPython (what this module does is conceptually simple). It belongs in the core because it's not safe to chase the tstate chain without holding pystate.c's internal head_mutex lock (holding the GIL isn't enough -- it's normal practice to call PyThreadState_Delete() while not holding the GIL). I'd do it myself (and maybe I will anyway), but this really would make a good (finite; conceptually simple) project for someone who wants to gain Python developer experience. What would you suggest calling it? sys._current_frames(), returning a dictionary? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev Summary for 2005-02-01 through 2005-02-14 [draft]
Here's another two skipped threads. Ditto Tim Lesher's comments, criticisms, or rotten tomatoes request. =) - 2.3.5 and 2.4.1 release plans - Anthony Baxter, Alex Martelli and Tim Peters squelched a bug where deepcopy failed on instances of types that lacked an ``__mro__`` attribute. The patch was pretty straight-forward (use ``inspect.getmro`` instead of ``cls.__mro__``), but coming up with a test case was hard -- creating a Python object that doesn't have an ``__mro__`` takes some complicated C code like that of Zope's ExtensionClass. Fortunately, John Lenton's c.l.py suggestion to simply raise an AttributeError for ``__mro__`` in ``__getattribute__`` properly ticked the bug, and 2.3.5 was cleared for release. Contributing Threads: - `2.3.5 and 2.4.1 release plans http://mail.python.org/pipermail/python-dev/2005-February/thread.html`__ - Clarification sought about including a multidimensional array object into Python core - Travis Oliphant and others looked into the issues of including an array object (like that of Numeric or numarray) in Python core. Guido seemed hesitant, concerned that as Numeric and numarray continue to co-exist, the array object wouldn't be the best of breed (one of the expectations for inclusion in Python core). Travis explained that most of the disagreements are over ufunc objects, not the basic array object itself, so it wouldn't be unreasonable to include the array object without the ufunc object if necessary. There was also some suggestion that, at least for basic arithmetic operations, Numeric and numarray mostly agree, so a stripped-down ufunc object for these operations might also be inclusion-worthy. In an aside that grew decidedly un-aside-ish, Paul F. Dubois, Guido and David Ascher explained why matrix should not inherit from arrayobject -- this would complicate __new__ and cause confusion when mixed operands (arrays and matrices) are given to a binary op like multiplication. Contributing Threads: - `Clarification sought about including a multidimensional array object into Python core http://mail.python.org/pipermail/python-dev/2005-February/051474.html`__ - `Numeric life as I see it http://mail.python.org/pipermail/python-dev/2005-February/051493.html`__ Steve Bethard -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev Summary for 2005-02-01 through 2005-02-14 [draft]
Both entries so far look very good. Perhaps writing python-dev summaries could be a rotating position? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev Summary for 2005-02-01 through 2005-02-14 [draft]
On Fri, Mar 04, 2005, John J Lee wrote: On Fri, 4 Mar 2005, Aahz wrote: Both entries so far look very good. Perhaps writing python-dev summaries could be a rotating position? Or even a joint effort? It's up to the contributors, of course: just a thought... That was my original thought, too, then I remembered just how much work coordinating is ;-) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Annoying $Id$ in Misc/NEWS
This entry in Misc/NEWS - SF patch 995225: The test file testtar.tar accidentally contained CVS keywords (like $Id: NEWS,v 1.1266 2005/03/05 02:53:17 gward Exp $), which could cause spurious failures in test_tarfile.py depending on how the test file was checked out. just caused a conflict when I merged something from 2.4 onto the trunk. (It was Id: ... 1.265 ... mloewis on the trunk, but Id: ... 1.1193.2.32 ... gward on the branch.) This is deliciously ironic: you can't talk about accidental CVS keywords in testtar.tar without having accidental CVS keywords in the text that talks about accidental CVS keywords!! Aieee!!! The obvious fix is to disable keyword expansion for Misc/NEWS: cvs admin -ko Misc/NEWS Anyone mind if I do that? wondering-what-will-happen-to-my-subject-line'ly, Greg -- Greg Ward [EMAIL PROTECTED] http://www.gerg.ca/ Never try to outstubborn a cat. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev Summary for 2005-02-01 through 2005-02-14 [draft]
Aahz wrote: Both entries so far look very good. Perhaps writing python-dev summaries could be a rotating position? Good idea that several people have now suggested to me. I have emailed Tim, Steve, and Tony to see what they think. It wouldn't surprise me if this happens if for any other reason than the shock at how long these Summaries can take. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev Summary for 2005-02-01 through 2005-02-14 [draft]
Aahz wrote: On Fri, Mar 04, 2005, John J Lee wrote: On Fri, 4 Mar 2005, Aahz wrote: Both entries so far look very good. Perhaps writing python-dev summaries could be a rotating position? Or even a joint effort? It's up to the contributors, of course: just a thought... That was my original thought, too, then I remembered just how much work coordinating is ;-) Maybe the contributors could claim threads to summarise shortly after the threads start? That might reduce the burden of needing to follow *every* thread. . . then Skipped Threads would contain any threads that nobody claimed. JJL's last comment applies to me, too, naturally :) Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Documentation for __new__
Steven Bethard has put together some text to add __new__ to the list of Basic Customisation methods in the language reference. Would one of the documentation folks care to take a look at it? The relevant SF tracker item is http://www.python.org/sf/1156412 Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Memory Allocator Part 2: Did I get it right?
Evan Jones wrote: Sorry for taking so long to get back to this thread, it has been one of those weeks for me. On Feb 16, 2005, at 2:50, Martin v. Löwis wrote: Evan then understood the feature, and made it possible. This is very true: it was a very useful exercise. I can personally accept breaking the code that still relies on the invalid APIs. The only problem is that it is really hard to determine whether some code *does* violate the API usage. Great. Please ignore the patch on SourceForge for a little while. I'll produce a revision 3 this weekend, without the compatibility hack. Evan uploaded the newest version (@ http://www.python.org/sf/1123430) and he says it is complete. Assuming a code review says the patch is sane, do we want to go with this garbage collection change? From past discussions I don't remember a consensus on acceptance or rejection, just lots of discussion about ripping out the hacks to allow freeing memory w/o holding the GIL (I assume Evan's patch rips that code out). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Requesting that a class be a new-style class
Guido van Rossum wrote: This is something I've typed way too many times: Py class C(): File stdin, line 1 class C(): ^ SyntaxError: invalid syntax It's the asymmetry with functions that gets to me - defining a function with no arguments still requires parentheses in the definition statement, but defining a class with no bases requires the parentheses to be omitted. It's fine to fix this in 2.5. I guess I can add this to my list of early oopsies -- although to the very bottom. :-) It's *not* fine to make C() mean C(object). (We already have enough other ways to declaring new-style classes.) OK, this is now in thanks to the following revisions: Checking in Grammar/Grammar; /cvsroot/python/python/dist/src/Grammar/Grammar,v -- Grammar new revision: 1.53; previous revision: 1.52 done Checking in Python/graminit.c; /cvsroot/python/python/dist/src/Python/graminit.c,v -- graminit.c new revision: 2.39; previous revision: 2.38 done Checking in Python/compile.c; /cvsroot/python/python/dist/src/Python/compile.c,v -- compile.c new revision: 2.349; previous revision: 2.348 done Checking in Misc/NEWS; /cvsroot/python/python/dist/src/Misc/NEWS,v -- NEWS new revision: 1.1267; previous revision: 1.1266 done -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python-dev Summary for 2005-02-15 through 2005-02-28 [draft]
Decided to just plow through the next Summary so that I was finally caught up. I am not expecting the candidates for taking of the Summaries to write stuff for this one (although I wouldn't mind it =). The idea of having them work together to write the Summaries has been proposed, but this is going out before I have heard back. Depending on the number of people who send in edits, this could go out the same time as the 2005-02-01 Summary or I might wait until Monday night so people who only check mail on weekdays have a chance to look at this. - = Summary Announcements = Status of the candidates XXX --- PyCon Looms --- PyCon_ is coming! Be there or be a Java or Perl coder! .. _PyCon: http://www.pycon.org/ = Summaries = - PEP movements - `PEP 309`_ is now final since the 'functional' module has now been checked into Python. .. _PEP 309: http://www.python.org/peps/pep-0309.html Contributing threads: - `PEP 309 enhancements `__ - `PEP 309 `__ -- Indices for slices other objects with __int__ not okay -- Travis Oliphant asked if it would be possible to patch slicing so that any object that defines __int__ could be used. Guido didn't like this idea, though. Float, for instance, has __int__ defined. Guido admitted he unfortunately copied a design mistake from C here. He said he might add a __trunc__ magic method in Python 3000 for objects that really can't be viewed as an int but are willing to have data loss to give one. Contributing threads: - `Fixing _PyEval_SliceIndex so that integer-like objects can be used `__ - `Fix _PyEval_SliceIndex (Take two) `__ Why can't ``class C(): pass`` be acceptable? No reason. =) So as of Python 2.5 it is acceptable to have empty parentheses for class definitions. It does create a classic class and not a new-style one. Contributing threads: - `Requesting that a class be a new-style class `__ -- What basestring is truly meant for -- What is basestring for? According to Guido it is purely for unicode and str to inherit from to help with checks in code where either type is acceptable. It is *not* meant to be used as a base class for any other classes. Contributing threads: - `UserString `__ -- Quickly opening an SF bug/patch in Firefox/Thunderbird -- Martin v. Lwis posted a way to use the DictionarySearch_ plug-in for Mozilla to launch a browser with the highlighted patch/bug #. See the email for the thread on how to get it to work. .. _DictionarySearch: http://dictionarysearch.mozdev.org/download.php/http://downloads.mozdev.org/dictionarysearch/dictionarysearch_0.8.xpi Contributing threads: - `Quick access to Python bug reports in Thunderbird `__ Optimizing ``x in [1, 2, 3]`` Raymond Hettinger has been trying to teach the peepholer some new tricks to optimize ``x in [1, 2, 3]`` and the like into a faster operation. Initially he got it to change the list to a tuple. He then tried turning the list into a frozenset, but that had the unforeseen issue of breaking semantics since it then required the object being checked for to be hashable. So Raymond suggested introducing a SearchSet that tried the comparison as a frozenset first, and upon failure of hashing, to old way of just looking at each item in the list. But this seemed like overkill since most lists would be small; probably usually under 4 items. But Fredrik Lundh suggested expanding it to ``x == 1 or x == 2 or x == 3``. This seemed like a performance boost when the items of the list were lists since the COMPARE_OP opcode special-cases comparing ints. But for other instances it probably isn't worth it unless more special-casing is done in the opcodes. Contributing threads: - `Prospective Peephole Transformation `__ -- A DupStore opcode? -- Raymond Hettinger suggested a new opcode called DupStore that would replace load;store opcode pairs. Guido questioned if this was leading down a road of adding too much extra code for little benefit. Off this a discussion about speeding up frame allocation, an area viewed as needing some optimization, started up. Contributing threads: - `Store x Load x -- DupStore `__ === Skipped Threads === + pymalloc on 2.1.3 + Exceptions *must*? be old-style classes? + subclassing PyCFunction_Type + Windows Low Fragementation Heap yields speedup of ~15% + string
