Mailman 3 August 2004 - Python-Dev

tab in file tkFont.py
by Simon Percivall Aug. 18, 2004

Aug. 18, 2004

lib-tk/tkFont.py CVS HEAD has a tab character at line 94, breaking installation. //Simon

2 1

RE: [Python-Dev] Find out whether PyEval_InitThreads has been called?
by Michael Chermside Aug. 18, 2004

Aug. 18, 2004

> Why not go one step further and make all locking > operations in python no-ops if PyEval_InitThreads has never been > called? Currently, we risk python crashing if we call such functions > without calling PyEval_InitThreads. +1. Seems like it can't possibly hurt, and as you say, it's trivial to implement. -- Michael Chermside

2 1

multiple instances of python on XP
by Paul Gimpelj Aug. 17, 2004

Aug. 17, 2004

hi, I was wondering how to have multiple instances of python running on XP. I have ZOPE and TSW installed, but ZOPE's python is grabbing paths from TSW's python. specifically I changed to dir "...\Zope-2.7.2-0\bin" and in cmd window ran python did help() , sys and executable= r'...\Zope-2.7.2-0\bin\python.exe' but exec_prefix = r'...\TSW\Apache2\python' path_importer_cache = ...\TSW|Apache2\python... TSW's pyhon is ver 2.3.4 ZOPE python is 2.3.3 so Is there a way to prevent this mixup? I would like to have ZOPE installed as a service, and that means a python is running as a service. I would like to multiple python services running, and have them stay in their own installed areas. Is there a way to define the internal paths, and not to use XP's search PATH Would I have to rename python to python_1, Python_2, etc? Thanks.

4 4

Deprecate sys.exitfunc?
by Raymond Hettinger Aug. 17, 2004

Aug. 17, 2004

The documentation for the atexit module (introduced in Py2.0) states: """Note: This module is unlikely to work correctly when used with other code that sets sys.exitfunc. In particular, other core Python modules are free to use atexit without the programmer's knowledge. Authors who use sys.exitfunc should convert their code to use atexit instead. The simplest way to convert code that sets sys.exitfunc is to import atexit and register the function that had been bound to sys.exitfunc.""" Can we strengthen this by deprecating sys.exitfunc? The atexit module does attempt to co-exist by introducing code to register a function in sys.exitfunc if it were defined before "import atexit" was called. However, this is unreliable because it depends on import order and the library is free to introduce an earlier "import atexit" which would break code relying on the co-existance mechanism. Raymond

6 13

RE: [Python-Dev] Decorator order implemented backwards?
by Michael Chermside Aug. 17, 2004

Aug. 17, 2004

Mark writes: > Your patch results in the evaluation order: > > evalname1 evalargs1 makedec1 > evalname2 evalargs2 makedec2 > evalname3 evalargs3 makedec3 > calldec3 calldec2 calldec1 > > Mine (#1009560) gives: > > evalname3 evalargs3 makedec3 calldec3 > evalname2 evalargs2 makedec2 calldec2 > evalname1 evalargs1 makedec1 calldec1 Guido writes: > Since Mark ended up agreeing with your order, the OK is given by > default. :-) Wait... I'm confused. What was the final decision? I favor evalname1 evalargs1 makedec1 evalname2 evalargs2 makedec2 evalname3 evalargs3 makedec3 calldec3 calldec2 calldec1 becase of left-to-right-top-to-bottom evaluation. Is this what it actually does? I imagine this: >>> # Warning - not actual code >>> def dummyDecorator1(x): ... print 'one' ... return x ... >>> def dummyDecorator2(x): ... print 'two' ... return x ... >>> @dummyDecorator1 >>> @dummyDecorator2 >>> def func(): pass two one which somehow seems wrong to me. -- Michael Chermside

2 1

RE: [Python-Dev] Decorator order implemented backwards?
by Michael Chermside Aug. 17, 2004

Aug. 17, 2004

I wrote: > Wait... I'm confused. What was the final decision? I favor [...] Never mind. I somehow missed Mark's second email. -- Michael Chermside

1 0

RE: [Python-Dev] Re: adding a bytes sequence type to Python
by Tony Meyer Aug. 17, 2004

Aug. 17, 2004

[Martin v. Löwis] > Maybe you are missing the point here, maybe not: there is no > debate that Python should always have a byte string type > (although there is debate on whether that type should be mutable). > > The current question is whether you want to denote objects of > the byte string type *in source code*. I.e. do you have the > "Lots of audio data" stored in .py files? I don't know about shtoom, but Mike Fletcher's resourcepackage does. (It packages up non-*.py files as *.py files). I believe that the main point of resourcepackage is for ease of distribution (but could be wrong), so perhaps better distribution tools make this unnecessary. It is an example use-case, though. =Tony Meyer

2 1

Classes that claim to be defined in __builtin__ but aren't
by James Y Knight Aug. 17, 2004

Aug. 17, 2004

There's a fair number of classes that claim they are defined in __builtin__, but do not actually appear there. For example: >>> def qual(clazz): ... return clazz.__module__ + '.' + clazz.__name__ ... >>> qual(types.GeneratorType) '__builtin__.generator' >>> qual(types.FunctionType) '__builtin__.function' >>> qual(types.MethodType) '__builtin__.instancemethod' >>> qual(types.NoneType) '__builtin__.NoneType' >>> qual(types.GeneratorType) '__builtin__.generator' >>> __builtin__.generator AttributeError: 'module' object has no attribute 'generator' [[[etc.]]] IMO classes ought to actually appear in __builtin__ if they claim they are defined there. Doing otherwise breaks reflection, as you have to add a special case for these class names to use the appropriate object from the types module instead. Thoughts? If it isn't desirable to have these names appear in __builtin__, perhaps their '__module__' should be changed to another module where they are defined? James

8 16

RE: [Python-Dev] Exception hierarchy [was Re: Another test_compilermystery]
by Delaney, Timothy C (Timothy) Aug. 17, 2004

Aug. 17, 2004

James Y Knight wrote: > One issue is that creating a new category of Exceptions doesn't help > people who do "except:" instead of "except Exception:". It is unlikely > that person meant to catch things like MemoryError, rather, they were > just being lazy. I suppose that syntax could be deprecated, at least > in > example code and documentation, in favor of "except Exception" for the > usual case, and "except Raisable" for the cases where you do actually > want to catch everything*. Personally, I would be in favour of a bare except being equivalent in new code to 'except Exception'. Although this does violate 'in the presence of ambiguity, resist the temptation to guess'. Tim Delaney

1 0

Decorator order implemented backwards?
by James Y Knight Aug. 17, 2004

Aug. 17, 2004

I haven't seen anyone remark upon this yet, but the order of decorator application appears to be implemented backwards. According to the PEP: > Proposed Syntax > > The current syntax for function decorators as implemented in Python > 2.4a2 is: > @dec2 > @dec1 > def func(arg1, arg2, ...): > pass > > > This is equivalent to: > def func(arg1, arg2, ...): > pass > func = dec2(dec1(func)) However, it seems the '@' form is really doing dec1(dec2(func)), not dec2(dec1(func)). The test_decorators.py reveals that it is, indeed, testing *for* the wrong behavior. test_decorators.py: > def test_order(self): > class C(object): > @funcattrs(abc=1) @staticmethod > def foo(): return 42 > # This wouldn't work if staticmethod was called first > self.assertEqual(C.foo(), 42) > self.assertEqual(C().foo(), 42) So, um...I assume this is a bug in the implementation, not the PEP, because the PEP's way makes sense and the way it's implemented doesn't. James

10 17