[Python-Dev] Deprecating divmod() // % for complex (original) (raw)

Andy Robinson andy@reportlab.com
Mon, 15 Apr 2002 16:34:10 +0100

-----Original Message----- From: python-dev-admin@python.org [mailto:python-dev-admin@python.org]On Behalf Of python-dev-request@python.org Sent: 15 April 2002 14:27 To: python-dev@python.org Subject: Python-Dev digest, Vol 1 #2152 - 16 msgs

Send Python-Dev mailing list submissions to python-dev@python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-request@python.org You can reach the person managing the list at python-dev-admin@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..." Today's Topics: 1. RE: A "new" kind of leak (Tim Peters) 2. Re: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58 (Tim Peters) 3. Re: Adding Optik to 2.3 standard library (Alex Martelli) 4. Re: Adding Optik to 2.3 standard library (Magnus Lie Hetland) 5. Re: A "new" kind of leak (Michael Hudson) 6. Re: Building on Windows (was Re: A "new" kind of leak) (Michael Hudson) 7. Re: Building on Windows (was Re: A "new" kind of leak) (Gustavo Niemeyer) 8. Re: Porting bug fixes (was A "new" kind of leak) (Michael Hudson) 9. Re: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58 (Guido van Rossum) 10. Deprecating divmod() // % for complex (Neal Norwitz) 11. Re: Building on Windows (was Re: A "new" kind of leak) (Guido van Rossum) 12. Re: Deprecating divmod() // % for complex (M.-A. Lemburg) 13. Re: Deprecating divmod() // % for complex (Guido van Rossum) 14. Re: Deprecating divmod() // % for complex (Neal Norwitz) 15. Re: Adding Optik to 2.3 standard library (Barry A. Warsaw) 16. Re: Re: Deprecating divmod() // % for complex (M.-A. Lemburg) ------ Message: 1 Date: Mon, 15 Apr 2002 00:07:33 -0400 From: Tim Peters <tim.one@comcast.net> Subject: RE: [Python-Dev] A "new" kind of leak To: python-dev@python.org >> An effective solution would be to bound the size of the frameobject >> free list: [Greg Ewing] > I don't think that's the right solution. Won't the same problem > occur with all the other kinds of free list as well? You'd have > to put bounds on all of them. tuple free lists were already bounded. Neil found what look to be the only other two possibilities in the core, but nobody has been able to provoke an actual leak out of them (this has already been gone over here, and I don't want to repeat it). > Seems to me the correct solution is to count allocs/frees from/to > any free list along with memory allocs/frees for the purpose of > deciding when to do a gc. This possibility was mentioned in the bug report, but would cost an extra call per allocation (please don't argue about that unless you're familiar with Python's gc code -- it's a tiny bug, and we're not going to do a massive rework). Since all possibilities require that vulnerable types do something they weren't doing before, right-vs-wrong doesn't appear a sensible axis along which to measure; bounding the free list is an easy change to a vulnerable type's dealloc routine.

------ Message: 2 Date: Mon, 15 Apr 2002 00:33:16 -0400 From: Tim Peters <tim.one@comcast.net> To: Guido van Rossum <guido@zope.com> Cc: PythonDev <python-dev@python.org> Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58 """ Update of /cvsroot/python/python/dist/src/Objects In directory usw-pr-cvs1:/tmp/cvs-serv7877 Modified Files: complexobject.c Log Message: SF bug #543387. Complex numbers implement divmod() and //, neither of which makes one lick of sense. Unfortunately this is documented, so I'm adding a deprecation warning now, so we can delete this silliness, oh, around 2005 or so. Bugfix candidate (At least for 2.2.2, I think.) """ Does it make sense to deprecate divmod() and // for complex numbers while leaving % intact? x % y == x - y * math.floor((x/y).real) makes exactly as much sense to me (approximately none) as x // y == math.floor((x/y).real) made. Python's definitions of % and // make great sense for integral types, but they start to fall apart for floats, and complexes are right out. ------ Message: 3 From: Alex Martelli <aleax@aleax.it> Organization: None in Sight To: barry@zope.com (Barry A. Warsaw) Subject: Re: [Python-Dev] Adding Optik to 2.3 standard library Date: Mon, 15 Apr 2002 09:36:43 +0200 Cc: python-dev@python.org On Monday 15 April 2002 12:18 am, you wrote: > >>>>> "GvR" == Guido van Rossum <guido@python.org> writes: > > GvR> To the contrary. Only problem is how to prevent loading all > GvR> of optik when one imports getopt.getopt (and getopt.error). > > Too bad modules can't have getattr's :) Wouldn't the same instance-as-module trick as in, e.g. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65207 let you make a "module-with-getattr" to most intents&purposes? Alex ------ Message: 4 Date: Mon, 15 Apr 2002 11:41:05 +0200 From: Magnus Lie Hetland <magnus@hetland.org> To: python-dev@python.org Subject: Re: [Python-Dev] Adding Optik to 2.3 standard library Barry A. Warsaw <barry@zope.com>: > > > >>>>> "GvR" == Guido van Rossum <guido@python.org> writes: > > GvR> To the contrary. Only problem is how to prevent loading all > GvR> of optik when one imports getopt.getopt (and getopt.error). > > Too bad modules can't have getattr's :) Well, you could always replace the module with an object that can... :) [snip] > > -Barry -- Magnus Lie Hetland The Anygui Project http://hetland.org http://anygui.org ------ Message: 5 To: python-dev@python.org Subject: Re: [Python-Dev] A "new" kind of leak From: Michael Hudson <mwh@python.net> Date: 15 Apr 2002 11:30:51 +0100 Tim Peters <tim.one@comcast.net> writes: > [Michael Hudson] > > For patches that > > > > cvs up -j blah -j blat file > > > > can handle, I have a setup that make porting them the work of seconds. > > It takes a little while to set up, so I batch them. > > Maybe waiting for a change to show up in the trunk is a better way to go. > Since I was making the trunk change "live", and wasn't going to check > anything in before everything worked on both trunk and branch, -j was > impotent (in the way I happened to do this). Regardless, it won't work for > this patch if it's desired in 2.1 (too much has changed). Yes, this particular patch was exceptional in several ways (eg. no chance of applying cleanly to 21-maint, being hard to test automatically, and affecting a particularly critical bit of code). I doubt many of that list apply to the majority of bugfixes (well, quite a few probably don't apply to 21-maint by now). Longer ramblings will appear in another thread in a moment. Cheers, M. -- If you don't have friends with whom to share links and conversation, you have social problems and you should confront them instead of joining a cultlike pseudo-community. -- "Quit Slashdot.org Today!" (http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq) ------ Message: 6 To: python-dev@python.org Subject: Re: [Python-Dev] Building on Windows (was Re: A "new" kind of leak) From: Michael Hudson <mwh@python.net> Date: 15 Apr 2002 11:39:16 +0100 Neil Schemenauer <nas@python.ca> writes: > Tim Peters wrote: > > The automation I've written beyond that is unique to me (which isn't > > good), and relies on batch run-capture-parse facilities supplied by my > > editor (which is worse, since I'm its only known user ). > > Source Insight? I tried it out yesterday. It looks pretty cool. If > they ported it to Linux (Qt?) I would consider spending the $250 for it. > Unfortunately it crashes under the latest version of Wine. I'm going to > have to look at cscope one of these days. cscope's occasionally handy. I find it unwieldy when you have source files spread among several directories (though this may be user stupidity), and TBH I know the bits of the Python source I regularly beat on well enough that I can usually find definitions as fast by hand/grep as I can with cscope. It's more useful when in unfamiliar territory. Cheers, M. -- The "of course, while I have no problem with this at all, it's surely too much for a lesser being" flavor of argument always rings hollow to me. -- Tim Peters, 29 Apr 1998 ------ Message: 7 Date: Mon, 15 Apr 2002 08:21:12 -0300 From: Gustavo Niemeyer <niemeyer@conectiva.com> To: Michael Hudson <mwh@python.net> Cc: python-dev@python.org Subject: Re: [Python-Dev] Building on Windows (was Re: A "new" kind of leak) > cscope's occasionally handy. I find it unwieldy when you have source > files spread among several directories (though this may be user I've created a vim plugin that looks for cscope.out in upper directories until it gets into the root directory. This way, you may just create the database recursively (cscope -b -R) in the root of the project, and everything will work fine. > stupidity), and TBH I know the bits of the Python source I regularly > beat on well enough that I can usually find definitions as fast by > hand/grep as I can with cscope. It's more useful when in unfamiliar > territory. Agreed. -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ] ------ Message: 8 To: python-dev@python.org Subject: Re: [Python-Dev] Porting bug fixes (was A "new" kind of leak) From: Michael Hudson <mwh@python.net> Date: 15 Apr 2002 13:22:26 +0100 Tim Peters <tim.one@comcast.net> writes: > [Michael Hudson] > > ... > > So what I'm suggesting is that if you want a checkin to be ported to > > release22-maint you should add a specific bit of text to the chickin > > message. Does this seem reasonable? > > Yes, but you have to Pronounce on which specific bit of text you want to > see. I realise this. It will probably be something along the lines of AutoPorter: 21, 22 (assuming you intend the fix to be applied to release21-maint and release22-maint). This obviously needs to be something everyone knows about, so I'll document it under www.python.org/dev in large friendly letters. It's also likely that this will result in an email back saying "do it yourself" if up -j can't do it (i.e. returns non-zero exit status). > It's going to get much more complicated if we intend to backport fixes > across 2 or 3 years of older releases. I predict that's not going to work > unless we establish an easy-to-update patch database recording which patches > have and haven't been applied to each old release, which should and > shouldn't be applied to each old release, and everyone is serious about > keeping that up to date. I've had similar thoughts. Maybe it's time to learn about CGI... > I'm not aware of any commerical organizations with full-time QA > departments that sign up for something so messy, and I'm not > sanguine about our prospects of pulling it off (the older the code, > the more likely "a bugfix" is to create at least as many problems as > it solves; and the more active branches, the more likely fixes to > get dropped on the floor). Indeed. > > Another random point: it would be nice if on checking a bugfix into > > HEAD people said if they planned to port the fix themselves. > > Otherwise I see the message that says "bugfix candidate", hit they key > > that copies it into my special bugfixes folder, then read on and find > > it's already been ported and have to go and find the copy and delete > > it. TIA. > > I already do all that stuff, so stop yelling at me . Well, I can't remember who has done this to me, but people have. > [Martin v. Loewis] > > If I'm going to commit the same patch onto the maintainance branch, I > > usually don't mark it as "bugfix candidate". If I can be awkward (and in fact, even if I can't ), I'd like to ask for more than that; sometimes people forget to mark bugfix candidates. So I'd like "I am going to check this in to the 22 branch". At least until I get more automation (at which point if you forget to mark your checkin, tough titties). Cheers, M. -- Screaming 14-year-old boys attempting to prove to each other that they are more 3133t than j00. -- Reason #8 for quitting slashdot today, from http://www.cs.washington.edu/homes/klee/misc/slashdot.html ------ Message: 9 To: Tim Peters <tim.one@comcast.net> cc: PythonDev <python-dev@python.org> From: Guido van Rossum <guido@python.org> Date: Mon, 15 Apr 2002 08:44:32 -0400 Subject: [Python-Dev] Re: [Python-checkins] python/dist/src/Objects complexobject.c,2.57,2.58 [Tim] > Does it make sense to deprecate divmod() and // for complex numbers while > leaving % intact? It doesn't, and I've repaired this. However, I'm wondering what to do after we unify all numeric types (if we ever decide to do that, which isn't clear). At that point, should these operators be allowed as long as the imaginary part is zero? --Guido van Rossum (home page: http://www.python.org/~guido/) ------ Message: 10 Date: Mon, 15 Apr 2002 08:50:24 -0400 From: Neal Norwitz <neal@metaslash.com> Organization: MetaSlash, Inc. To: Guido van Rossum <guido@python.org> CC: Tim Peters <tim.one@comcast.net>, PythonDev <python-dev@python.org> Subject: [Python-Dev] Deprecating divmod() // % for complex Guido van Rossum wrote: > > [Tim] > > Does it make sense to deprecate divmod() and // for complex numbers while > > leaving % intact? > > It doesn't, and I've repaired this. Does it make sense to expand PEP 4 or make a new PEP to point out all these other features which are also deprecated? This would include classes/methods/functions, etc. Neal ------ Message: 11 To: Michael Hudson <mwh@python.net> cc: python-dev@python.org Subject: Re: [Python-Dev] Building on Windows (was Re: A "new" kind of leak) From: Guido van Rossum <guido@python.org> Date: Mon, 15 Apr 2002 08:57:23 -0400 > TBH I know the bits of the Python source I regularly > beat on well enough that I can usually find definitions as fast by > hand/grep as I can with cscope. Don't people use TAGS or tags any more? Works for me (in Emacs). Just say "make TAGS" every once in a while. --Guido van Rossum (home page: http://www.python.org/~guido/) ------ Message: 12 Date: Mon, 15 Apr 2002 15:02:45 +0200 From: "M.-A. Lemburg" <mal@lemburg.com> Organization: eGenix.com Software GmbH To: Neal Norwitz <neal@metaslash.com> CC: Guido van Rossum <guido@python.org>, Tim Peters <tim.one@comcast.net>, PythonDev <python-dev@python.org> Subject: Re: [Python-Dev] Deprecating divmod() // % for complex Neal Norwitz wrote: > > Guido van Rossum wrote: > > > > [Tim] > > > Does it make sense to deprecate divmod() and // for complex numbers while > > > leaving % intact? > > > > It doesn't, and I've repaired this. > > Does it make sense to expand PEP 4 or make a new PEP to > point out all these other features which are also deprecated? IMHO, it does. > This would include classes/methods/functions, etc. Plus, a section which covers the C API. All entries should include the reasoning and explain ways to upgrade old code or what to do in order to maintain backward compatibility to run old code without change (e.g. to install a backward compatibility add-on distutils package). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH

Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

------ Message: 13 To: Neal Norwitz <neal@metaslash.com> cc: Tim Peters <tim.one@comcast.net>, PythonDev <python-dev@python.org> From: Guido van Rossum <guido@python.org> Date: Mon, 15 Apr 2002 09:10:54 -0400 Subject: [Python-Dev] Re: Deprecating divmod() // % for complex > Guido van Rossum wrote: > > > > [Tim] > > > Does it make sense to deprecate divmod() and // for complex numbers while > > > leaving % intact? > > > > It doesn't, and I've repaired this. > > Does it make sense to expand PEP 4 or make a new PEP to > point out all these other features which are also deprecated? > This would include classes/methods/functions, etc. > > Neal Unclear what the value is. Deprecations are systematically listed in the documentation AFAIK. --Guido van Rossum (home page: http://www.python.org/~guido/) ------ Message: 14 Date: Mon, 15 Apr 2002 09:16:42 -0400 From: Neal Norwitz <neal@metaslash.com> Organization: MetaSlash, Inc. To: Guido van Rossum <guido@python.org> CC: Tim Peters <tim.one@comcast.net>, PythonDev <python-dev@python.org> Subject: [Python-Dev] Re: Deprecating divmod() // % for complex Guido van Rossum wrote: > > > Guido van Rossum wrote: > > > > > > [Tim] > > > > Does it make sense to deprecate divmod() and // for complex numbers while > > > > leaving % intact? > > > > > > It doesn't, and I've repaired this. > > > > Does it make sense to expand PEP 4 or make a new PEP to > > point out all these other features which are also deprecated? > > This would include classes/methods/functions, etc. > > Unclear what the value is. Deprecations are systematically listed in > the documentation AFAIK. So the APIs and doc can be removed. Here's the current list, found by a lot of grepping in the Python modules: htmllib.HTMLParser.donextid() pty.masteropen() pty.slaveopen() pstats.Stats.ignore() rfc822.AddrlistClass string.zfill() Cookie.Cookie() # parameter usage change There are probably others in the C modules. Neal ------ Message: 15 Date: Mon, 15 Apr 2002 09:19:39 -0400 To: Alex Martelli <aleax@aleax.it> Cc: python-dev@python.org Subject: Re: [Python-Dev] Adding Optik to 2.3 standard library From: barry@zope.com (Barry A. Warsaw) >>>>> "AM" == Alex Martelli <aleax@aleax.it> writes: AM> Wouldn't the same instance-as-module trick as in, e.g. AM> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65207 AM> let you make a "module-with-getattr" to most AM> intents&purposes? Yes, nice. Okay, I'll work something up and submit it as a patch to the Optik project on SF. Then Greg can fiddle with it and check it in if he likes it. >>>>> "MM" == Michael McLay <mjm42@comcast.net> writes: MM> Pmw (Python Megawidgets, http://pmw.sourceforge.net/) has a MM> lazy loader. It is loaded by init.py when the Pmw package MM> is loaded. The loader is in Pmw/Pmw085/lib/PmwLoader.py Perhaps we should automatically add the PEPs to the standard Python documentation as well ?! Some duplication of this information is necessary to increase visibility, IMHO, esp. for those of us who don't regularly read the docs.

I for one would find this really handy and interesting. It kind of puts PEPs into the "read-about-Python's-history -in-an-armchair" category rather than requiring active lookup. Think of it as one more manual indexed on the main docco page.