> -----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 <wink>). > > > > 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 <wink>. > > 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 <wink>), 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.do_nextid() > pty.master_open() > pty.slave_open() > 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/Pmw_0_8_5/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. - Andy Robinson
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4