Mailman 3 September 2001 - Python-Dev

Preventing PyEval_AcquireLock deadlock
by Robin Dunn 14 Sep '01

14 Sep '01

Is there an easy way in the API to check if the current thread already has the interpreter lock so I can avoid calling PyEval_AcquireLock again? If so, is it available all the way back to 1.5.2? -- Robin Dunn Software Craftsman robin(a)AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!

3 4

A draft PEP for a new memory model
by Paul Barrett 14 Sep '01

14 Sep '01

The following is the beginnings of a PEP for a new memory model for Python. It currently contains only the motivation section and a description of a preliminary design. I'm submitting the PEP in its current form to get a feel for whether or not I should pursue this proposal and to find out if I am overlooking any details that would make it incompatible with Python's core implementation, i.e. implementing it would cause too much of an affect on Python's performance. I do plan to implement something along these lines, but may have to change my approach if I hear comments about this PEP to the contrary. Cheers, Paul PEP: XXX Title: A New Memory Management Model for Python Version: $Revision: 1.3 $ Last-Modified: $Date: 2001/08/20 23:59:26 $ Author: barrett(a)stsci.edu (Paul Barrett) Status: Draft Type: Standards Track Created: 05-Sep-2001 Python-Version: 2.3 Post-History: Replaces: PEP 42 Abstract This PEP proposes a new memory management model to provide better support for the various types of memory found in modern operating systems. The proposed model separates the memory object from its access method. In simplest terms, memory objects only allocate memory, while access objects only provide access to that memory. This separation allows various types of memory to share a common interface or access object and vice versa. Motivation There are three sequence objects which share similar interfaces, but have different intended uses. The first is the indispensable 'string' object. A 'string' is an immutable sequence of characters and supports slicing, indexing, concatenation, replication, and related string-type operations. The second is the 'array' object. Like a 'list', it is a mutable sequence and supports slicing, indexing, concatenation, and replication, but its values are constrained to one of several basic types, namely characters, integers, and floating point numbers. This constraint enables efficient storage of the values. The third object is the 'buffer' which behaves similar to a string object at the Python programming level: it supports slicing, indexing, concatenation, and related string-like operations. However, its data can come from either a block of memory or an object that exports the buffer interface, such as 'mmap', the memory-mapped file object which is its prime justification. Each object has been used at one time or other as a way of allocating read-write memory from the heap. The 'string' object is often used at the C programming level because it is a standard Python object, but its use goes counter to its intended behavior of being immutable. The preferred way of allocating such memory is the 'array' object, but its insistence on returning a representation of itself for both the 'repr' and 'str' methods makes it cumbersome to use. In addition, the use of a 'string' as an initializer during 'array' creation is inefficient, because the memory is temporarily allocated twice, once for the 'string' and once for the 'array'. This is particularly onerous when allocating tens of megabytes of memory. The 'buffer' object also has its problems, some of which have been discussed on python-dev. Some of the more important ones are: (1) the 'buffer' object always returns a read-only 'buffer', even for read-write objects. This is apparently a bug in the 'buffer' object, which is fixable. (2) The buffer API provides no guarantee about the lifetime of the base pointer - even if the 'buffer' object holds a reference to the base object, since there is no locking mechanism associated with the base pointer. For example, if the initial 'buffer' is deleted, the memory pointer of the derived 'buffer' will refer to freed memory. This situation happens most often at the C programming level as in the following situation: PyObject *base = PyBuffer_New(100); PyObject *buffer = PyBuffer_FromObject(base); Py_DECREF(base); This problem is also fixable. And (3) the 'buffer' object cannot easily be used to allocate read-write memory at the Python programming level. The obvious approach is to use a 'string' as the base object of the 'buffer'. Yet, a 'string' is immutable which means the 'buffer' object derived from it is also immutable, even if problem (1) is fixed. The only alternative at the Python programming level is to use the cumbersome 'array' object or to create your own version of the 'buffer' object to allocate a block of memory. We feel that the solution to these and other problems is best illustrated by problem (3), which can essentially be described as the simple operation of allocating a block of read-write memory from the heap. Python currently provides no standard way of doing this. It is instead done by subterfuge at the C programming level using the 'string', 'array', or 'buffer' APIs. A solution to this specific problem is to include a 'malloc' object as part of standard Python. This object will be used to allocate a block of memory from the heap and the 'buffer' object will be use to access this memory just as it is used to access data from a memory-mapped file. Yet, this hints at a more general solution, the creation of two classes of objects, one for memory-allocation, and one for memory-access. The Model We propose a new memory-management model for Python which separates the allocation object from its access method. This mix-and-match memory model will enable various access objects, such as 'array', 'string', and 'file', to access easily the data from different types of memory, namely heap, shared, and memory-mapped files; or in other words, different types of memory can share a common interface (see figure below). It will also provide better support for the various types of memory found in modern operating systems. |---------------------------------------------------| | interface layer | | ----------------------------------------------- | | array | string | file | ... | |===================================================| | data layer | | ----------------------------------------------- | | heap memory | shared memory | memory mapped file | |---------------------------------------------------| Memory Objects Modern operating systems, such as Unix and Windows, provide access to several different types of memory, namely heap, shared, and memory-mapped files. These memory types share two common attributes, a pointer to the memory and the size of the memory. This information is usually sufficient for objects whose data uses heap memory, since the object is expected to have sole control over that memory throughout the lifetime of the object. For objects whose data also uses shared and memory-mapped files, an additional attribute is necessary for access permission. However, the issue of how to handle memory persistence across processes does not appear well-defined in modern OSs, but appears to be left to the programmer to implement. In any case, a fourth attribute to handle memory persistence seems imperative. Access Objects Consider 'array', 'buffer', and 'string' objects. Each provides, more or less, the same string-like interface to its underlying data. They each support slicing, indexing, concatenation, and replication of the data. They differ primarily in the types of initializing data and the permissions associated with the underlying data. Currently, the 'array' initializer accepts only 'list' and 'string' objects. If this was extended to include objects that support the 'buffer interface', then the distinction between the 'array' and 'buffer' objects would disappear, since they both support the sequence interface and the same set of base objects. The 'buffer' object is therefore redundant and no longer necessary. The 'string' and 'array' objects would still be distinct, since the 'array' object encompasses more data-types than does the 'string' object. The 'array' object is also mutable requiring its underlying data to be read-write, while the 'string' object is immutable requiring read-only data. This new memory-management model therefore suggests that the 'string' object support the 'buffer interface' with the proviso that the data have read-only permission. Implementation References Copyright This document has been placed in the public domain. -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Group FAX: 410-338-4767 Baltimore, MD 21218

2 1

Re: PEP 269
by Samuele Pedroni 13 Sep '01

13 Sep '01

Hi personally I have the following concerns about PEP 269: - if it's purpose is to offer a framework for small languages support, there are already modules around that support that (SPARK, PLY ...), the only advantage of PEP 269 being speed wrt to the pure python solutions, because of the use of the internal CPython parser, OTOH the other solutions are more flexible... - or if's purpose is to help experimenting with the grammar unless support for adding keywords is added is a quite unfinished tool. Further the PEP propose to use the actual AST format of parser module as output format. To be honest that format is quite awful, especially for general purpose use. It should be considered that Jython does not contain a parser similar to CPython one. Because of this jython does not offer parser module support. So implementing the PEP for Jython would require writing a Java or pure python equivalent of the CPython parser. My plans for resolving the lack of parser module support were to to implement an higher compatibility layer based on the AST format of tools/compiler, a more nicer format. PEP 269 adds issues to this open problem, which I would like to see addressed by future revisions and by further discussions. I can live with PEP 269 implemented only for CPython, for a lack of resources on Jython side, if is to be used for rare experimenting with the grammar. But it seems, as it is, a rather half-cooked solution to offer a module for mini language support in the standard library. regards, Samuele Pedroni. > From: Jonathan Riehl <jriehl(a)spaceship.com> > To: Martin von Loewis <loewis(a)informatik.hu-berlin.de> > cc: <python-list(a)python.org>, <types-sig(a)python.org> > MIME-Version: 1.0 > Subject: [Types-sig] Re: PEP 269 > X-BeenThere: types-sig(a)python.org > X-Mailman-Version: 2.0.6 (101270) > List-Help: <mailto:types-sig-request@python.org?subject=help> > List-Post: <mailto:types-sig@python.org> > List-Subscribe: <http://mail.python.org/mailman/listinfo/types-sig>, <mailto:types-sig-request@python.org?subject=subscribe> > List-Id: Special Interest Group on the Python type system <types-sig.python.org> > List-Unsubscribe: <http://mail.python.org/mailman/listinfo/types-sig>, <mailto:types-sig-request@python.org?subject=unsubscribe> > List-Archive: <http://mail.python.org/pipermail/types-sig/> > Date: Thu, 13 Sep 2001 14:49:32 -0500 (CDT) > > Howdy all, > I'm afraid Martin's attention to the PEP list has outted me > before I was able to post about this myself. Anyway, for those > interested, I wrote a PEP for the exposure of pgen to the Python > interpreter. You may view it at: > > http://python.sourceforge.net/peps/pep-0269.html > > I am looking for comments on this PEP, and below, I address some > interesting issues raised by Martin. Furthermore, I already have a > parially functioning reference implementation, and should be pestered to > make it available shortly. > > Thanks, > -Jon > > On Tue, 11 Sep 2001, Martin von Loewis wrote: > > > Hi Jonathan, > > > > With interest I noticed your proposal to include Pgen into the > > standard library. I'm not sure about the scope of the proposed change: > > Do you view pgen as a candidate for a general-purpose parser toolkit, > > or do you "just" contemplate using that for variations of the Python > > grammar? > > I am thinking of going for the low hanging fruit first (a Python centric > pgen module), and then adding more functionality for later releases of > Python (see below.) > > > If the former, I think there should be a strategy already how > > to expose pgen to the application; the proposed API seems > > inappropriate. In particular: > > > > - how would I integrate an alternative tokenizer? > > - how could I integrate semantic actions into the parse process, > > instead of creating the canonical AST? > > The current change proposed is somewhat restrained by the Python 2.2 > release schedule, and will initially only address building parsers that > use the Python tokenizer. If the module misses 2.2 release, I'd like to > make it more functional and provide the ability to override the Python > tokenizer. I may also add methods to export all the data found in the DFA > structure. > > I am unsure what the purpose of integration of semantics into the parse > process buys us besides lower memory overhead. In C/C++ such coupling is > needed because of the TYPEDEF/IDENTIFIER tokenization problem, but I > don't see Python and future Python-like, LL(1), languages needing such > hacks. Finally, I am prone to enforce the separation of the backend > actions from the AST. This allows the AST to be used for a variety of > purposes, rather than those intended by the initial parser developer. > > > Of course, these questions are less interesting if the scope is to > > parse Python: in that case, Python tokenization is fine, and everybody > > is used to getting the Python AST. > > An interesting note to make about this is that the since the nonterminal > integer values are generated by pgen, pgen AST's are not currently > compatible with the parser module AST's. Perhaps such unification may be > slated for future work (I know Fred left room in the parser AST datatype > for identification of the grammar that generated the AST using an integer > value, but using this would be questionable in a "rapid parser > development" environment.) > > > On the specific API, I think you should drop the File functions > > (parseGrammarFile, parseFile). Perhaps you can also drop the String > > functions, and provide only functions that expect file-like objects. > > I am open to further discussion on this, but I would note that filename > information is used (and useful) when reporting syntax errors. I think > that the "streaming" approach to parsing is another hold over from days > where memory constraints ruled (much like binding semantics to the parser > itself.) > > > On the naming of the API functions: I propose to use an underscore > > style instead of the mixedCaps style, or perhaps to leave out any > > structure (parsegrammar, buildparser, parse, symbol2string, > > string2symbolmap). That would be more in line with the parser module. > > I would like to hear more about this from the Pythonati. I am currently > following the naming conventions I use at work, which of course is most > natural for me at home. :) > > > > > Regards, > > Martin > > > > > > > _______________________________________________ > Types-SIG mailing list > Types-SIG(a)python.org > http://mail.python.org/mailman/listinfo/types-sig

1 0

Free threading and borrowing references from mutable types
by Martin von Loewis 12 Sep '01

12 Sep '01

Considering the free threading issue (again), I found that functions returning borrowed references are problematic if the container is mutable. In traditional Python, extension modules could safely borrow references if they know that they maintain a reference to the container. If a thread switch is possible between getting the borrowed reference and using it, then this assumption is wrong: another thread may remove the reference from the container, so that the object dies. Therefore, I propose to deprecate these functions. I'm willing to write a PEP elaborating on that if necessary, but I'd like to perform a quick poll beforehand - whether people think that deprecating these functions is reasonable - whether it is sufficient to only have their abstract.c equivalents, or whether type-specific replacements that do return new references are needed - what else I'm missing. Specifically, I think the following functions are problematic: - PyList_GetItem, PyList_GET_ITEM, - PyDict_GetItem, PyDict_GetItemString Any comments appreciated, Martin

3 3

interning string subclasses
by Guido van Rossum 12 Sep '01

12 Sep '01

> Question: Should we complain if someone tries to intern an instance of > a string subclass? I hate to slow any code on those paths. I think in this case intern(s) should return intern(str(s)). The fast path checks ob_sinterned first, and that should always point to a real string for a string subclass. --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

[development doc updates]
by Fred L. Drake 12 Sep '01

12 Sep '01

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Miscellaneous updates, plus documentation for the new "hmac" module (located in the crypto chapter of the Library Reference).

1 0

Re: [Python-checkins] CVS: python/nondist/sandbox/Lib README,NONE,1.1 davlib.py,NONE,1.1 httpx.py,NONE,1.1
by Greg Stein 11 Sep '01

11 Sep '01

I've now created nondist/sandbox/Lib as a place where people can (cooperatively) develop modules intended for inclusion into the core's Lib directory. Of course, at your discretion, you can also create sandbox/big-project, but the sandbox/Lib directory could be handy for more people. I've checked in a non-working httpx, and the current davlib. These will get worked on over the next few weeks to prep them for the next release. Review and commentary are welcome! Cheers, -g On Mon, Sep 10, 2001 at 06:27:40PM -0700, Greg Stein wrote: > Update of /cvsroot/python/python/nondist/sandbox/Lib > In directory usw-pr-cvs1:/tmp/cvs-serv17467 > > Added Files: > README davlib.py httpx.py > Log Message: > Initial checkin of some files: > > * README: describe this directory and its contents > > * davlib.py: current, published davlib (only tweaked the header) > > * httpx.py: initial draft from some coding over the weekend (incomplete, > untested, and it doesn't even load :-) > > > > --- NEW FILE: README --- > This directory is for modules that are intended to go into the main Lib > directory of Python. They can be developed here until they are ready for > evaluation for inclusion into Python itself. > > (this prevents iteration of development within the core, yet also provides > for public development of (new) modules) > > Note: a module's presence here does not mean it *will* go into Lib, but > merely that (should it be accepted) the appropriate place is Lib. ... -- Greg Stein, http://www.lyra.org/

5 8

2.2a3 error messages
by Fredrik Lundh 11 Sep '01

11 Sep '01

maybe it's just me, but I just spent five minutes trying to figure out why an innocent-looking line of code resulted in an "iter() of non-sequence" type error. I finally ran it under 2.1, and immediately realized what was wrong. is there any chance of getting the old, far more helpful "unpack non-sequence" and "loop over non-sequence" error messages back before 2.2 final? </F>

3 2

problem with inspect module and Jython
by James_Althoff＠i2.com 11 Sep '01

11 Sep '01

Apologies for not being up to speed on the standard bug reporting process. There appears to be an incompatibility between the inspect module and Jython. The inspect module uses "type(xxx) is types.zzz" in a number of places. This seems to fail when inspect is used with Jython. Using "isinstance" instead works as shown in the example below. My understanding is that "isinstance" is the preferred idiom in any case. Jim =========================================== from the inspect module: def iscode(object): """Return true if the object is a code object. Code objects provide these attributes: co_argcount number of arguments (not including * or ** args) co_code string of raw compiled bytecode co_consts tuple of constants used in the bytecode co_filename name of file in which this code object was created co_firstlineno number of first line in Python source code co_flags bitmap: 1=optimized | 2=newlocals | 4=*arg | 8 =**arg co_lnotab encoded mapping of line numbers to bytecode indices co_name name with which this code object was defined co_names tuple of names of local variables co_nlocals number of local variables co_stacksize virtual machine stack space required co_varnames tuple of names of arguments and local variables""" ###return type(object) is types.CodeType # <<< returns 0 (before reload below) return isinstance(object,types.CodeType) # <<< returns 1 (after reload below) Jython 2.1b1 on java1.3.0 (JIT: null) Type "copyright", "credits" or "license" for more information. >>> from core.probe import tablepanel >>> import inspect >>> source = inspect.getsource(tablepanel.TablePanel.__init__) Traceback (innermost last): File "<console>", line 1, in ? File "C:\_Dev\pnp\3rdparty\jython\Lib\inspect.py", line 411, in getsource File "C:\_Dev\pnp\3rdparty\jython\Lib\inspect.py", line 400, in getsourcelines File "C:\_Dev\pnp\3rdparty\jython\Lib\inspect.py", line 280, in findsource IOError: could not get source code >>> reload(inspect) <module inspect at 4523599> >>> source = inspect.getsource(tablepanel.TablePanel.__init__) >>> source " def __init__(self,rowList=None,label=None):\n self.rowList = rowList or [['','','']]\n self.jtable = None\n from javax.swing.table import DefaultTableModel\n self.tabl eModel = DefaultTableModel(self.rowList,self.columnNameList)\n _super.__init__(self,label=lab el)\n" >>>

2 1

More test problems
by Jack Jansen 11 Sep '01

11 Sep '01

The recent mods to the test suite make my life a _lot_ simpler, thanks! I now have a new problem, one that I've seen in the past but always seems to go away all by itself. Urllib2 will fail when I run the whole regrtest suite: >>> import test.regrtest >>> test.regrtest.main() test_grammar [... many lines deleted] test_urllib2 test test_urllib2 crashed -- exceptions.AttributeError: 'module' object has no attribute 'error' But if I run only the urllib2 test in verbose mode it works fine: >>> sys.argv = ['regrtest.py', '-v', 'test_urllib2'] >>> test.regrtest.main() test_urllib2 test_urllib2 1 test OK. CAUTION: stdout isn't compared in verbose mode: a test that passes in verbose mode may fail without it. Does anyone know where I could start looking for this one? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 1

More test problems
by Martin v. Loewis 10 Sep '01

10 Sep '01

> Does anyone know where I could start looking for this one? My guess is that something happens to socket.error. What this could be, I don't know. To analyse this, you could disable the "verbose" test in regrtest after the "crashed" line, and always print the traceback. Regards, Martin

1 0

2.2a3 oddities
by Fredrik Lundh 10 Sep '01

10 Sep '01

anyone else seeing this? 1) using a local windows build, I keep getting complaints about a missing symbol in the python22.dll: _PyGC_Insert an easy way to get this is to import the "xmlrpclib" module into a clean interpreter. (fwiw, this doesn't stop Python -- once you click OK, the interpreter proceeds as if nothing happened...) 2) most C functions that expect 8-bit strings crash if you hand them a unicode string containing non-ascii characters. an example: >>> import socket >>> socket.gethostbyname(u"pythönware.com") this works as expected in 2.1.1 (that is, I get an exception). it doesn't work in a local build of 2.2a2. </F>

6 7

Re: [Python-Dev] test_descrtut failing
by Jack Jansen 09 Sep '01

09 Sep '01

Recently, Guido van Rossum <guido(a)python.org> said: > You said that when you run the test standalone the type names are > different. *How* do you run it standalone? If I run it like this: > > ./python Lib/test/test_descrtut.py > > it works fine (and -v works here too). But if I run it like this: > > ./python > >>> import test.test_descrtut # this does not run the tests! > >>> test.test_descrtut.test_main() # this does! Indeed, I run it the second way (no command line on the Mac, remember:-). The fun thing is that if I run it completely standalone (by dragging test_descrtut.py to the interpreter, the test can handle this situation) it works fine! So, there must be something wrong with either the test framework (or maybe this re-import trick?) that doesn't work as expected on the Mac. Maybe test_regrtest can be thought which tests use unittest or doctest, and not try to be helpful in those cases? For now I've just put a note in the readme file for MacPython that this test is expected to fail, but I'd like to fix it eventually, of course. I have another gripe with the new unittest stuff (this is the first time I've seen the doctest thing, never knew it was there!), and that's that most of the test failures are difficult to interpret. Whereas the old-style tests simply "print math.sin(math.pi)" and tell you they expected the output to be 0 but got -1 in stead the unittest-based tests often don't give that information. Most of the unittest-based tests use only failUnless/assert_ in stead of the higher-level functions, i.e. test_time uses things like self.assert_(time.ctime(self.t) == time.asctime(time.localtime(self.t))) where the test results would be a lot easier to interpret if they used self.assertEqual(time.ctime(self.t), time.asctime(time.localtime(self.t)), "ctime(T) != asctime(localtime(T)") -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 3

Re: [Python-Dev] test_descrtut failing
by Jack Jansen 08 Sep '01

08 Sep '01

Recently, "Tim Peters" <tim.one(a)home.com> said: > I'd rather delete the test. But since I doubt Jack is running the test in > the devious way shown above, I'll hold off until he surprises me <wink>. Well, as you've seen from my previous message I'm indeed running the test in this devious way:-) But I must say that I'm mildly surprised that windows users not also do this. In the MacPython installation instructions I suggest people start by firing up the interpreter and doing "importtest.regrtest; test.regrtest.main()". What does PythonWin suggest? That people fire up a dos shell to run the tests? Or does it simply not suggest anything <half-a-wink>? Or do the problems somehow not show up in PythonWin? -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

test_descrtut failing
by Jack Jansen 08 Sep '01

08 Sep '01

Test_descrtut is driving me up the wall (or actually, the whole test suite is:-). If I run it from regrtest it fails with the completely useless message test_descrtut The actual stdout doesn't match the expected stdout. This much did match (between asterisk lines): ********************************************************************** test_descrtut ********************************************************************** Then ... We expected (repr): '' But instead we got: '*****************************************************************\n' test test_descrtut failed -- Writing: '*****************************************************************\n', expected: '' If I run it standalone it doesn't work because all the typenames are different. This is a general problem, I've seen the same on unix. In general, I find the new test framework not much of an improvement. Whereas with old tests you would get some indication as to what was failing, currently it is at best a not very helpful "We expected '' But in stead we got 'TestFailed'", and at worst something like the above. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

3 2

RE: Bug in time.timezone of Python 2.1.1
by Norman Vine 07 Sep '01

07 Sep '01

Ivan J. Wagner writes: >Sent: Thursday, September 06, 2001 8:03 PM >To: cygwin(a)sources.redhat.com >Cc: jason(a)tishler.net >Subject: Bug in time.timezone of Python 2.1.1 > > >I maintain a CVS archive (using cvs 1.11.0-1) on a Cygwin 1.3.2 install >and use ViewCVS 0.7 to access it. ViewCVS uses python and today I >upgraded from python 2.1-1 to 2.1.1-1. However the upgade >broke the Age >field in ViewCVS. The Age field is the time span between the >file's check >in and today. The Age field is displayed when you view a CVS directory >listing. I looked at the ViewCVS sources and tracked the problem to >time.timezone. In 2.1 it returns 18000 but in 2.1.1 it returns >1834228892. Does anybody have any day what might be causing >this problem? > >Thanks, >Ivan Wagner YES see attached patch Cheers Norman Vine

4 3

warning in _localemodule.c patch
by Martin von Loewis 07 Sep '01

07 Sep '01

> You can't free the memory Py_FSDE points to, since it wasn't > allocated by malloc(). Why is that? The memory was allocated by strdup in this case, so you can certainly free() it. > I guess the simple solution is to remove the const. Is there a > better option? The other option is to cast the pointer in the call to free(). I don't know which one is better; Py_FSDE certainly points to memory that should not be changed. Regards, Martin

3 3

RELEASED: Python 2.2a3 is out!
by barry＠zope.com 07 Sep '01

07 Sep '01

We've released Python 2.2a3, the third alpha for Python 2.2, for your excitement, enlightenment, and endless-amusement. Download it from: http://www.python.org/2.2/ Give it a good try, and report what breaks to the bug tracker: http://sourceforge.net/bugs/?group_id=5470 [Note: this is my first solo release as Release Manager. If you find any problems with the downloads, please let me know! -BAW] New features in this release include: - Conversion of long to float now raises OverflowError if the long is too big to represent as a C double. - The 3-argument builtin pow() no longer allows a third non-None argument in some situations. - The builtin dir() now returns more information. - Overflowing operations on plain ints now return a long int rather than raising OverflowError. - A new command line option, -Q<arg>, is added to control run-time warnings for the use of classic division. - Many built-in types can now be subclassed. - The dictionary constructor now takes an optional argument, a mapping-like object. - New built-in types `super' and `property' have been added. - The syntax of floating-point and imaginary literals has been liberalized, to allow leading zeroes. - Lots of bug fixes, contributed patches, and other stuff. See the Misc/NEWS file in the distribution, or see the release notes on SourceForge: http://sourceforge.net/project/shownotes.php?release_id=51791 As usual, Andrew Kuchling is writing a gentle introduction to the most important changes (currently excluding type/class unification), titled "What's New in Python 2.2": http://www.amk.ca/python/2.2/ There is an introduction to the type/class unification at: http://www.python.org/2.2/descrintro.html Thanks to everybody who contributed to this release, including all the 2.2 alpha 1 and 2 testers! Enjoy! -Barry

2 1

warning in _localemodule.c patch
by Jeremy Hylton 07 Sep '01

07 Sep '01

The most recent revision (2.23) adds some code that modifies Py_FileSystemDefaultEncoding. This variable is decarled const char * in bltinmodule.c, but passed to free() in the new localmodule. gcc warns about this: 'free' discards qualifiers from pointer target type. You can't free the memory Py_FSDE points to, since it wasn't allocated by malloc(). I guess the simple solution is to remove the const. Is there a better option? Jeremy

1 0

CVS: python/dist/src setup.py,1.52,1.53
by Martin v. Loewis 07 Sep '01

07 Sep '01

>> I think the bug isn't OSX specific, I would be very >> surprised if other FreeBSD's at least don't have the same problem >> (why would Apple take FreeBSD but put an older version of curses in, >> after all). > Well, maybe Apple took a copy of FreeBSD several years ago... Probably on the contrary. When researching a getaddrinfo bug on OS X, I found that, when given a choice, they took library functions from the NeXT, rather than taking them from BSD. In case of getaddrinfo, this was the wrong choice - the BSD version would have worked... Now, I don't know where NeXT got its curses implementation from, but I wouldn't be surprised if it was 1.0BSD, or some such :-) Regards, Martin

1 0

Python 2.2a3 tagged
by barry＠zope.com 06 Sep '01

06 Sep '01

In preparation for the next alpha release, we've tagged the tree and created the branch. The tag on the trunk is r22a3-fork and the branch tag is r22a3-branch. The only people authorized to make checkins on the branch are Guido, Tim, and myself. You can still make checkins on the trunk, but please keep them to a minimum until 2.2a3 is released. If you make any trunk checkins that need to go into 2.2a3, please send Guido, Tim, and I a message directly asking us to merge your trunk change into the branch. Thanks, and watch for the release some time tomorrow. Cheers, -Barry

1 0

very long python files
by The Intermission Elf 06 Sep '01

06 Sep '01

Hey Folks, I just got this message from a developer inside of ILM today. Before I start digging, can anyone tell me if this has been dealt with in any version of python more recent than 1.5.2? (and where I might look for this info myself- I'm very unfamiliar with sourceforge and its bug tracker)... thanks! Garrick Meeker writes: | ******** is starting to produce very long project files (over 32K lines) | which it currently can't read. (Because curves are imbedded in the | files, it's not difficult to hit that limit.) | | Here's what I've found so far (in both python 1.4 and 1.5): | | ******** read the file by calling PyRun_SimpleFile. This byte compiles | the entire file into memory and then runs that (which is probably not | ideal). | | The file is tokenized into nodes that have a 'short' for the line | number, so this wraps around to negative numbers. | | The line number is entered into the byte code with a call to | 'com_addint', which calls: | | com_addbyte(c, x & 0xff); | com_addbyte(c, x >> 8); /* XXX x should be positive */ | | (notice that 'x >> 8' for a negative number will be a negative number). | | com_addbyte has a sanity check: | | if (byte < 0 || byte > 255) { | com_error(c, PyExc_SystemError, "com_addbyte: byte out of range"); | | This is what prevents ******** from loading long files. The options I | see are: | | Fix our build of python to fix this problem. We can't change the line | number to 'int' because we'd be changing the byte code, but we could | stop the number from wrapping around. | | Manually read each line from the file and feed it to the interpreter as | if we were interactive. We'd lose the line number information if | there's an error in the file (but we can't save numbers over 32K | anyway). I think it would also be friendlier on memory because it | wouldn't byte compile the entire file first. There is a call to pass | strings in this manner, but I don't know if it will actually work this | way. | | Tommy, have you heard of this before? I know I still missing part of | the story because I can create a simple file with 40K lines of: | | a = 0 | | and python accepts it without error.

3 2

re-ordering sys.path
by Neil Schemenauer 06 Sep '01

06 Sep '01

jerome.marant(a)free.fr (Jérôme Marant) in debian-python(a)lists.debian.org: > I am the python-unit maintainer (upstream program called PyUnit) > for python 1.5 and 2.0. > PyUnit has been included in Python 2.1. but I won't give it away > since it does evolve separately from Python releases. > > However, because of PYTHONPATH, the latest version of the module > will never be loaded by the interpreter. > > In 2.0 (and quite the same in 2.1), PYTHONPATH looks like: > > amboise:~$ python2 -c 'import sys; print sys.path' > ['', > '/usr/lib/python2.0', > '/usr/lib/python2.0/plat-linux2', > '/usr/lib/python2.0/lib-dynload', > '/usr/local/lib/python2.0/site-packages', > '/usr/local/lib/site-python', > '/usr/lib/python2.0/site-packages', > '/usr/lib/site-python'] > > So, if the interpreter find the module in its core modules, it > will never see that a newer version of the module was installed > in site-packages. > > Usually, packages installed separately (site-packages) from the > core python modules are more recent that the same modules of > the core, because they evolve faster than python releases. > Manual installations of modules (/usr/local) are usually done > when packages are not up-to-date, so more recent than site modules. > > This is a well known problem since python-xml (PyXML) is both > in 2.0 core and in a separate package and PyXML people have > implemented an ugly hack to work this around. > > So, I'm proposition to reorganize the PYTHONPATH like this : > > ['', > '/usr/local/lib/python2.0/site-packages', > '/usr/local/lib/site-python', > '/usr/lib/site-python' > '/usr/lib/python2.0/site-packages', > '/usr/lib/python2.0', > '/usr/lib/python2.0/plat-linux2', > '/usr/lib/python2.0/lib-dynload', > > ] > > I know that it could lead to some problems but not > that much I think. > > Thanks in advance for your comments. > > PS: it would be usefull to talk to Brendan O'Dea who chose the > same ordering for Perl packages. Will this work? If so, why is it not already done? Neil

4 3

python/dist/src setup.py,1.52,1.53
by Martin von Loewis 06 Sep '01

06 Sep '01

> But what if someone installs their own, better version of curses, > e.g. in /usr/local? Maybe you should only disable it if it's darwin > *and* if it's in a standard location? Or if the header file contains > a certain characteristic string? In that case, the user could still put the appropriate instructions into Modules/Setup, which they'd probably do anyway, since they need special -I/-L options. So I agree with the notion that setup.py should only do so much autoconfiguration, and leave special cases to manual configuration through Modules/Setup. However, I dislike the frequent usage of platform in setup.py, where this patch adds another instance of. I believe the autoconf approach "test for features, not system names" is much more flexible. If the curses module requires certain feature, find a way of testing whether the features are present, and only compile _curses if they are. Then it would not be necessary to check whether the system name is "darwin1". This is problematic in particular as different spellings of the platform are expected: It is "darwin1" in some places, and "Darwin1.2" atleast in another place. Regards, Martin

5 7

[development doc updates]
by Fred L. Drake 06 Sep '01

06 Sep '01

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Documentation for 2.2 alpha 3.

1 0

why doesn't print pass unicode strings on to the file object?
by Fredrik Lundh 06 Sep '01

06 Sep '01

is there any reason why "print" cannot pass unicode strings on to the underlying write method? it would be really nice if this piece of code worked as expected: import sys class Wrapper: def __init__(self, file): self.file = file def write(self, data): self.file.write(data.encode("iso-8859-1", "replace")) sys.stdout = Wrapper(sys.stdout) print u"åäö" under 2.2a2 (and earlier versions), this gives me: Traceback (most recent call last): File "\test.py", line 8, in ? print u"åäö" UnicodeError: ASCII encoding error: ordinal not in range(128) (I'm willing to implement this, if the BDFL says so) </F>

2 1

Re: python/dist/src/Objects complexobject.c,2.42,2.43
by Billy G. Allie 06 Sep '01

06 Sep '01

"Martin v. Loewis" wrote: > > What's the plan for removing this stuff again when UnixWare fixes > > their bugs? > > There is no plan for that at the moment. Please have a look at > > http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=4… > 710 > > for prior discussion on the matter; the submitter has considered > coming up with an autoconf bug test for the problem, but hasn't > followed up with that - testing for the system apparently turned out > to be the easier route. Easier only in that I am a beginner when it comes to using autoconf. If someone can point me in the right direction, I will work on such a test. I also try to keep current on patches with UnixWare. If I find that the bug has been fixed, I can back out the SCO specific changes. -- ____ | Billy G. Allie | Domain....: Bill.Allie(a)mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie(a)email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 |

1 0

python/dist/src/Objects complexobject.c,2.42,2.43
by Martin v. Loewis 05 Sep '01

05 Sep '01

> What's the plan for removing this stuff again when UnixWare fixes > their bugs? There is no plan for that at the moment. Please have a look at http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=4… for prior discussion on the matter; the submitter has considered coming up with an autoconf bug test for the problem, but hasn't followed up with that - testing for the system apparently turned out to be the easier route. One possible approach is that UnixWare releases are regularly tested for the presence of the bug. That would be simplified if the nature of the problem was documented somewhere, that also hasn't happened. To retest, it might be easiest to disable the SCO_ macros, and re-run the test suite; test_math will fail if the bug is still present. Once the version of UnixWare is identified that first fixed the bugs, it hopefully is possible to check the value of __SCO_VERSION__ to tell apart the good, the bad, and the ugly. Regards, Martin

2 1

RE: [Python-checkins] CVS: python/dist/src/Objects complexobject.c,2.42,2.43
by Tim Peters 05 Sep '01

05 Sep '01

[Martin v. L?wis] > Update of /cvsroot/python/python/dist/src/Objects > In directory usw-pr-cvs1:/tmp/cvs-serv12367/Objects > > Modified Files: > complexobject.c > Log Message: > Patch #453627: Define the following macros when compiling on a > UnixWare 7.x system: > SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. > Work aroudn a bug in the SCO UnixWare atan2() implementation. and so on. What's the plan for removing this stuff again when UnixWare fixes their bugs?

1 0

pycnfig.h.in and UW7
by Guido van Rossum 05 Sep '01

05 Sep '01

Hi Martin, Reviewing the checkin message, I just saw some stuff that you added disappear: *************** *** 716,725 **** #define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE #endif - #endif - - /* Define the macros needed if on a UnixWare 7.x system. */ - #if defined(__USLC__) && defined(__SCO_VERSION__) - #define SCO_ACCEPT_BUG /* Use workaround for UnixWare accept() bug */ - #define SCO_ATAN2_BUG /* Use workaround for UnixWare atan2() bug */ - #define STRICT_SYSV_CURSES /* Don't use ncurses extensions */ #endif --- 722,724 ---- The removed lines were added by you a few minutes earlier. I did a full cvs update, ran autoconf and autoheader, and checked in the resulting files (after testing everything first). AFAIK, pyconfig.h.in is a generated file, written by autoheader, so those #defines that you added won't stick. I'm not sure where they *should* go though. The normal way to get a variable defined in pyconfig.h.in is complicated; you have to put a template using #undef in acconfig.h.in, and call AC_DEFINE() in configure.in. I think there are a few places in configure.in where -D options are added to OPT or to CC -- I'm not sure why, it could be that the author of the patch didn't know the proper way, or it could be there was a special reason. --Guido van Rossum (home page: http://www.python.org/~guido/)

3 4

RE: two failing tests on Linux
by Tim Peters 05 Sep '01

05 Sep '01

> With the latest CVS, test_long and test_long_future fail on Linux, > because float(huge) doesn't raise OverflowError but returns inf. I'm > guessing this wasn't your intention; Interesting. Of course it wasn't my intention, but it is relying on the platform ldexp setting errno to ERANGE appropriately. Apparently glibc's does not. Worse, I see the C99 standard *never* requires a conforming libm to set errno for any call of any libm function anymore. From the C99 rationale: In C9X, errno is no longer required to be set to EDOM or ERANGE because that is an impediment to optimization. The Standard has been crafted to neither require nor preclude any popular floating-point implementation. Fucking idiots <0.01 wink>. This means none of Python's fp overflow checking anywhere is worth spit anymore, not even the CHECK macro in mathmodule.c -- to the contrary, C99 *does* require overflowing libm functions to return +- HUGE_VAL, but the CHECK macro considers that a normal (not overflow) case. Without errno to distinguish them, it's impossible to determine whether HUGE_VAL is a normal result or an overflow indicator. The 754 Cabal did their job well here (i.e., they made *portable* numeric C impossible, except across 754 boxes using C99's new 754 gimmicks). Oh well. I don't know how to fix this in general (as above, it sounds truly impossible to do so portably now, without platfrom #ifdefs). I expect I can hack something together for the specific failing tests, though (which I added specifically to find out how reliable ERANGE was -- no time like an alpha for that!).

3 3

PEP 250
by Greg Ward 05 Sep '01

05 Sep '01

Thomas -- have you been following the saga of patch #449054, part of the PEP 250 implementation. If I understand things correctly, this patch only partly implements PEP 250 -- the rest is waiting on a change to bdist_wininst. What's the status of this change? Going to make it in? Please see http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id… if you haven't already... Greg -- Greg Ward - geek-at-large gward(a)python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you.

2 3

Re: [Python-Dev] 2.2a3 release
by Jack Jansen 05 Sep '01

05 Sep '01

> I plan to release 2.2a3 this Thursday or Friday, depending on how > things go. > > Jack, do you want to coordinate the Mac 2.2a3 release with this event? Just plod along, don't tag the Mac subtree, I'll do that later. I think things are up-to-date enough that I'll be able to build with the machine-independent files from the 2.2a3 tree, otherwise I'll add another tag. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

new page for Newbies
by Guido van Rossum 05 Sep '01

05 Sep '01

I finally broke down and created a new page collecting the most important resources for newbies (people who are new at programming): http://www.python.org/doc/Newbies.html We get several emails per day from people asking how to get started, so I figured this definitely serves a need. Please help us making this a better resource -- send your ideas for making the page more effective to webmaster(a)python.org. (Note: more effective could mean removing information as well as adding!) Please add this URL to other collections of links about Python. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

new page for Newbies
by Guido van Rossum 05 Sep '01

05 Sep '01

I finally broke down and created a new page collecting the most important resources for newbies (people who are new at programming): http://www.python.org/doc/Newbies.html We get several emails per day from people asking how to get started, so I figured this definitely serves a need. Please help us making this a better resource -- send your ideas for making the page more effective to webmaster(a)python.org. (Note: more effective could mean removing information as well as adding!) Please add this URL to other collections of links about Python. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

2.2a3 release
by Guido van Rossum 04 Sep '01

04 Sep '01

I plan to release 2.2a3 this Thursday or Friday, depending on how things go. Jack, do you want to coordinate the Mac 2.2a3 release with this event? --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Profiling of generators broken
by Neil Schemenauer 04 Sep '01

04 Sep '01

Here's a simple test: from __future__ import generators def test(): yield 1 yield 2 import profile profile.run("list(test())") It looks like the profile module is getting confused by functions that get called once but return multiple times. My proposed solution is to modify ceval.c so that call_trace(..., PyTrace_CALL, ...) is called when a generator is resumed rather then when it is created. Sound reasonable? Neil

2 1

Re: [Python-checkins] CVS: python/dist/src setup.py,1.52,1.53
by Jack Jansen 04 Sep '01

04 Sep '01

> > Disabled _curses modules on MacOSX. The curses version is a 1994 BSD > > curses, far too old for _cursesmodule.c. > > But what if someone installs their own, better version of curses, > e.g. in /usr/local? Maybe you should only disable it if it's darwin > *and* if it's in a standard location? Or if the header file contains > a certain characteristic string? This is probably a good idea, but I know absolutely nothing about curses, so someone else will have to do this (I think the standard location trick isn't good enough, Apple could supply a more decent curses in a next release, so it'll have to be the string trick). And actually I don't _want_ to know anything about curses, really:-) Maybe you can reopen the bug and assign it to someone who uses curses? I think the bug isn't OSX specific, I would be very surprised if other FreeBSD's at least don't have the same problem (why would Apple take FreeBSD but put an older version of curses in, after all). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

2.2a2 release next Wednesday
by Guido van Rossum 04 Sep '01

04 Sep '01

Barry & I are planning to release Python 2.2a2 next Wednesday (August 19), according to the (updated) schedule in PEP 251. Tomorrow (Saturday, August 15) I plan to fork off a short-lived "release branch", from which the release will be done. Nobody but Barry & I should be checking things in on the release branch. We'll selectively merges the trunk into the branch if needed. We'll merge the branch back to the trunk after the release. Anybody who wants something to show up in 2.2a2 would be wise to check it in today or before dawn tomorrow. Please mail me if you need me to wait for something specific. PS Martin: I currently have two failing tests! - test_b1 crashes (in the "float" subtest): Traceback (most recent call last): File "../Lib/test/test_b1.py", line 259, in ? if float(unicode(" \u0663.\u0661\u0664 ")) != 3.14: ValueError: invalid literal for float(): \u0663.\u0661\u0664 - test_format.py fails: u'abc %\\\u3000' % 1 works? ... no Unexpected exceptions.ValueError : "unsupported format character '\\' (0x5c) at index 5" I expect these are casualties of the --disable-unicode checkins. --Guido van Rossum (home page: http://www.python.org/~guido/)

10 21

Re: [Python-checkins] CVS: python/dist/src setup.py,1.52,1.53
by Guido van Rossum 04 Sep '01

04 Sep '01

> Disabled _curses modules on MacOSX. The curses version is a 1994 BSD > curses, far too old for _cursesmodule.c. But what if someone installs their own, better version of curses, e.g. in /usr/local? Maybe you should only disable it if it's darwin *and* if it's in a standard location? Or if the header file contains a certain characteristic string? --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

-Dwarn, long->double overflow (was RE: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.219,1.220)
by Tim Peters 04 Sep '01

04 Sep '01

[Guido] > + + A new command line option, -D<arg>, is added to control run-time > + warnings for the use of classic division. > ... > + Using -Dwarn issues a run-time warning about all uses of classic > + division for int, long, float and complex arguments. I'm unclear on why we warn about classic division when a float or complex is involved: C:\Code\python\PCbuild>python -Dwarn Python 2.2a2+ (#22, Aug 31 2001, 14:36:57) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> 2./3. __main__:1: DeprecationWarning: classic float division 0.66666666666666663 >>> Given that this is going to return the same result even in Python 3.0, what is it warning me about? That is, as an end user, I'm being warned about behavior I can't do anything about, and behavior that Python isn't going to change anyway. Different issue: I would like to add OverflowError when coercion of long to float yields a senseless result. PEP 238 mentions this as a possibility, and >>> from __future__ import division >>> x = 1L << 3000 >>> x/(2*x) -1.#IND >>> really sucks. For that matter, >>> float(1L << 3000) 1.#INF >>> has always sucked; future division just makes it suck harder <wink>. Any objections to raising OverflowError here? Note this is a bit painful for a bogus reason: PyFloat_AsDouble returns a double, and nothing in the codebase now checks it for a -1.0 error return (despite that it can already produce one). So half the effort would be repairing code currently ignoring the possibility of error. Third issue: I don't see a *good* reason for the future-division x/(2*x) above not to return 0.5. long_true_divide could be made smart enough to do that (more generally, to return a good float approximation whenever the true result is representable as a float).

6 14

Python
by Martin v. Loewis 03 Sep '01

03 Sep '01

[I just filled out the form at the URL; if they get multiple registrations, they probably have to pick one of them]. Liebes c't-Shareware-Team, Das klingt ja verdammt nach einer automatischen Email; mit ein wenig Recherche wäre wohl auch die Email-Adresse des Python-Erfinders rausgesprungen... Auf jeden Fall habe ich jetzt Euer Formular ausgefüllt, ich habe dabei *nicht* den Namen des Python-Erfinders angegeben; als zu veröffentlichende Adresse habe ich python-list(a)python.org angegeben. Diese Adresse ist ebenfalls mit einer grossen Email-Liste verbunden sowie mit comp.lang.python; ein Nutzer, der also an diese Adresse schreibt, sendet an viele Leser. MfG, Martin

1 0

CVS tree doesn't build currently
by Jack Jansen 03 Sep '01

03 Sep '01

I can't build from the CVS tree right now (confirmed on Irix and OSX): setup.py crashes. Here's the stacktrace: CC='cc' LDSHARED='ld -shared -all' ./python -E ./setup.py build Traceback (most recent call last): File "./setup.py", line 708, in ? main() File "./setup.py", line 702, in main scripts = ['Tools/scripts/pydoc'] File "/ufs/jack/src/python/Lib/distutils/core.py", line 101, in setup _setup_distribution = dist = klass(attrs) File "/ufs/jack/src/python/Lib/distutils/dist.py", line 129, in __init__ setattr(self, method_name, getattr(self.metadata, method_name)) AttributeError: DistributionMetadata instance has no attribute 'get___doc__' -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

3 2

CVS tags, unix Python and MacPython
by Martin v. Loewis 03 Sep '01

03 Sep '01

> Things will get worse with the 2.2a2 release, as there are a couple > of things that I definitely want in there that aren't finished yet, > so it'll be at least another week until I'm done, and moreover I'll > have to be making a few (minor) mods to files outside the Mac > subtree. From a procedural, quality-guaranteeing point of view, I think you shouldn't release anything as "MacPython 2.2a2" which does not come from the 2.2a2 tag (and, as Guido explains, you should never move a tag). There is no such thing as the "Unix release" of Python 2.2a2; there is the source distribution, and there happens to be a Windows binary (which I trust came from the tagged source); everything coordinated by the release manager. IOW, if your changes missed the release date by a few days, tough luck - PEP 251 is there precisely for the purpose to align your changes with the rest of the tree, and to enable you to get a consistent, if not perfect, code base included in the alpha release. In theory, all you have to do is to compile this to get a binary distribution, perhaps with any add-on modules that you also want to distribute. It seems that nobody else is making much fuss about this, so I'll shut up now... Regards, Martin

3 2

Re: [Python-Dev] CVS tags, unix Python and MacPython
by Jack Jansen 03 Sep '01

03 Sep '01

> Jack doesn't have that kind of intimate access to (and veto power over!) the > release process, so there's going to be some kind of compromise somewhere. > I think it should be limited to post-release changes in the Mac subtree > alone, and that he should tag the whole tree with mac-rIJAK for easy > reproducibility later. Yes, I think I'll do just that. I don't like the proliferation of tags, but in general there's no way I can be sure to keep up with the unix/windows release process, there being other things needing my time too:-) Although for 2.2a3 this weeks things look pretty good, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Python
by c't-Shareware-Team 03 Sep '01

03 Sep '01

English version at the end of this e-mail Sehr geehrter Programmautor, wir betreiben unter http://www.heise.de/ct/shareware/ ein gut besuchtes Verzeichnis von Free- und Shareware- Programmen. Einer unserer Besucher hat uns auf Ihr Programm Python aufmerksam gemacht. Gerne würden wir Ihr Programm in unser Verzeichnis aufnehmen. Daher möchte ich Sie bitten Ihr Programm unter http://www.heise.de/ct/shareware/default.shtml?ad=af&v=13 einzutragen. Mit freundlichen Grüßen, Ihr c't-Shareware-Team *** Dear Program Author, At http://www.heise.de/ct/shareware/, we keep a popular Free and Shareware archive. One of our visitors has recommended your program Python. In order to be able to include your program in our archive, we would like to ask you to provide further details to your program at http://www.heise.de/ct/shareware/default.shtml?ad=af&v=13&lang=e Yours, c't Shareware Team

1 0

3-arg float pow()
by Tim Peters 03 Sep '01

03 Sep '01

Python's builtin 3-argument pow() exists because, e.g., >>> pow(3L, 500, 7) 2L >>> can be done very much faster, and with much less memory, than >>> 3L**500 % 7 2L >>> There isn't any compelling use I know of for 3-arg pow() given float arguments, though, and what you get back is a platform-dependent accident: >>> pow(3., 500., 7.) 4.0 >>> You may get some other integer there, or an Infinity or a NaN, depending on the Python release, and the compiler used to build Python, and the configuration of your libm. That example was done under CVS 2.2a2+ on Windows; here's the same thing but under 2.2.1: >>> pow(3., 500., 7.) 0.0 >>> Since 3-argument float pow() *appears* to be at best useless, I'm taking it away in 2.2a3, unless someone can testify to a reasonable use case that's actually used. more-trouble-than-it's-worth-if-it-isn't-worth-anything-ly y'rs - tim

1 0

Change from "config.h" to "pyconfig.h" may be a ticking #include bomb
by Martin v. Loewis 02 Sep '01

02 Sep '01

> To pick up this sort of bug, perhaps "make install" should attempt > to remove config.h if it exists in the target include directory? I don't think so. Once Python 2.2 is released, it will install its headers into <prefix>/include/python2.2, which will be empty since it is the first usage ever of this directory; the previous *release* installed its files into a different location. Giving the advice to people to remove their <prefix>/include/python2.2, and (most of) <prefix>/lib/python2.2 if they update from an earlier alpha release might be a good idea, though: there might be other removed or renamed files whose absence they would not notice. Regards, Martin

1 0

Would it make sense to issue an extra alpha next week?
by Guido van Rossum 01 Sep '01

01 Sep '01

When I was updating the NEWS file this morning, I realized that we've already added a truckload of nifty stuff in the 9 days since 2.2a2 was released: int overflows return longs, classic division warnings, subclassing builtins, super, getset, two fixes to float literals, the new GC API, and PyString_FromFormat[V]. I expect that I'll be concentrating on documentation for the type/class unification next. While writing the first piece of documentation, I realized that, sadly, several more advanced things aren't available in 2.2a2 yet. The next alpha is planned for Sept. 19, almost three weeks off still. Does anybody object against the release of an extra release, 2.2a3, around Sept. 5? We could do 2.2a4 on Sept. 19, or a week later if the schedule gets too crowded. --Guido van Rossum (home page: http://www.python.org/~guido/)

3 2