Python-Dev November 2000

python-dev@python.org

56 participants
128 discussions

Re: [Python-Dev] surprising bug in s.capitalize()?
by Michael Hudson 30 Nov '00

30 Nov '00

barry(a)digicool.com (Barry A. Warsaw) writes: > I was just surprised by something I've never observed before from > string.capitalize(). There is clearly either a bug (really two) in > the code or in the documentation. > > >>> '__Myfoo'.capitalize() > '__myfoo' > > Huh? The documentation says: > > capitalize () > Return a copy of the string with only its first character capitalized. > > So it's only doing one of the three things it's promising! For one > thing, it's modifying something other than the first character, and > for another, it's actually swapping the case of the character it /is/ > changing. At least it returns a copy. :) >>> 'AaAaAa'.capitalize() 'Aaaaaa' That's not a ridiculous reading of the above docs. It all depends whether you think "being capitalized" is a property or an action, I guess. > Given the documentation, I would have expected the return value to be > the same as the original string, i.e. unchanged. I would probably have expected that, too. But I'm not really sure why. > So which is it? Does the description of the method need to be made > more complicated, or does the code need to be simplified <wink>? Clarifying the docs won't break any code. Not sure that changing the code will much, either. Oooh, here's something a bit more serious though: >>> u'aAaAaA'.capitalize() u'AAaAaA' Something obviously Needs To Be Done. My hunch is to change string_capitalize, but that may be just me (and probably Barry). Cheers, M. -- Famous remarks are very seldom quoted correctly. -- Simeon Strunsky

2 1

Re: [Python-checkins] CVS: python/dist/src/Objects dictobject.c,2.65,2.66
by Guido van Rossum 30 Nov '00

30 Nov '00

Aargh! I thought I told you to submit a patch (to SF), not to check it in. The code looks okay but we'll have to discuss whether we really want all three (as opposed to only firstitem()). I'm also not sure whether KeyError might be a better exception. Don't touch it for now, but let's think this over a bit. --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Re: [Python-Dev] {}.getitem() (was Re: PEP-0218)
by Michael Hudson 30 Nov '00

30 Nov '00

Guido van Rossum <guido(a)python.org> writes: > > M.-A. Lemburg: > > > Shouldn't be hard to do... the C API for this is already in place: > > > PyDict_Next(). I'd prefer a method .getitem(), though, which then > > > returns a tuple (key, value). > > > > IMO '.pickitem()' would be a better name, since many people would > > think, that 'getitem()' would take some kind of index as parameter. > > Nevertheless I think this is a nice idea, though. > > Pronouncement: > > It is only efficient to get the *first* item, so let's make that > explicit. The method names will be: > > .firstkey() > .firstvalue() > .firstitem() > > Moshe will check in a patch. > > Thinking aloud: > > Would it be useful to also implement popkey(), popvalue(), popitem(), > which would remove the first item and then return the relevant part of > it? I must admit I can't think of a situation where .firstkey would be more useful than .popkey; I thought that this discussion was discussion was inspired by the wish to write code like: while not set.empty(): x = set.popfirstkey() ... Maybe I'm jsut being dense, though. FWIW, I think dict.firstkey() reads better than dict.firstitem()[0] if the former's what you're actually trying to say. Why not write for k,_ in dict.items(): ... ? (Overstating the case slightly for effect, but I hope the point is clear). Cheers, M. -- Arrrrgh, the braindamage! It's not unlike the massively non-brilliant decision to use the period in abbreviations as well as a sentence terminator. Had these people no imagination at _all_? -- Erik Naggum, comp.lang.lisp

4 5

Re: [Python-Dev] {}.getitem() (was Re: PEP-0218)
by Michael Hudson 30 Nov '00

30 Nov '00

"M.-A. Lemburg" <mal(a)lemburg.com> writes: > Michael Hudson wrote: > > I must admit I can't think of a situation where .firstkey would be > > more useful than .popkey; I thought that this discussion was > > discussion was inspired by the wish to write code like: > > > > while not set.empty(): > > x = set.popfirstkey() > > ... > > > > Maybe I'm jsut being dense, though. > > Just curious: how would you get at the deleted value when > using .popfirstkey() ? You wouldn't. I was thinking of the dict-as-sets code that was being flung around earlier. > But you have a point: dict.pop() returning the first filled slot > in the dictionary as tuple (key,value) would probably be most > effective. It's also nice and short. Yes. > > FWIW, I think > > > > dict.firstkey() > > > > reads better than > > > > dict.firstitem()[0] > > > > if the former's what you're actually trying to say. Why not write > > > > for k,_ in dict.items(): > > ... > > > > ? (Overstating the case slightly for effect, but I hope the point is > > clear). > > No, the point is that you can modify the dictionary within > the loop. You wouldn't see any changes using the second technique. I was trying to make an analogy between .firstkey/.firstitem and .keys/.items - the for k,_ in dict.items(): ... was meant to be compared to for k in dict.keys(): ... Sorry for being obscure. Cheers, M. -- "declare"? my bogometer indicates that you're really programming in some other language and trying to force Common Lisp into your mindset. this won't work. -- Erik Naggum, comp.lang.lisp

1 0

Python track--O'Reilly Open Source Convention
by Guido van Rossum 30 Nov '00

30 Nov '00

Laura Lewin is looking for chairs for two Python tracks (or a Python track and a Zope track) at the O'Reilly conference. Anybody interested in volunteering? Some background info: > We actually have two tracks, and there's room for strong differentiation > between the two. Each track has a room for two days. We'll also want > tutorials on the Monday and Tuesday. > > Like O'Reilly's books, we're not really aimed at the novice. We want to > give people who already use the technology more information. There should > be at least one introductory tutorial, but we don't want to focus > exclusively on that. However, if you, as Chair, have a vision for what you > want O'Reilly's conference to be, we'd be very happy to work with you to > realize that vision. > > This year we're trying to raise the bar on our Python and Zope offerings. > We'd like to have a lot of editorial involvement from a program committee, > so that potential speakers have a chance to get their talks reviewed and > commented-upon by others. > > The program chair would really be the point person for the conference, to > drum up papers and help publicize the conference to the Python community. > The chair would appoint a committee, receive submissions, select > presentations, seek out talks from people who > didn't submit, and generally put together the material. > > We can handle any combination of program committees and chairs: one person > overseeing two committees, two chairs two committees, whatever gets it all > done. > > Does this sound like a job you're interested in? It doesn't pay, but it > would be great for the Python community, as I'm sure you know. For more info, please write or call Laura Lewin LLewin(a)oreilly.com (631) 262-9278. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

[development doc updates]
by Fred L. Drake 30 Nov '00

30 Nov '00

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Today's changes are primarily in the xml.dom API documentation: http://python.sourceforge.net/devel-docs/lib/markup.html

1 0

long formatting
by bckfnn＠worldonline.dk 30 Nov '00

30 Nov '00

Hi, While adding support to Jython for formatting of longs in "%[duxXo]", I inadvertently introduced another difference between Python and Jython: Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> print '%030o' % -10L 000000000000000000037777777766 >>> Jython 2.0alpha1 on java1.3.0 (JIT: null) Type "copyright", "credits" or "license" for more information. >>> print '%030o' % -10L -00000000000000000000000000012 >>> The CPython behaviour looks as if the number have been through a C long before it is formatted. It that intended? Would jython be wrong if it used the result above? regards, finn

3 3

Re: long formatting
by Guido van Rossum 30 Nov '00

30 Nov '00

I just skimmed the pipermail python-dev archives and found one item to pronounce on: what "%o" should do with negative longs. I agree with Tim. Also for "%x". Reason: this matches oct() and hex(). >>> oct(-10L) '-012L' >>> oct(-10) '037777777766' >>> hex(-10L) '-0xAL' >>> hex(-10) '0xfffffff6' >>> Compatibility be damned (in this case). (One could argue that for plain ints, the same result are desirable; however when these are used as bitmasks, I as human reader prefer to see '0xfffffff6' rather than '-0xA'. Ah the insanity of consistency!) --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Mail to guido@python.org lost or delayed
by Guido van Rossum 30 Nov '00

30 Nov '00

Folks, mail to guido(a)python.org may have been bouncing or dropped in a black hole, since approximately 12:40 pm EST today -- due to a mail server problem at my ISP (@home.com -- fast reliable cable bandwidth but lousy mail and DNS service). I found out about this and *thought* I had fixed it by switching to guido(a)digicool.com, but in fact there was still a forward to @home.com in effect. I just finally fixed that (around 10:10 pm EST). You don't need to change the email address you have for me: guido(a)python.org is still the preferred address. However if you sent me mail between the approximate times above, I probably haven't seen it yet. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

PEP-0218
by Moshe Zadka 30 Nov '00

30 Nov '00

Well, another proof of the bugs in the PEP process -- my remarks were lost, so I'll send them here. Let me note that almost everything Greg Wilson wants to do can be done via a Python class implementing a set using a dictionary mapping to None. Almost? * No builitin syntax: import Set;Set(1,2,3) instead of {1,2,3} * Convertors: if we want list/tuple to have a semblance of efficiency, we'll need to cache the element list as a list when accessed by index. * Two different constructors: set() for building from sequence, Set() for building from elements. Might be confusing. * Only possible elements of a set are immutables. OTOH, I'm not sure how Greg intends to implement his sets if these sets are allowed to contain mutable elements. -- Moshe Zadka <sig(a)zadka.site.co.il> This is a signature anti-virus. Please stop the spread of signature viruses!

9 13

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev November 2000