Mailman 3 November 2002 - Python-Dev

Re: PyMem_MALLOC (was [Python-Dev] Snake farm)
by Tim Peters Nov. 22, 2002

Nov. 22, 2002

[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 … [View More]

2 1

Anon CVS
by Michael Gilfix Nov. 22, 2002

Nov. 22, 2002

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 … [View More]

5 6

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

Nov. 22, 2002

"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 … [View More]

2 1

Re: [Python-Dev] release22-maint branch broken
by Michael Hudson Nov. 22, 2002

Nov. 22, 2002

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. -- … [View More]

1 0

Returning objects in Tkinter
by martin＠v.loewis.de Nov. 22, 2002

Nov. 22, 2002

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 Nov. 22, 2002

Nov. 22, 2002

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 … [View More]

7 9

Re: [Python-Dev] Yet another string formatting proposal
by Oren Tirosh Nov. 21, 2002

Nov. 21, 2002

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 … [View More]

1 0

Yet another string formatting proposal
by Oren Tirosh Nov. 21, 2002

Nov. 21, 2002

"\(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 … [View More]

2 4

--disable-unicode, again
by Michael Hudson Nov. 21, 2002

Nov. 21, 2002

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 … [View More]

4 4

Need some configure eyeballs and testing
by Skip Montanaro Nov. 21, 2002

Nov. 21, 2002

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 … [View More]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 [View Less]

5 11