[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 413 open ( -7) / 3521 closed (+11) / 3934 total ( +4) Bugs: 946 open ( +2) / 6400 closed ( +9) / 7346 total (+11) RFE : 248 open ( -1) / 246 closed ( +1) / 494 total ( +0) New / Reopened Patches __ Auto-completion list placement (2006-12-23) http://python.org/sf/1621265 opened by Tal Einat normalize namespace from minidom (2006-12-23) http://python.org/sf/1621421 opened by Paul Pacheco Allow __class __ assignment for classes with __slots__ (2006-12-28) http://python.org/sf/1623563 opened by TH fast subclasses of builtin types (2006-12-28) http://python.org/sf/1624059 opened by Neal Norwitz Patches Closed __ add direct access to MD5 compression function to md5 module (2003-03-16) http://python.org/sf/704676 closed by akuchling pty.fork() compatibility code wrong? (2003-08-04) http://python.org/sf/783050 closed by akuchling for i in range(N) optimization (2003-05-15) http://python.org/sf/738094 closed by gvanrossum Add --remove-source option to setup.py (2003-08-22) http://python.org/sf/793070 closed by akuchling SimpleHTTPServer directory-indexing "bug" fix (2003-10-21) http://python.org/sf/827559 closed by akuchling Remove unncessary NLST from ftp transfers (2004-10-12) http://python.org/sf/1045783 closed by akuchling add Bunch type to collections module (2005-01-02) http://python.org/sf/1094542 closed by akuchling HMAC hexdigest and general review (2005-04-13) http://python.org/sf/1182394 closed by akuchling tarfile.py: ExFileObject\'s tell() is wrong after readline() (2005-06-30) http://python.org/sf/1230446 closed by gustaebel tarfile: fix for bug #1257255 (2005-08-17) http://python.org/sf/1262036 closed by gustaebel Patch for 1496501 tarfile opener order (2006-06-10) http://python.org/sf/1504073 closed by gustaebel New / Reopened Bugs ___ minor inconsistency in socket.close (2006-12-22) http://python.org/sf/1620945 opened by Jonathan Ellis IDLE crashes on OS X 10.4 when "Preferences" selected (2006-12-23) http://python.org/sf/162 opened by Mick L random import works? (2006-12-23) CLOSED http://python.org/sf/1621367 opened by Msword this module (Zen of Python) docs list broken URL (2006-12-24) http://python.org/sf/1621660 opened by Calvin Spealman Tcl/Tk auto-expanding window (2006-12-25) http://python.org/sf/1622010 opened by Fabian_M null bytes in docstrings (2006-12-26) http://python.org/sf/1622533 opened by Fredrik Lundh language reference index links are broken (2006-12-26) http://python.org/sf/1622664 opened by Drew Perttula Exception when compressing certain data with bz2 (2006-12-27) http://python.org/sf/1622896 opened by Alex Gontmakher preferred diff format should be mentioned as "unified". (2006-12-27) http://python.org/sf/1623153 opened by Raghuram Devarakonda module docstring for subprocess is wrong (2006-12-28) CLOSED http://python.org/sf/1623890 opened by Neal Norwitz updating a set in a list of sets will update all of them (2006-12-29) CLOSED http://python.org/sf/1624534 opened by Amir Reza Khosroshahi webbrowser.open_new() suggestion (2006-12-30) http://python.org/sf/1624674 opened by Imre Péntek Bugs Closed ___ gethostbyaddr lag (2002-07-19) http://python.org/sf/583975 closed by nnorwitz CGIHTTPServer does not handle scripts in sub-dirs (2003-05-13) http://python.org/sf/737202 closed by akuchling MacOS9: test_uu fails (2003-07-23) http://python.org/sf/776202 closed by akuchling Mode argument of dumbdbm does not work (2003-09-07) http://python.org/sf/802128 closed by akuchling random import works? (2006-12-23) http://python.org/sf/1621367 closed by rhettinger tarfile local name is local, should be abspath (2005-08-12) http://python.org/sf/1257255 closed by gustaebel Dictionary ordering docs are too unclear of dangers (2006-12-09) http://python.org/sf/1612113 closed by sf-robot logging %(module)s reporting wrong modules (2006-11-29) http://python.org/sf/1605110 closed by sf-robot array.array borks on deepcopy (2006-08-24) http://python.org/sf/1545837 closed by twouters tarfile.py: dict order dependency (2006-05-28) http://python.org/sf/1496501 closed by gustaebel module docstring for subprocess is wrong (2006-12-28) http://python.org/sf/1623890 closed by nnorwitz updating a set in a list of sets will update all of them (2006-12-29) http://python.org/sf/1624534 deleted by amir_reza Immediate Crash on Open (2006-11-20) http://python.org/sf/1599931 closed by sf-robot python-logging compatability with Zope. (2006-12-12) http://python.org/sf
Re: [Python-Dev] Possible platforms to drop in 2.6
On 12/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Brett Cannon schrieb: > I originally posted this list to python-3000 since I figured we could > be more aggressive with Py3K, but Guido said I should move it over > here and just be aggressive in 2.6. Please follow PEP 11 in doing so. This means you cannot remove the code in Python 2.6, only break the build with an error message. Actual removal would be deferred to 2.7. I wasn't planning on skipping the procedures in PEP 11. I just wanted to get the list of possible platforms to eliminate out there for people to comment on. So, here are the platforms I figured we should drop: > > * AtheOS > * BeOS In both cases, the last maintainer should be contacted before the platform is unsupported. I guess I can go off the emails listed in README and Misc/BeOS-NOTES, although I would hope that any maintainer would watch python-dev in some fashion. Is there an official list of maintainers? If not perhaps there should be a PEP listing who maintains what platforms. I had SunoS 5 but Ronald Oussoren said that is actually Solaris > through version 9, so I took that off. It's actually *all* Solaris versions (up to 11). Dropping support for 5.6 (Solaris 2.6) and earlier may be an option; we have some special-cased code for 5.6. OK. I don't have a Solaris box so someone else might need to help with that. Several people have questioned AtheOS, but considering the site for > the OS has not been updated since 2002 and it was a niche OS to begin > with I doubt we really need the support. IMO, that should really depend on active maintenance. Somebody should confirm that Python 2.5 still compiles out of the box on that system, and, if not, volunteer to fix it. If nobody does, we can remove the code in 2.7. Yep. Guess that goes along with contacting the maintainers. And I listed FreeBSD 2 as a drop since FreeBSD 3 seemed to have been > released in 1999. But if most users have upgraded by now (release 6 > is the most current) then we could consider dropping 3 as well. This really should use the PEP 11 procedure: let configure fail (early) on the system, and then remove support if nobody complains (in 2.7 and 3k). Sounds reasonable. Hopefully it would catch people early in the alpha stage to deal with this. -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] Possible platforms to drop in 2.6
Brett Cannon schrieb: > I originally posted this list to python-3000 since I figured we could > be more aggressive with Py3K, but Guido said I should move it over > here and just be aggressive in 2.6. Please follow PEP 11 in doing so. This means you cannot remove the code in Python 2.6, only break the build with an error message. Actual removal would be deferred to 2.7. > So, here are the platforms I figured we should drop: > > * AtheOS > * BeOS In both cases, the last maintainer should be contacted before the platform is unsupported. > I had SunoS 5 but Ronald Oussoren said that is actually Solaris > through version 9, so I took that off. It's actually *all* Solaris versions (up to 11). Dropping support for 5.6 (Solaris 2.6) and earlier may be an option; we have some special-cased code for 5.6. > Several people have questioned AtheOS, but considering the site for > the OS has not been updated since 2002 and it was a niche OS to begin > with I doubt we really need the support. IMO, that should really depend on active maintenance. Somebody should confirm that Python 2.5 still compiles out of the box on that system, and, if not, volunteer to fix it. If nobody does, we can remove the code in 2.7. > And I listed FreeBSD 2 as a drop since FreeBSD 3 seemed to have been > released in 1999. But if most users have upgraded by now (release 6 > is the most current) then we could consider dropping 3 as well. This really should use the PEP 11 procedure: let configure fail (early) on the system, and then remove support if nobody complains (in 2.7 and 3k). 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] multiple interpreters and extension modules
Jeremy Kloth schrieb: >> I think you understand exactly what is happening. It is happening for >> good reasons. Rather than asking for a change in semantics, I >> recommend that you deal with it, either in your Python code, or in >> your extension. It's not likely to change. > > I don't believe I was asking for a change in semantics, rather an additional, > optional interface for extension module writers. And that *is* a change in semantics. The algorithm run by the interpreter on module startup will be different from what it is now, i.e. it is a behavior (semantic) change. > I'll add here that it has been brought up here before that extension module > finalization is a feature that would be appreciated. With that, it is not > that far to add support for initialization/finalization for each interpreter. > That is, of course, using a DllMain-like solution. I wouldn't like to see a DllMain-like solution. Instead, there should be a function vector, and a specification which function is called in what cases. There should be an entry point that typically just returns a pointer to this module vtable. > With that approach in mind, I will be making changes so 4Suite will work in a > production mod_python deployment (where the aforementioned error occurred). > When that works, I'll come back with a proper PEP *and* patches against > Python SVN to support its use. I hope no one was thinking I wanted someone > else to do the work. I was actually going to, for several years now. Please do write the PEP before making the implementation. 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] multiple interpreters and extension modules
Jeremy Kloth schrieb: > 1) is subclassing Python classes in C as a static type supported? Even if > they > would be declared on the heap, they would be bound to the first loaded Python > class. As you found out: no, this isn't supported. To work around, you can wrap the extension module with Python module which invokes an explicit module initialization function; you then need to lookup the subclasses dynamically (going through thread_state->interp->modules). > As to question 2, I'm in the process of prototyping that approach to see if > it > is feasible in our code and if so, (and people find it useful) I'll attempt > to write a PEP for that feature. I'd like to see the module initialization/finalization be redone for Python 3, in particular with explicit finalization procedures. If Python 3 still supports multiple interpreters, this aspect should be taken into account. Whether there is any chance to add the PEP to 2.x, I don't know - it needs to be written first. 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] [Python-checkins] r53110 - python/trunk/Lib/mailbox.py
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 29, 2006, at 4:55 PM, Guido van Rossum wrote: > But my main objection to suggesting that these constants ought to be > used is that open() is a built-in but you would have to import os to > be able to call the seek method on the object it returns. > > If we want to make the seek API more 21st century, why not use keyword > arguments? Or put the constants on class attributes. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRZWRM3EjvBPtnXfVAQLWdwQAmrt5ncAhFIxCK2Tm72g90P9qckVrkdAt odvZ+fw8RFrKs3MUpsP2HtfHWHrouC6SHQCXoU63msfgy52vO4M9rG3NLN5Hi0KK tU4J9pkSqqi+Jfu4LvCs+ouURqxTbGicyMBUuw54hQWqg0bxvYvjEyuC1NFltcV6 HJ2qElSTOw0= =LAq1 -END PGP SIGNATURE- ___ 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-checkins] r53110 - python/trunk/Lib/mailbox.py
On Friday 29 December 2006 16:55, Guido van Rossum wrote: > If we want to make the seek API more 21st century, why not use keyword > arguments? I'd prefer that myself. I'm not advocating the constants as a way to go forward, but was simply expressing a preference for the named constant over a magic number in code. -Fred -- Fred L. Drake, Jr. ___ 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-checkins] r53110 - python/trunk/Lib/mailbox.py
On 12/29/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Fred L. Drake, Jr. schrieb: > > Speaking strictly for myself: I don't think I *have* to use them, but I do > > prefer to use them because I don't like magic constants that affect what a > > function does in code; I'd rather have a named constant for readability's > > sake. Maybe I just can't keep enough in my head, but I don't find I > > actually > > use seek() enough to remember what the numeric values mean with checking the > > reference documentation. > > But you *can* remember the symbolic names (plus you can remember what > module they are in, in what Python version)? I'd have to consult the > documentation for either; help(file.seek) gives the numeric values. I'm with Martin here. But my main objection to suggesting that these constants ought to be used is that open() is a built-in but you would have to import os to be able to call the seek method on the object it returns. If we want to make the seek API more 21st century, why not use keyword arguments? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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-checkins] r53110 - python/trunk/Lib/mailbox.py
Fred L. Drake, Jr. schrieb: > Speaking strictly for myself: I don't think I *have* to use them, but I do > prefer to use them because I don't like magic constants that affect what a > function does in code; I'd rather have a named constant for readability's > sake. Maybe I just can't keep enough in my head, but I don't find I actually > use seek() enough to remember what the numeric values mean with checking the > reference documentation. But you *can* remember the symbolic names (plus you can remember what module they are in, in what Python version)? I'd have to consult the documentation for either; help(file.seek) gives the numeric values. 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] classes and cell variables question
On 12/29/06, tomer filiba <[EMAIL PROTECTED]> wrote: > On 12/29/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > > def spam(): > > x = 5 > > class eggs(object): > > x = 6 > > def spam(self): > > return x > > return eggs > > > > spam()().spam() should return 5. > > > > the question that arises is -- is this what we wanted? > if i had to read such code, where i can't (easily) tell where "x" > is bound to, i wouldn't be content, to say the least. It's obfuscated code. But there is no doubt that these are the semantics that we wanted, and still want. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] classes and cell variables question
On 12/29/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > def spam(): > x = 5 > class eggs(object): > x = 6 > def spam(self): > return x > return eggs > > spam()().spam() should return 5. > the question that arises is -- is this what we wanted? if i had to read such code, where i can't (easily) tell where "x" is bound to, i wouldn't be content, to say the least. -tomer ___ 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] classes and cell variables question
On 12/19/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> to my understanding of the object model, the code of snippet 1
> and snippet 2 should be equivalent. a class is just a "special function"
> that returns its locals automatically and passes them to the metaclass
> constructor:
>
> --- snippet 1 ---
> class foo(object):
> x = 5
> def f(self):
> print "f", x
>
> --- snippet 2 ---
> def bar():
> x = 5
> def g(self):
> print "g", x
> return locals()
> barcls = type("barcls", (object,), bar())
>
> but there's one big difference. classes don't create cell variables
> to hold bound external variables. the "bar" version works, because
> "x" is a bound cell variable, but the "foo" version fails, as it attempts
> to access "x" as a global.
Others have explained the rationale for this design choice, and the
PEP is a good source for what we were thinking at the time.
I thought it was worth adding that a) class variables can never be
access as free variables, as your example foo() shows, and b) you
could access a variable bound in a function scope in a method.
Example of b):
def spam():
x = 5 # provides the binding for the free variable x in methods of eggs
class eggs(object):
x = 6 # irrelevant for purposes of resolving the free variable in
the method spam
def spam(self): # can't have too much spam
return x
return eggs
spam()().spam() should return 5.
Jeremy
>
> .>>> barcls().g()
> g 5
>
> .>>> foo().f()
> f
> Traceback (most recent call last):
> File "", line 1, in
> File "", line 4, in f
> NameError: global name 'x' is not defined
>
> for reference, i attached the code of all four functions below.
>
> my question is, how come classes don't create cell variables, like
> normal functions? was this done on purpose? does it have to
> do with inheritance? if so, what's wrong with my "bar" version?
>
>
> [1]
> # code of class foo
>
> # 2 0 LOAD_NAME0 (__name__)
> # 3 STORE_NAME 1 (__module__)
> # 3 6 LOAD_CONST 0 (5)
> # 9 STORE_NAME 2 (x)
> #
> # 4 12 LOAD_CONST 1 ( 009E5608, file "", line 4>)
> # 15 MAKE_FUNCTION0
> # 18 STORE_NAME 3 (f)
> # 21 LOAD_LOCALS
> # 22 RETURN_VALUE
>
> [2]
> # code of foo.f:
>
> # 5 0 LOAD_CONST 1 ('f')
> # 3 PRINT_ITEM
> # 4 LOAD_GLOBAL 0 (x)
> # 7 PRINT_ITEM
> # 8 PRINT_NEWLINE
> # 9 LOAD_CONST 0 (None)
> # 12 RETURN_VALUE
>
> [3]
> # code of bar:
>
> # 2 0 LOAD_CONST 1 (5)
> # 3 STORE_DEREF 0 (x)
> #
> # 3 6 LOAD_CLOSURE 0 (x)
> # 9 BUILD_TUPLE 1
> # 12 LOAD_CONST 2 ( 009F6698, file "", line 3>)
> # 15 MAKE_CLOSURE 0
> # 18 STORE_FAST 0 (g)
> #
> # 5 21 LOAD_GLOBAL 0 (locals)
> # 24 CALL_FUNCTION0
> # 27 RETURN_VALUE
>
> [4]
> # code of bar.g:
>
> # 4 0 LOAD_CONST 1 ('g')
> # 3 PRINT_ITEM
> # 4 LOAD_DEREF 0 (x)
> # 7 PRINT_ITEM
> # 8 PRINT_NEWLINE
> # 9 LOAD_CONST 0 (None)
> # 12 RETURN_VALUE
> ___
> 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/jeremy%40alum.mit.edu
>
___
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] Cached Property Pattern
On Friday 29 December 2006 10:50, Oleg Broytmann wrote: >I don't remember any resolution. I think submitting a small module to > the patch tracker would be the simplest way to revive the discussion. We have a handful of interesting descriptors we use for Zope 3 development: http://svn.zope.org/Zope3/trunk/src/zope/cachedescriptors/ I find I use the Lazy property quite a bit in short-lived contexts (a single web request); this sounds very much like what's being described here. The readproperty is probably better when the computation isn't so expensive and the value may need to be re-computed frequently anyway. -Fred -- Fred L. Drake, Jr. ___ 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] Cached Property Pattern
On Fri, Dec 29, 2006 at 09:55:46AM -0500, Calvin Spealman wrote: > It may have been discussed before, but there does not seem to have > been any resolution on the issue. Am I missing something or did the > discussion just kind of stop, with no solution or agreement ever > reached? In which case, reviving the question is not a bad idea, is > it? I don't remember any resolution. I think submitting a small module to the patch tracker would be the simplest way to revive the discussion. > On 12/29/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > > http://mail.python.org/pipermail/python-dev/2005-September/056782.html > > http://mail.python.org/pipermail/python-dev/2005-October/057120.html Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] Cached Property Pattern
It may have been discussed before, but there does not seem to have been any resolution on the issue. Am I missing something or did the discussion just kind of stop, with no solution or agreement ever reached? In which case, reviving the question is not a bad idea, is it? On 12/29/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > http://mail.python.org/pipermail/python-dev/2005-September/056782.html > > On Fri, Dec 29, 2006 at 02:40:05AM -0500, Calvin Spealman wrote: > > To this end, should a cachedproperty builtin be included to do this > >The issue was discussed a year ago: > > http://mail.python.org/pipermail/python-dev/2005-September/056782.html > http://mail.python.org/pipermail/python-dev/2005-October/057120.html > > Oleg. > -- > Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] >Programmers don't die, they just GOSUB without RETURN. > ___ > 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/ironfroggy%40gmail.com > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ 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] Looking for python SIP and MGCP stacks
On Wednesday 27 December 2006 12:15, Jenny Zhao (zhzhao) wrote: > Hi Python developers, > > I am using python to write a testing tools, currently this tool > only supports skinny protocol. I am planning to add SIP and MGCP > support as well, wondering if you have written these protocol > stacks before which can be leveraged from. This should go to python-list@python.org (aka comp.lang.python), not this list. This list is for development _of_ python, not development _in_ python. Thanks, Anthony ___ 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] Looking for python SIP and MGCP stacks
Hi Python developers, I am using python to write a testing tools, currently this tool only supports skinny protocol. I am planning to add SIP and MGCP support as well, wondering if you have written these protocol stacks before which can be leveraged from. thanks Jenny ___ 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] Cached Property Pattern
http://mail.python.org/pipermail/python-dev/2005-September/056782.html On Fri, Dec 29, 2006 at 02:40:05AM -0500, Calvin Spealman wrote: > To this end, should a cachedproperty builtin be included to do this The issue was discussed a year ago: http://mail.python.org/pipermail/python-dev/2005-September/056782.html http://mail.python.org/pipermail/python-dev/2005-October/057120.html Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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
