Mailman 3 November 2003 - Python-Dev

operator.isMappingType
by Raymond Hettinger Nov. 8, 2003

Nov. 8, 2003

>>> import operator >>> map(operator.isMappingType, [(), [], '', u'', {}]) [True, True, True, True, True] We did not resolve this when it came up before. Would there be any objections to my removing operator.isMappingType()? Raymond Hettinger

2 1

SourceForge CVS services improved
by Martin v. Löwis Nov. 8, 2003

Nov. 8, 2003

In case you haven't read this announcement: <quote> ( 2003-11-04 09:51:53 - Project CVS Service ) Cutover of pserver-based CVS service and ViewCVS access to repositories to the new CVS infrastructure has been completed. Synchronization of data from the primary CVS server to the new CVS infrastructure now occurs every 5 hours (formerly once per day). Performance of pserver-based CVS access and ViewCVS access has been significantly improved; connection shedding (formerly used to cap the … [View More]

1 0

RE: [Python-Dev] Deprecating obsolete builtins
by Delaney, Timothy C (Timothy) Nov. 7, 2003

Nov. 7, 2003

> From: Guido van Rossum [mailto:guido@python.org] > > > > > So I'd actually advocate enhancing intern(), rather > than removing > > > > it, now that interned things are mortal. > > > > > > Have you thought about how to implement that? And have > you calculated > > > how much memory you would save? > > > > Not yet - musings at the end of the day. As to how much memory - I > > really don't think it can be … [View More]

3 2

check-in policy, trunk vs maintenance branch
by Alex Martelli Nov. 7, 2003

Nov. 7, 2003

I made a few bugfix check-ins to the 2.3 maintenance branch this weekend and Michael Hudson commented that he thinks that so doing is a bad idea, that bug fixes should filter from the 2.4 trunk to the 2.3 branch and not the other way around. Is this indeed the policy (have I missed some guidelines about it)? I guess for this round of fixes I will find the time to forward-port them to the 2.4 trunk (in AMPLE time for a 2.4 release -- as 2.3.3 is going to come well before 2.4 releases, the … [View More]

11 15

Re: [Python-checkins] python/dist/src/Doc/lib libtraceback.tex, 1.17, 1.18
by Thomas Heller Nov. 6, 2003

Nov. 6, 2003

nascheme(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Doc/lib > In directory sc8-pr-cvs1:/tmp/cvs-serv27582/Doc/lib > > Modified Files: > libtraceback.tex > Log Message: > Add traceback.format_exc(). > > > Index: libtraceback.tex > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Doc/lib/libtraceback.tex,v > retrieving revision 1.17 > retrieving revision 1.… [View More]

2 1

test warnings for "%x"%id(foo) on 2.3 branch
by Anthony Baxter Nov. 5, 2003

Nov. 5, 2003

I'm seeing a couple of warnings that I don't remember seeing at the time of the 2.3.2 release. Given what they are, it's possible that it's just a random thing (whether the id is < 0 or not). test_minidom /home/anthony/src/py/23maint/Lib/xml/dom/minidom.py:797: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up return "<DOM Element: %s at %#x>" % (self.tagName, id(self)) test_repr /home/anthony/src/py/23maint/Lib/test/test_repr.py:91: … [View More]

4 6

Re: [Python-Dev] accumulator display syntax
by Skip Montanaro Nov. 5, 2003

Nov. 5, 2003

Greg> What you're proposing hijacks the indexing syntax and uses it to Greg> mean something completely different from indexing, which is a much Greg> bigger change, and potentially a very confusing one. Greg> So, no, sorry, it doesn't overcome my objection! I agree. Any expression bracketed by '[' and ']', no matter how many other clues to the ultimate result it might contain, ought to result in a list as far as I'm concerned. Skip

35 332

RE: [Python-Dev] Deprecating obsolete builtins
by Delaney, Timothy C (Timothy) Nov. 5, 2003

Nov. 5, 2003

> From: Aahz [mailto:aahz@pythoncraft.com] > > > > So I'd actually advocate enhancing intern(), rather than > > removing it, now that interned things are mortal. > > Agreed. But intern() should *not* be a builtin function. It > belongs in sys. Hmm - not so sure about sys, but I agree it could quite well be moved out of builtins. I don't feel it belongs in sys because it has nothing to do with the environment that python is running in. Instead it has to do … [View More]

1 0

RE: [Python-Dev] Deprecating obsolete builtins
by Delaney, Timothy C (Timothy) Nov. 5, 2003

Nov. 5, 2003

> From: Neal Norwitz [mailto:neal@metaslash.com] > > For the most part, I meant to remove them (including intern) > altogether in the long run. In 2.4, I only meant to officially > deprecate them with a warning. intern() doesn't seem particularly > useful or commonly used. At least moving it to sys or some other > module is an improvement IMO. One reason why intern() hasn't been commonly used is that it made things immortal. This is no longer the case - I'd like to see … [View More]

2 1

RE: [Python-Dev] Re: PEP 322: Reverse Iteration
by Moore, Paul Nov. 5, 2003

Nov. 5, 2003

From: Guido van Rossum [mailto:guido@python.org] >> 1. Add a plain irange() to itertools. >> 2. IF the general reversed() is deemed too theoretical, add EITHER a >> reverse argument to irange, or an irevrange to itertools. Both feel >> to me a little iffy, but that's my generality bias again. >> 3. IF the general reversed() is accepted (builtin or not) leave the >> irange function in its simple form. > Hm. reversed(irange(...)) can't work, so … [View More]

6 11