Mailman 3 December 2003 - Python-Dev

RE: [Python-Dev] Importing packages from command line
by Michael Chermside Dec. 23, 2003

Dec. 23, 2003

Dmitry Vasiliev writes: > Just an idea... > > 1. python -p package_name > > Equivalent to: > > import package_name (1) Sourceforge is a great place to request feature enhancements. Suggestions made on this mailing list is likely to be forgotten sooner or later. (2) Can you explain WHY you would want this feature? Is there some use case? I would prefer NOT to have this, because right now if I'm reading code and it uses "package_name.… [View More]

4 6

Improve Python for embedding
by Thomas Heller Dec. 22, 2003

Dec. 22, 2003

I find the current situation when 'embedding' Python rather unsatisfying. 1. Careful preparation (hacking?) of environment variables is needed to avoid that Py_Initialize() takes the default actions needed for the standard Python interpreter (for example, to avoid the default sys.path). 2. A suggestion from /F on c.l.p was to change pythonw.exe so that instead of hiding all output to stderr a console window would be opened to show the tracebacks. This requires to construct an object with a '… [View More]

6 13

OpenBSD anyone?
by Guido van Rossum Dec. 22, 2003

Dec. 22, 2003

John Draper <crunch(a)shopip.com> (the famous Capt'n Crunch) reports that on his OpenBSD box, he can't build a debug version of Python 2.3(.3c1, but I doubt that matters) unless he tweaks the configure file to add -O3 to the C flags. That sounds fishy to me, but he insists that's how it is, and he's reproduced it from a clean tarball. Debugging it further doesn't really seem to be within John's power; the -O3 trick was found by his partner Steve who's temporarily unavailable. The … [View More]

5 10

Re: [Python-Dev] getting rid of default object.__hash__ (SF 660098)
by Samuele Pedroni Dec. 22, 2003

Dec. 22, 2003

At 13:43 22.12.2003 -0800, Guido van Rossum wrote: > > > > I see, but then there should be probably be a different way to spell > > > > the default hash, because id is not a sensible option for Jython etc > > > > > >Ow, you're right. I bet this is why object.__hash__ was introduced in > > >the first place. > > > > > >We're either back to square one, or we can add a __default_hash__ to > > >object which has the … [View More]

1 0

Re: [Python-Dev] getting rid of default object.__hash__ (SF 660098)
by Samuele Pedroni Dec. 22, 2003

Dec. 22, 2003

At 13:32 22.12.2003 -0800, Guido van Rossum wrote: > > >Since the default hash simply takes id() of the object, it's easy to > > >fix such code once the failure is understood though. > > > > Jython 2.2a0 on java1.4.0_02 (JIT: null) > > Type "copyright", "credits" or "license" for more information. > > >>> class C: pass > > ... > > >>> id(C) > > 1 > > >>> hash(C) > > 9174506 > > >>&… [View More]

2 1

Re: [Python-Dev] getting rid of default object.__hash__ (SF 660098)
by Samuele Pedroni Dec. 22, 2003

Dec. 22, 2003

At 13:04 22.12.2003 -0800, Guido van Rossum wrote: >Since the default hash simply takes id() of the object, it's easy to >fix such code once the failure is understood though. Jython 2.2a0 on java1.4.0_02 (JIT: null) Type "copyright", "credits" or "license" for more information. >>> class C: pass ... >>> id(C) 1 >>> hash(C) 9174506 >>> I see, but then there should be probably be a different way to spell the default hash, because id is not a … [View More]

2 1

Re: [Python-Dev] getting rid of default object.__hash__ (SF 660098)
by Phillip J. Eby Dec. 22, 2003

Dec. 22, 2003

At 01:04 PM 12/22/03 -0800, Guido van Rossum wrote: >New-style classes inherit a default __hash__ from object, but this >is incorrect if the inheriting object defines __eq__ or __cmp__. > >This has been reported several times; the roll-up SF entry is 660098, >which has the proposed patch attached as newpatch.txt. > >I've long pondered this, and it seems the best solution is to simply >not define __hash__ on the base object class. After all, you don't >inherit __eq__ … [View More]

2 1

Re: [Python-Dev] Got None. Maybe Some?
by Guido van Rossum Dec. 22, 2003

Dec. 22, 2003

> Is None so weird? All I am proposing is a symmetric value to None. > Just like there is a -1 and 1, -Infinity and Infinity, None logically > should have Some. Maybe not so much -Some == None, but as I propose in > the PEP, possibly Some == not None. None's purposr is not to be less than all numbers (in fact in the past it wasn't); it's to be "not any object", like nil or NULL in other languages. I don't see a similar broad role for Some. And I repeat my question: which other … [View More]

3 4

Re: [Python-checkins] python/dist/src/Objects unicodeobject.c, 2.204, 2.205
by M.-A. Lemburg Dec. 22, 2003

Dec. 22, 2003

perky(a)users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory sc8-pr-cvs1:/tmp/cvs-serv1651/Objects > > Modified Files: > unicodeobject.c > Log Message: > SF #859573: Reduce compiler warnings on gcc 3.2 and above. > > Index: unicodeobject.c > *************** > *** 2204,2208 **** > > /* Latin-1 is equivalent to the first 256 ordinals in Unicode. */ > ! if (size == 1 && *(unsigned char*)s &… [View More]

12 24

Py_DECREF causes spurious gcc warning
by Edward C. Jones Dec. 22, 2003

Dec. 22, 2003

I use Gentoo 1.4 Linux with gcc 3.2.2. The C program given below gives the following compiler message: silly.c: In function `silly': silly.c:5: warning: suggest explicit braces to avoid ambiguous `else' I doubt if there is any bug in Py_DECREF. But would it be possible to jiggle the Py_DECREF macros to suppress this message? In my real code, I, of course, just added braces. ----------------------- #include </usr/local/include/python2.3/Python.h> static PyObject* silly(PyObject* obj,… [View More]

6 15