Mailman 3 June 2004 - Python-Dev

Re: [Python-Dev] Object finalization for local (ie function) scop es
by Jewett, Jim J June 14, 2004

June 14, 2004

I suspect people are talking about slightly different things. I'll try to make my understanding very explicit, so that people can jump on the parts they disagree with. (1) Python does not guarantee that it will clean up for you. If an object has a __del__ method, then this method will be run when the object is finalized -- but python might decide to never finalize the object. For example, if there are two objects in a cycle, and both have a __del__ method, then python may decide to make them immortal, so that it doesn't have to decide which __del__ to run first. (2) It is fairly common to have a resource which should be closed/released when you are done. (Example: a file). Normally, the garbage collector will do this for you -- it might even do so in all your tests, but not in production. If you want to *ensure* that your files are flushed and closed, you have to do it yourself, because python might choose not to collect them, even though it could. This is bug-prone. (a) It is easy to forget (and the problem may not show up in tests, because the garbage collection will *usually* work). (b) Calling a finalizer (such as close) explicitly means you can call it before all references are truly gone. (3) The closest thing there is to a safe idiom today is to emulate lisp's with-open-* macros using try/finally. try: f = open("filename") # if you do catch exceptions, then finally will have to # be replaced with a bare except and a reraise, plus an # else clause finally: f.close() (4) Proponents would like a way of saying "objects like this should *always* get their finalizer called". In return, they're willing to say "this is a temporary object that will not be returned from the local scope." If you replaced f() with f() gc() then any such objects created in f should have their __del__ methods run now. Even if they do appear in cycles. Even if they are referenced by an uncollectable object, such as an old extension class. (5) As proposed, it would be the user's responsibilibity to ensure that running __del__ was safe. In return, python would guarantee to actually do it, even if garbage collection is turned off. -jJ

1 0

RE: [Python-checkins] python/dist/src/Lib asyncore.py, 1.51, 1.52
by Raymond Hettinger June 14, 2004

June 14, 2004

> ! def loop(timeout=30.0, use_poll=False, map=None, count=1e309): Would sys.maxint have sufficed? Raymond

3 3

python-dev Summary for 2004-05-01 through 2004-05-31 [draft]
by Brett June 14, 2004

June 14, 2004

Thanks to a change in the IMAP server used for my email I have switched to Apple Mail to do this summary. May have missed some threads, but if I did miss anything I will get to them in the next summary. I probably won't get to sending out this summary until the latter half of next week, so no huge rush on corrections. ----------------------------------- Summary Announcements ===================== The Spring quarter is now finished for me, so hopefully over the summer I can pull off a semi-monthly summaries again (work permitting). 2.3.4 was released during the coverage time of this summary. Everyone should upgrade if possible to this bugfix release. 2.4a should be ready by mid-July. The email server I use (not under my control) decided to change their IMAP server. Unfortunately it is not playing nicely with Thunderbird or the mbox format, so I am being forced to use Apple Mail in order to delete emails. Since I am not used to Mail's threading I may have missed some threads. If I did, sorry about that and they will be covered in the next summary. Summaries ========= ----------------------------- Generator expressions are in! ----------------------------- Generator expressions have been checked in. They are currently using late bindings (see the `last summary`_ for an explanation of what that means). If using late binding semantics doesn't work for you, do express your opinion since it can be changed before the beta is released. Contributing threads: - `PEP 289 - Generator Expressions <http://mail.python.org/pipermail/python-dev/2004-May/044684.html>`__ - `PEP 289 - Generator Expressions - Let's Move For ward <http://mail.python.org/pipermail/python-dev/2004-May/044643.html>`__ ------------------------------------------ Following the docs, not the implementation ------------------------------------------ What happens if you rely on an implementation when the documentation explicitly states the semantics in another way? Well, "you will pay for your sin in a special kind of hell set aside for people who take the implementation as the spec" according to Guido. Some things in CPython go against the spec for performance reasons, but there is nothing stopping from it being changed at another point to more closely follow the spec. Contributing threads: - `Passing compile(...,'exec') code to 'eval' <http://mail.python.org/pipermail/python-dev/2004-May/044683.html>`__ --------------------------------------------- What you need to get a module into the stdlib --------------------------------------------- In order to prevent the stdlib from getting bloated with unneeded modules, new ones need to have seen use "in the field", as Guido put it. Contributing threads: - `New Subscriber <http://mail.python.org/pipermail/python-dev/2004-May/044709.html>`__ --------------------- 2.3.4 is out the door --------------------- Python 2.3.4 has been released. Being a bugfix there are no new features. It is recommended that everyone upgrade to this version. Contributing threads: - `Python 2.3.4 schedule <http://mail.python.org/pipermail/python-dev/2004-May/044661.html>`__ - `release23-maint tree closed for 2.3.4rc1 <http://mail.python.org/pipermail/python-dev/2004-May/044771.html>`__ - `Python 2.3.4, release candidate 1 - BUG FIX <http://mail.python.org/pipermail/python-dev/2004-May/044854.html>`__ - `python 2.3.4 delayed for a week <http://mail.python.org/pipermail/python-dev/2004-May/044921.html>`__ - `2.3.4 release this thursday <http://mail.python.org/pipermail/python-dev/2004-May/044954.html>`__ - `ELEASED Python 2.3.4 (final) <http://mail.python.org/pipermail/python-dev/2004-May/044984.html>`__ ----------------------- IPv6 for Windows in 2.4 ----------------------- For those of you wanting IPv6 support on Windows in the binary build, you will get in 2.4 . The reason it isn't in 2.3.x is that the branch is compiled with VC 6 which can only compile in IPv6 support with a separate SDK. VC 7, on the other hand, does not have this issue. Contributing threads: - `IPv6 support in Win binary again <http://mail.python.org/pipermail/python-dev/2004-May/044779.html>`__ ----------------------- cookielib in the stdlib ----------------------- A module named cookielib was added to the stdlib to allow transparent handling of cookies for modules such as urllib2. Contributing threads: - `cookielib module in 2.4? <http://mail.python.org/pipermail/python-dev/2004-May/044785.html>`__ - `cookielib <http://mail.python.org/pipermail/python-dev/2004-May/045015.html>`__ ------------------------ cmp doesn't call __cmp__ ------------------------ It was pointed out that calling ``cmp(x,x)``` does not call ``x.__cmp__(x)`` but instead uses PyObject_RichCompareBool(). The issue with this is that PyObject_RichCompareBool() has a short-circuit for when the object being compared is the same, thus skipping a possible call to x.__cmp__ and saving some time. This can be an issue, though, if you want something other than True or False to be returned. Basically what came out of this thread was that C functions can short-circuit comparisons so be careful if you want to make sure that __cmp__ is called; use '==' and the other comparison operators instead. Contributing threads: - `cmp(x,x) <http://mail.python.org/pipermail/python-dev/2004-May/044885.html>`__ ---------------------------------- Posssible improvements to import.c ---------------------------------- Tim Peters asked if anyone knew the working details of import.c; no one spoke up. The question was brought up because Tim would like to see failed imports not lead to mangled modules being in sys.modules and thus being considered properly imported. The suggestion of also handling circular imports came up as well. Contributing threads: - `import.c <http://mail.python.org/pipermail/python-dev/2004-May/044998.html>`__

1 0

RE: [Python-Dev] Side by Side Differencing Patch
by Dan Gass June 14, 2004

June 14, 2004

Tim, >That said, I downloaded the zip file attached to your patch just now, and >was delighted by the examples of its output you included. I'd definitely >use this! OTOH, I'm not an HTML Guy, and unassigned myself -- I'm not the >best person to review it. I'm +1 on the concept, FWIW. > > > 1) Is this worthwhile functionality where it would be worth including it > > and supporting it in Python? > >Yes, I think so. The closest alternative I know of is the HTML-ized >diff'ing included in ViewCVS, which I believe also builds on difflib >functions. I like your output better, both because of the embedded "next >difference" links and because of the intraline difference marking. <clippedText/> >For purposes of getting the patch reviewed, it would help most if you: > >a) Generated an ordinary context-diff patch against current CVS Python. > >and > >b) Added a documentation patch. It doesn't need to be LaTeX -- if you > write new docs in plain text, the reviewers here are usually happy > to add the sometimes-mysterious markup needed to play well with > the Python doc-generation tools. Based on your positive response I'll go ahead and regenerate the patch with the current CVS Python code and redo the differences. This will allow me to address the issues discussed in the sourceforge patch (correctly handling files with no differences and improving the interface for dropping anchors) as well as a couple other really minor issues not documented anywhere. I'd appreciate feedback from other interested parties before I go nuts on writing good user documentation for the Python manuals. I hope there is an HTML guru interested in this as they may have better ideas for the HTML look, feel and functionality that may impact the interfaces I provide. Who worked on ViewCVS? Thanks for your positive feedback! Dan Gass _________________________________________________________________ Getting married? Find great tips, tools and the latest trends at MSN Life Events. http://lifeevents.msn.com/category.aspx?cid=married

2 1

VC 7.1 maintenance?
by Guido van Rossum June 14, 2004

June 14, 2004

Is anybody maintaining the project files for Visual Studio 7.1? In recent checkins a new file was added (pystrtod.c) that isn't included in the project file yet. I hesitate to make the checkin myself because I honestly don't understand which files are affected... --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Re: [Python-Dev] Bug day outcome
by Matthias Klose June 14, 2004

June 14, 2004

Barry Warsaw writes: > +1 on Subversion too, but I still say the biggest problem is finding the > cycles to set up and maintain the infrastructure. It was an > overwhelming task when we did it ourselves with a fraction of the user > and developer community, and I was glad when we moved to SF. If the > Gforge installation Andrew was talking about can really be set up and > babysat with as little effort as claimed, I think that's worth looking > into. you may want to check alioth.debian.org for a gforge setup supporting either cvs, subversion or arch.

1 0

Timing results for scope.py (was Re: Object finalization for local (ie function) scopes)
by Oliver Schoenborn June 13, 2004

June 13, 2004

I created two functions: one empty and one that opens a file and writes a line and closes it. I ran once without scope-guard, and once with for each. Short unscoped (us): 17.485010669 Short and scoped (us): 72.8106022384 Long unscoped (ms): 19.7690964161 Long and scoped (ms): 20.380344323 Here is the code with the tests: import sys def ScopeGuarded(func): return lambda *args, **kwargs: ScopeGuardian(func, *args, **kwargs) _funcStack = [] def ScopeGuardian(func, *args, **kwargs): try: scopedObjs = [] _funcStack.append(scopedObjs) func(*args, **kwargs) finally: _funcStack.pop() if scopedObjs != []: scopedObjs.reverse() # destroy in reverse order from creation for obj in scopedObjs: obj.finalizeMaster() def testTimingShort(scoped=False): def fastFun(): pass if scoped: fastFun = ScopeGuarded(fastFun) fastFun() def testTimingLong(scoped=False): def slowFun(): ff = file('asdfaf','w') ff.write('asdfaf') ff.close() if scoped: slowFun = ScopeGuarded(slowFun) slowFun() def testTiming(): from timeit import Timer tts = Timer('testTimingShort()', 'from __main__ import testTimingShort') ttss = Timer('testTimingShort(True)', 'from __main__ import testTimingShort') ttl = Timer('testTimingLong()', 'from __main__ import testTimingLong') ttls = Timer('testTimingLong(True)', 'from __main__ import testTimingLong') tms = tts.timeit(10000)*100 print "Short unscoped (us): ", tms tmss = ttss.timeit(10000)*100 print "Short and scoped (us):", tmss tml = ttl.timeit(100)*10 print "Long unscoped (ms): ", tml tmls = ttls.timeit(100)*10 print "Long and scoped (ms): ", tmls print "For long, scoped takes %s%% longer than unscoped" % ((tmls/tml-1)*100) if __name__ == '__main__': testTiming()

1 0

Re: [Python-Dev] An ability to specify start and length of slices
by Noam Raphael June 13, 2004

June 13, 2004

Ok, I quit... Thank you for your serious consideration of my proposal and for your suggestions! I think that, according to Duncan Booth's suggestion, I will write, for my own use, a function which gets start and length and returns a slice. Even though it wasn't accepted, making the patch and participating in the discussion was quite fun. And don't worry, I will continue to use Python - it's still the best computer language I know... Thanks again, Noam

1 0

Re: Python CVS docs - libposixpath.tex is wrong file!
by Fred L. Drake, Jr. June 11, 2004

June 11, 2004

On Monday 07 June 2004 08:00 pm, Mat Martineau wrote: > It looks like something went awry with sf.net CVS - somehow > libposixpath.tex (and all of its revision history) got swapped out > with a file from the "moodle" project. I've verified on separate > machines and clean CVS checkouts. The file CVS has been handing out > since this morning (at least) is attached - definitely not a LaTeX > file! > > Thought you'd want to know. Mat just alerted me to this screwed-up file in the Python CVS. Doing a "cvs log" on Doc/lib/libposixpath.tex shows an error in the repository: cvs [log aborted]: unexpected '\x0' reading revision number in RCS file /cvsroot/python/python/dist/src/Doc/lib/libposixpath.tex,v The most recent version of the file I can find on my disks (that isn't corrupt) is dated 16 April 2004. I've started looking through the snapshots at http://cvs.perl.org/snapshots/python/python/ for a more recent good copy, but I'd really like a good copy of the ,v from the repository itself. Does anyone have a recent copy of that? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

4 8

Re: python-dev archive searching ?
by Seo Sanghyeon June 11, 2004

June 11, 2004

Dave Harrison <dave <at> nullcube.com> writes: > Hi all, > > I've spent a bit of time looking for a way to search the python-dev > archives for topics, but I'm not having much success (unless I want to > trawl the archives by hand, month by month). > > Is there something I'm missing here ? Try http://search.gmane.org/ in group gmane.comp.python.devel. It works very well.

1 0