[Python-Dev] Deprecating divmod() // % for complex
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 <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