Mailman 3 June 2002 - Python-Dev

proposed patch
by David Abrahams 20 Jun '02

20 Jun '02

I suggested: "What about making a public interface to apply_slice() and assign_slice() which I can call in the future? Perhaps PyObject_Get/Set/DelSlice()?" If I submitted such a patch would it be likely to be accepted? I don't want to waste my time on this if it's a bad idea. -Dave +---------------------------------------------------------------+ David Abrahams C++ Booster (http://www.boost.org) O__ == Pythonista (http://www.python.org) c/ /'_ == resume: http://users.rcn.com/abrahams/resume.html (*) \(*) == email: david.abrahams(a)rcn.com +---------------------------------------------------------------+

1 0

RE: [Python-Dev] Re: PEP 292, Simpler String Substitutions
by Delaney, Timothy 20 Jun '02

20 Jun '02

> From: Patrick K. O'Brien [mailto:pobrien@orbtech.com] > > Definitely. And habit. Since I program mostly in Python I'm used to {} > meaning dictionary and I'm used to typing parens everywhere In that case you should be happy. ${} is using a dictionary as its source ... Actually, for consistency, it should probably be $[] to suggest accessing a dictionary element. But I won't go down that path ;) Tim Delaney

1 0

RE: [Python-Dev] PEP 292, Simpler String Substitutions
by Damien Morton 20 Jun '02

20 Jun '02

LOL. Youre right of course :) `...` is already in python though. Better to generalise and/or extend an already existing construct than to add a new one, I would assert. Youre also right about `...` being less visible than other pairs of delimiters. I think, though, that if modifying the % notation, that the requirement should be for delimiters that are not parentheses, and ones that wouldn't interfere with putting expressions between them. This would allow for eval()ing the content between the delimiters. > -----Original Message----- > From: guido(a)pcp02138704pcs.reston01.va.comcast.net > [mailto:guido@pcp02138704pcs.reston01.va.comcast.net] On > Behalf Of Guido van Rossum > Sent: Thursday, 20 June 2002 00:08 > To: Damien Morton > Subject: Re: [Python-Dev] PEP 292, Simpler String Substitutions > > > > I stand by my position though. Ive been programing for a long time, > > and I have rarely come across the $ notation. Mind you, I > don't work > > in unix very often, and I would hazard a guess that the $ > substitution > > comes mainly from unix. > > So does `...`. :-) > > --Guido van Rossum (home page: http://www.python.org/~guido/) >

2 1

Re: [Python-Dev] PEP 292, Simpler String Substitutions
by Paul Prescod 20 Jun '02

20 Jun '02

"Barry A. Warsaw" wrote: > >... The mapping argument is optional; if it is omitted then the > mapping is taken from the locals and globals of the context in > which the .sub() method is executed. For example: > > def birth(self, name): > country = self.countryOfOrigin['name'] > return '${name} was born in ${country}' > > birth('Guido') You forgot the "implicit .sub"() feature. >... > - We can simply allow the exception (likely a NameError or > KeyError) to propagate. Explicit! > - We can return the original substitution placeholder unchanged. Silently guess??? Overall it isn't bad...it's a little weird to have a method that depends on sys._getframe(1) (or as the say in Tcl-land "upvar"). It may set a bad precedent... Paul Prescod

4 6

RE: [Python-Dev] PEP 292, Simpler String Substitutions
by Delaney, Timothy 20 Jun '02

20 Jun '02

> From: Guido van Rossum [mailto:guido@python.org] > > > > > There's a lot of empirical evidence that %(name)s is quite error > > > > prone. > > > > > > Perhaps an unadorned %(name) should default to %(name)s? > > Ambiguous, hence even more error-prone. Fair enough. I couldn't off the top of my head think of an ambiguous case, but of course there's '%(thing)s'ly-yours' ... PyChecker2 should *definitely* include checking format strings IMO, irrespective of whether $ formatting gets in. But only as a warning (because of the above case). Tim Delaney

3 2

Re: PEP 292, Simpler String Substitutions
by Ka-Ping Yee 20 Jun '02

20 Jun '02

On Tue, 18 Jun 2002, Barry A. Warsaw wrote: > def birth(self, name): > country = self.countryOfOrigin['name'] > return '${name} was born in ${country}' > > birth('Guido') > > returns > > 'Guido was born in the Netherlands' I assume you in fact meant return '${name} was born in ${country}'.sub() for the third line above? > print s.sub({'name': 'Guido', > 'country': 'the Netherlands'}) Have you considered the possibility of accepting keyword arguments instead? They would be slightly more pleasant to write: print s.sub(name='Guido', country='the Netherlands') This is motivated because i imagine relative frequencies of use to be something like this: 1. sub() [most frequent] 2. sub(name=value, ...) [nearly as frequent] 3. sub(dictionary) [least frequent] If you decide to use keyword arguments, you can either allow both keyword arguments and a single dictionary argument, or you can just accept keyword arguments and people can pass in dictionaries using **. -- ?!ng

4 4

RE: [Python-Dev] PEP 292, Simpler String Substitutions
by Delaney, Timothy 20 Jun '02

20 Jun '02

> From: barry(a)zope.com [mailto:barry@zope.com] > > >>>>> "GvR" == Guido van Rossum <guido(a)python.org> writes: > > GvR> That's a matter of validating the template before accepting > GvR> it. > > True, which isn't hard to do. You can write a regexp to extract the > $names and then validate those. In fact, I think this is what newer > versions of xgettext do for Python code (albeit with the %(name)s > syntax). Of course, once you've validated a string, it's almost no extra work to do the interpolation in place (at least in source code size). Tim Delaney

1 0

PEP 8: Lists/tuples
by Aahz 19 Jun '02

19 Jun '02

I don't really want to open a can of worms here, but as I'm finishing up my OSCON slides, I remembered a conversation earlier where Guido said that tuples should be used for heterogeneous items (i.e. lightweight structs) while lists should be used for homogeneous items. Should this preference be enshrined in PEP 8? (I'm -1 myself, but I'd like to know what to tell my class.) -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ Project Vote Smart: http://www.vote-smart.org/

3 2

Re: making dbmmodule still broken
by Skip Montanaro 19 Jun '02

19 Jun '02

Guido> On my 2yo Mandrake 8.1 (?) system, when I do "make" in the latest Guido> CVS tree, I always get an error from building dbmmodule.c: Okay, in between ringing up credit card charges I took another look at building the dbm module. I can't cvs diff at the moment, but here's what I propose (and what changes I just made locally): * Remove the ndbm.h and gdbm/ndbm.h checks from configure.in and run autoconf. * Change the block of code in setup.py that checks for dbm libraries and include files to if platform not in ['cygwin']: if (self.compiler.find_library_file(lib_dirs, 'ndbm') and find_file("ndbm.h", inc_dirs, []) is not None): exts.append( Extension('dbm', ['dbmmodule.c'], define_macros=[('HAVE_NDBM_H',None)], libraries = ['ndbm'] ) ) elif (self.compiler.find_library_file(lib_dirs, 'gdbm') and find_file("gdbm/ndbm.h", inc_dirs, []) is not None): exts.append( Extension('dbm', ['dbmmodule.c'], define_macros=[('HAVE_GDBM_NDBM_H',None)], libraries = ['gdbm'] ) ) elif db_incs is not None: exts.append( Extension('dbm', ['dbmmodule.c'], library_dirs=[dblib_dir], include_dirs=db_incs, define_macros=[('HAVE_BERKDB_H',None), ('DB_DBM_HSEARCH',None)], libraries=dblibs)) This does two things. It removes the else clause which would never have worked (no corresponding include files would have been found). It also performs the two include file tests I removed from configure.in and defines the appropriate macros. Building after making these changes I get gdbm. If I mv gdbm/ndbm.h out of the way or comment out the first elif branch I get Berkeley DB. I don't have an ndbm library on my system, so I can't exercise the first branch. I think it would probably be a good idea to alert the person running make what library the module will be linked with. Anyone else agree? Skip

3 4

Re: [Python-Dev] extended slicing again
by Michael Hudson 19 Jun '02

19 Jun '02

Michael Hudson <mwh(a)python.net> writes: > Guido van Rossum <guido(a)python.org> writes: > > > IOW slice(a, b, None) should be considered equivalent to L[a:b] in all > > situations. > > OK. I'll do this soon. It's not as bad as I thought at first -- only > mutable sequences are affected, so it's only lists and arrays that > need to be tweaked. That was easy! Cheers, M. -- I have no disaster recovery plan for black holes, I'm afraid. Also please be aware that if it one looks imminent I will be out rioting and setting fire to McDonalds (always wanted to do that) and probably not reading email anyway. -- Dan Barlow

1 0