Mailman 3 November 2002 - Python-Dev

Re: PyMem_MALLOC (was [Python-Dev] Snake farm)
by Tim Peters 22 Nov '02

22 Nov '02

[Marc Recht] > What about changing > PyMem_MALLOC malloc > to > #define PyMem_MALLOC(n) n ? malloc(n) : NULL No, but expanding to malloc(n || 1) or malloc(n ? n : 1) would be fine. Code in Python uses a NULL return as an indication that a memory operation failed, so returning NULL is never appropriate for a PyMem_Malloc(0) call -- the Python API guarantees that its memory functions return NULL to mean out-of-memory, and that 0 is an OK argument. The configuration cruft should go away here. It's proven itself too brittle too many times. That is, we should pretend that all platforms are insane, and never pass 0 to any platform's malloc or realloc.

2 1

Anon CVS
by Michael Gilfix 22 Nov '02

22 Nov '02

Just tried to anon out the python CVS tree off of SF and got: bash-2.05a$ cvs -d:pserver:anonymous@cvs.python.sourceforge.net:/cvsroot/python login Logging in to :pserver:anonymous@cvs.python.sourceforge.net:2401/cvsroot/python CVS password: cvs login: authorization failed: server cvs.python.sourceforge.net rejected access to /cvsroot/python for user anonymous Anybody else having this problem? Or is it just my end? -- Mike -- Michael Gilfix mgilfix(a)eecs.tufts.edu For my gpg public key: http://www.eecs.tufts.edu/~mgilfix/contact.html

5 6

Re: [Python-Dev] --disable-unicode, again
by Michael Hudson 22 Nov '02

22 Nov '02

"Fredrik Lundh" <fredrik(a)pythonware.com> writes: > Michael Hudson wrote: > > > I think I've asked this before, but does anyone use this build? > > Should I spend some time patching things up -- again -- or ripping > > --disable-unicode support out. *I* don't care about it. > > you missed the third option: since you don't care, don't do anything. That's what I'd been doing since it broke a couple of months back. > isn't the idea that "the first one who really needs this has to fix it"? Maybe, but having a configure option so conspicuously broken seemed a bit embarrassing. I also got tired of the failure reports from my cronjob every night -- got a couple of warnings last night, but it built. > (adding a comment along those lines to the right place might be a > good idea, though...) Where is the right place? It had occurred to me to stencil "don't forget the --disable-unicode build!" along the top of every Python developer's monitor, but that didn't seem practical. Cheers, M. -- I have a cat, so I know that when she digs her very sharp claws into my chest or stomach it's really a sign of affection, but I don't see any reason for programming languages to show affection with pain. -- Erik Naggum, comp.lang.lisp

2 1

Re: [Python-Dev] release22-maint branch broken
by Michael Hudson 22 Nov '02

22 Nov '02

Tim Rice <tim(a)multitalents.net> writes: > I pulled the release22-maint branch today and tried to build on UnixWare 7 > It looks like changes to setup.py and Lib/distutils/sysconfig.py > broke the build. Oops. > At least if there is no pre existing python installed. Well, if was reading the previous Python's config, that would be broken too. Can you work out why Lib/distutils/sysconfig.py isn't setting python_build? I suggest some debugging 'print's. Cheers, M. -- I've even been known to get Marmite *near* my mouth -- but never actually in it yet. Vegamite is right out. UnicodeError: ASCII unpalatable error: vegamite found, ham expected -- Tim Peters, comp.lang.python

1 0

Returning objects in Tkinter
by martin＠v.loewis.de 22 Nov '02

22 Nov '02

I'd like to integrate python.org/sf/518625 in some form into Python 2.3. If it is unacceptable in its current form, could I apply it if I change the default to "not return objects"? Regards, Martin

1 0

dict() enhancement idea?
by Just van Rossum 22 Nov '02

22 Nov '02

I sometimes use an idiom like def dictfromkeywords(**kwargs): return kwargs d = dictfromkeywords( akey = 12, anotherkey = "foo", ...etc. ) to conveniently build dicts with literal keys. I think I've seen Alex Martelli advertise it, too. Don't know how well known it is otherwise, but it is extremly handy. It just occured to me that the dict constructor could easily be overloaded with this behavior: it currently takes no keyword arguments[*], so the kwargs dict could simply be used to initialize the new dict. Has this been proposed before? Can't seem to find any reference to it. I could try to make a patch if people think this is a good idea. [*] caveat: dict_new() currently _does_ take one keyword argument "items", using it is the same as simply passing one arg to dict(). It seems to suggest a (key, value) list, though, but strangely it also works for dicts: >>> d = {1: 2, 3: 4} >>> dict(items=d) {1: 2, 3: 4} >>> However, this "items" keyword arg is not documented, and together with the above oddity I suggest to simply get rid of it. Just

7 9

Re: [Python-Dev] Yet another string formatting proposal
by Oren Tirosh 21 Nov '02

21 Nov '02

On Thu, Nov 21, 2002 at 05:00:44PM -0500, Paul Svensson wrote: > On Thu, 21 Nov 2002, Oren Tirosh wrote: > > >One advantage of using an operator, method or function over in-line > >formatting is that it enables the use of a template. A new string method > >can provide run-time evaluation of the same format: > > > > "\(a) + \(b) = \(a+b)\n" > > r"\(a) + \(b) = \(a+b)\n".cook() > > > >A raw string is used to defer the evaluation of all backslash escape > >sequences to some later time. The cook method evaluates backslash > >escapes in the string, including any embedded expressions. This runtime > >version may be used for internationalization, for example. > > Why not call this method "eval", so we all will know to treat it with care ? If cook() is limited to variable names it will be pretty safe and no special care should be necessary. In that case the example above wouldn't work, though, because it contains (a+b). It will need to use cook_eval(). Since what it does is the opposite of "raw" I just had to call it "cook"! Oren

1 0

Yet another string formatting proposal
by Oren Tirosh 21 Nov '02

21 Nov '02

"\(a) + \(b) = \(a+b)\n" The expressions embedded in the string are parsed at compile time and any syntax errors in them are detected during compilation. The use of the backslash as introducer makes it unnecessary to add a new magic character ("$") along with a new escaping convention when this character needs to appear in the string ("$$") and a new string prefix (pep 215) or method (pep 292) to instruct the system to perform additional processing on this string. One advantage of using an operator, method or function over in-line formatting is that it enables the use of a template. A new string method can provide run-time evaluation of the same format: "\(a) + \(b) = \(a+b)\n" r"\(a) + \(b) = \(a+b)\n".cook() A raw string is used to defer the evaluation of all backslash escape sequences to some later time. The cook method evaluates backslash escapes in the string, including any embedded expressions. This runtime version may be used for internationalization, for example. By default, the cook method uses the global and local namespace of the calling scope, just like the built-in function eval(). Dictionary and/or named arguments may be used to override the namespace in which embedded expressions are evaluated: s = formatstring.cook(a=5, b=6) s = formatstring.cook(sys._getframe().f_locals) Security issues: Compile-time expression embedding should not have any special security concerns since there is no parsing of data from untrusted sources (if your SOURCE CODE is not trusted I can't help you there). In order to provide protection against evaluation of arbitrary code when an attacker has access to the format strings the cook() method could be limited to variable names only. A sparate cook_eval() method would support full expressions. The 'eval' in the method name should remind the programmer that it is potentially as dangerous as eval(). Drawbacks: Must use the full format "I like \(traffic) lights". There is no option for the shorter version "I like \traffic lights" because these combinations are already taken. May be considered an advantage: "There should be one-- and preferably only one --obvious way to do it." Not as familiar as $ for programmers from other languages. May also be considered an advantage :-) Oren

2 4

--disable-unicode, again
by Michael Hudson 21 Nov '02

21 Nov '02

Once again the --disable-unicode build is completely shafted. Include/pyerrors.h, Python/exceptions.c are easy enough to fix. Python/codecs.c looks worse. Modules/posixmodule.c doesn't build either, haven't looked into this at all. Seems the PEP 293 work is the main culprit. I think I've asked this before, but does anyone use this build? Should I spend some time patching things up -- again -- or ripping --disable-unicode support out. *I* don't care about it. Cheers, M. -- Important data should not be entrusted to Pinstripe, as it may eat it and make loud belching noises. -- from the announcement of the beta of "Pinstripe" aka. Redhat 7.0

4 4

Need some configure eyeballs and testing
by Skip Montanaro 21 Nov '02

21 Nov '02

Awhile ago I volunteered to fix the use of OPT within configure. The problem is that OPT is overloaded with two different kinds of things, optimization/debug flags and other flags which are required to get code to compile. The problem is that if there are any flags which need to be set to simply get Python to compile, if you override OPT when running configure or make, you may wipe out compiler flags necessary to simply compile the interpreter. I finally got a round to finishing that off this morning. I split OPT into two variables, OPT and BASECFLAGS. OPT can be modified, while BASECFLAGS should be left alone. You can pass BASECFLAGS to configure. If it decides you need some other flags they just get tacked on. On the other hand, if you pass OPT to configure, it generally will prevent the configure script from doing anything else to it. (There is one bit of code I didn't understand too well which does set OPT unconditionally on BeOS. I left that alone, but I think it probably needs to be changed. As they say, "it works for me", however all I've tested it on is MacOSX, and only a Unix build (I still don't know how to do the fancy schmansy Mac builds). The following issues remain: * For some reason the flags which wind up in BASECFLAGS are getting duplicated on the gcc command line. I'm not sure where this is happening, but Makefile.pre and Makefile both wind up with these definitions: OPT= -Wno-long-double -no-cpp-precomp -g -Wall -Wstrict-prototypes BASECFLAGS= -Wno-long-double -no-cpp-precomp I don't merge BASECFLAGS into OPT anywhere, and the echo statements in configure report: Base CFLAGS: < -Wno-long-double -no-cpp-precomp> OPT: <-g -Wall -Wstrict-prototypes> * There are three XXX comments in configure.in which could use some investigation. Two are related to condensing two bits of code which seem to overlap a bit. The third is related to Monterey. This small block of code: # The current (beta) Monterey compiler dies with optimizations case $ac_sys_system in Monterey*) OPT="" ;; esac unconditionally wipes out OPT, but doesn't say what Monterey is or give any indication that this setting needs to be revisited. Is "Monterey" still in beta test? "cvs annotate" indicates that Trent Mick added this in August 2000, so I assume it's something to do with Win64 (the OS? MSVC?), but it would be nice to know if this is still needed. I can use some extra eyeballs if you have a few moments to spare. To save bandwidth on the group, I opened a patch at http://python.org/sf/640843 The uploaded file includes diffs for Makefile.pre.in, configure.in and configure, so you don't need to have a recent version of autoconf to try it out. I uploaded the context diffs using Internet Explorer on my Mac. I just downloaded it to my Linux laptop using Opera and noticed a bit of corruption (NULs at the start and the end). The file is fine on my Mac. Downloading on the Mac with IE generates an okay file, but Mac+Opera also results in corruption. If you can't get a clean file, let me know and I'll be happy to mail it to you. I have no idea what caused this but would appreciate some feedback on efforts to download it, even if you don't have time to test it more extensively. Skip

5 11