Mailman 3 August 2000 - Python-Dev

Threads & autoconf
by Thomas Wouters Aug. 30, 2000

Aug. 30, 2000

I'm trying to clean up the autoconf (and README) mess wrt. threads a bit, but I think I need some hints ;) I can't figure out why there is a separate --with-dec-threads option... Is there a reason it can't be autodetected like we do for other thread systems ? Does DEC Unix do something very different but functional when leaving out the '-threads' option (which is the only thing -dec- adds) or is it just "hysterical raisins" ? And then the systems that need different library/compiler flags/settings... I suspect noone here has one of those machines ? It'd be nice if we could autodetect this without trying every combination of flags/libs in autoconf :P (But then, if we could autodetect, I assume it would've been done long ago... right ? :) Do we know if those systems still need those separate flags/libs ? Should we leave a reference to them in the README, or add a separate README.threads file with more extensive info about threads and how to disable them ? (I think README is a bit oversized, but that's probably just me.) And are we leaving threads on by default ? If not, the README will have to be re-adjusted again :) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

If you thought there were too many PEPs...
by Greg Ward Aug. 30, 2000

Aug. 30, 2000

...yow: the Perl community is really going overboard in proposing enhancements: [from the Perl "daily" news] > [3] Perl 6 RFCs Top 150 Mark; New Perl 6 Lists Added [Links] > > The number of [4]Perl 6 RFCs hit 161 today. The 100th RFC was > [5]Embed full URI support into Perl by Nathan Wiger, allowing > URIs like "file:///local/etc/script.conf" to be passed to builtin > file functions and operators. The 150th was [6]Extend regex > syntax to provide for return of a hash of matched subpatterns by > Kevin Walker, and the latest, 161, is [7]OO Integration/Migration > Path by Matt Youell. > > New [8]Perl 6 mailing lists include perl6-language- sublists > objects, datetime, errors, data, and regex. perl6-bootstrap is > being closed, and perl6-meta is taking its place (the subscriber > list will not be transferred). [...] > 3. http://www.news.perl.org/perl-news.cgi?item=967225716%7C10542 > 4. http://dev.perl.org/rfc/ > 5. http://dev.perl.org/rfc/100.pod > 6. http://dev.perl.org/rfc/150.pod > 7. http://dev.perl.org/rfc/161.pod > 8. http://dev.perl.org/lists.shtml -- Greg Ward - software developer gward(a)mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367

9 10

NetBSD compilation bug - I need help (was: Re: Python bug)
by Trent Mick Aug. 30, 2000

Aug. 30, 2000

On Tue, Aug 29, 2000 at 11:29:22PM -0400, Jeremy Hylton wrote: > You have one open Python bug that is assigned to you and given a > priority seven or higher. I would like to resolve this bugs before > the 2.0b1 release. > > The bug is: > 112289 | NetBSD1.4.2 build issue > Sorry to have let this one get a little stale. I can give it a try. A couple of questions: 1. Who reported this bug? He talked about providing more information and I would like to speak with him. I cannot find his email address. 2. Does anybody have a NetBSD1.4.2 (or close) machine that I can get shell access to? Do you know if they have such a machine at SourceForge that users can get shell access to? Or failing that can someone with such a machine give me the full ./configure and make output and maybe run this command: find /usr/include -name "*" -type f | xargs -l grep -nH _TELL64 and give me the output. If I come up blank on both of these then I can't really expect to fix this bug. Thanks, Trent -- Trent Mick TrentM(a)ActiveState.com

1 0

Re: [Python-Dev] stack check on Unix: any suggestions?
by Jack Jansen Aug. 30, 2000

Aug. 30, 2000

My SGI has getrlimit(RLIMIT_STACK) which should do the trick. But maybe this is an sgi-ism? Otherwise RLIMIT_VMEM and subtracting brk() may do the trick. While thinking about this, though, I suddenly realised that my (new, faster) Mac implementation of PyOS_CheckStack will fail miserably in any other than the main thread, something I'll have to fix shortly. Unix code will also have to differentiate between running on the main stack and a sub-thread stack, probably. And I haven't looked at the way PyOS_CheckStack is implemented on Windows, but it may well also share this problem. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Re: [Python-Dev] stack check on Unix: any suggestions?
by Jack Jansen Aug. 30, 2000

Aug. 30, 2000

A completely different way to go about getting the stacksize on Unix is by actually committing the space once in a while. Something like (typed in as I'm making it up): STACK_INCREMENT=128000 prober() { char space[STACK_INCREMENT]; space[0] = 1; /* or maybe for(i=0;i<STACK_INCREMENT; i+=PAGESIZE) or so */ space[STACK_INCREMENT-1] = 1; } jmp_buf buf; catcher() { longjmp(buf); return 1; } PyOS_CheckStack() { static char *known_safe; char *here; if (we-are-in-a-thread()) go do different things; if ( &here > known_safe ) return 1; keep-old-SIGSEGV-handler; if ( setjmp(buf) ) return 0; signal(SIGSEGV, catcher); prober(); restore-old-SIGSEGV-handler; known_safe = &here - (STACK_INCREMENT - PYOS_STACK_MARGIN); return 1; } -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Python-Dev] MacPython 2.0?
by Jack Jansen Aug. 30, 2000

Aug. 30, 2000

> Has Jack or anyone else been building Mac versions of 2.0 and making them > available somewhere? I seem to have fallen off the MacPython list and > haven't taken the time to investigate (perhaps I set subscription to NOMAIL > and forgot that crucial point). I have no compilation tools on my Mac, so > while I'd like to try testing things a little bit there, I am entirely > dependent on others to provide me with something runnable. I'm waiting for Guido to release a 2.0 and then I'll quickly follow suit. I have almost everything in place for the first alfa/beta. But, if you're willing to be my guineapig I'd be happy to build you a distribution of the current state of things tonight or tomorrow, let me know. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

stack check on Unix: any suggestions?
by Jeremy Hylton Aug. 30, 2000

Aug. 30, 2000

Does anyone have suggestions for how to detect unbounded recursion in the Python core on Unix platforms? Guido assigned me bug 112943 yesterday and gave it priority 9. http://sourceforge.net/bugs/?func=detailbug&bug_id=112943&group_id=5470 The bug in question causes a core dump on Unix because of a broken __radd__. There's another bug (110615) that does that same thing with recursive invocations of __repr__. And, of course, there's: def foo(x): return foo(x) foo(None) I believe that these bugs have been fixed on Windows. Fredrik confirmed this for one of them, but I don't remember which one. Would someone mind confirming and updating the records in the bug tracker? I don't see an obvious solution. Is there any way to implement PyOS_CheckStack on Unix? I imagine that each platform would have its own variant and that there is no hope of getting them debugged before 2.0b1. We could add some counters in eval_code2 and raise an exception after some arbitrary limit is reached. Arbitrary limits seem bad -- and any limit would have to be fairly restrictive because each variation on the bug involves a different number of C function calls between eval_code2 invocations. We could special case each of the __special__ methods in C to raise an exception upon recursive calls with the same arguments, but this is complicated and expensive. It does not catch the simplest version, the foo function above. Does stackless raise exceptions cleanly on each of these bugs? That would be an argument worth mentioning in the PEP, eh? Any other suggestions are welcome. Jeremy

11 24

[PEP 224] Attribute Docstrings
by M.-A. Lemburg Aug. 30, 2000

Aug. 30, 2000

An HTML version of the attached can be viewed at http://python.sourceforge.net/peps/pep-0224.html Even though the implementation won't go into Python 2.0, it is worthwhile discussing this now, since adding these attribute docstrings to existing code already works: Python simply ignores them. What remains is figuring out a way to make use of them and this is what the proposal is all about... -- PEP: 224 Title: Attribute Docstrings Version: $Revision: 1.2 $ Author: mal(a)lemburg.com (Marc-Andre Lemburg) Status: Draft Type: Standards Track Python-Version: 2.1 Created: 23-Aug-2000 Post-History: Introduction This PEP describes the "attribute docstring" proposal for Python 2.0. This PEP tracks the status and ownership of this feature. It contains a description of the feature and outlines changes necessary to support the feature. The CVS revision history of this file contains the definitive historical record. Rationale This PEP proposes a small addition to the way Python currently handles docstrings embedded in Python code. Python currently only handles the case of docstrings which appear directly after a class definition, a function definition or as first string literal in a module. The string literals are added to the objects in question under the __doc__ attribute and are from then on available for introspection tools which can extract the contained information for help, debugging and documentation purposes. Docstrings appearing in locations other than the ones mentioned are simply ignored and don't result in any code generation. Here is an example: class C: "class C doc-string" a = 1 "attribute C.a doc-string (1)" b = 2 "attribute C.b doc-string (2)" The docstrings (1) and (2) are currently being ignored by the Python byte code compiler, but could obviously be put to good use for documenting the named assignments that precede them. This PEP proposes to also make use of these cases by proposing semantics for adding their content to the objects in which they appear under new generated attribute names. The original idea behind this approach which also inspired the above example was to enable inline documentation of class attributes, which can currently only be documented in the class's docstring or using comments which are not available for introspection. Implementation Docstrings are handled by the byte code compiler as expressions. The current implementation special cases the few locations mentioned above to make use of these expressions, but otherwise ignores the strings completely. To enable use of these docstrings for documenting named assignments (which is the natural way of defining e.g. class attributes), the compiler will have to keep track of the last assigned name and then use this name to assign the content of the docstring to an attribute of the containing object by means of storing it in as a constant which is then added to the object's namespace during object construction time. In order to preserve features like inheritance and hiding of Python's special attributes (ones with leading and trailing double underscores), a special name mangling has to be applied which uniquely identifies the docstring as belonging to the name assignment and allows finding the docstring later on by inspecting the namespace. The following name mangling scheme achieves all of the above: __doc__<attributename>__ To keep track of the last assigned name, the byte code compiler stores this name in a variable of the compiling structure. This variable defaults to NULL. When it sees a docstring, it then checks the variable and uses the name as basis for the above name mangling to produce an implicit assignment of the docstring to the mangled name. It then resets the variable to NULL to avoid duplicate assignments. If the variable does not point to a name (i.e. is NULL), no assignments are made. These will continue to be ignored like before. All classical docstrings fall under this case, so no duplicate assignments are done. In the above example this would result in the following new class attributes to be created: C.__doc__a__ == "attribute C.a doc-string (1)" C.__doc__b__ == "attribute C.b doc-string (2)" A patch to the current CVS version of Python 2.0 which implements the above is available on SourceForge at [1]. Caveats of the Implementation Since the implementation does not reset the compiling structure variable when processing a non-expression, e.g. a function definition, the last assigned name remains active until either the next assignment or the next occurrence of a docstring. This can lead to cases where the docstring and assignment may be separated by other expressions: class C: "C doc string" b = 2 def x(self): "C.x doc string" y = 3 return 1 "b's doc string" Since the definition of method "x" currently does not reset the used assignment name variable, it is still valid when the compiler reaches the docstring "b's doc string" and thus assigns the string to __doc__b__. A possible solution to this problem would be resetting the name variable for all non-expression nodes. Copyright This document has been placed in the Public Domain. References [1] http://sourceforge.net/patch/?func=detailpatch&patch_id=101264&group_id=5470 -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

6 15

MacPython 2.0?
by Skip Montanaro Aug. 30, 2000

Aug. 30, 2000

Has Jack or anyone else been building Mac versions of 2.0 and making them available somewhere? I seem to have fallen off the MacPython list and haven't taken the time to investigate (perhaps I set subscription to NOMAIL and forgot that crucial point). I have no compilation tools on my Mac, so while I'd like to try testing things a little bit there, I am entirely dependent on others to provide me with something runnable. Thx, Skip

1 0

Problem reloading mx.DateTime in PyApache
by Skip Montanaro Aug. 29, 2000

Aug. 29, 2000

Don't know if this should concern us in preparation for 2.0b1 release, but the following came across c.l.py this morning. FYI. Skip ------- start of forwarded message (RFC 934 encapsulation) ------- X-Digest: Python-list digest, Vol 1 #3344 - 13 msgs Message: 11 Newsgroups: comp.lang.python Organization: Concentric Internet Services Lines: 41 Message-ID: <39ABD9A1.A8ECDEC8(a)faxnet.com> NNTP-Posting-Host: 208.36.195.178 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Path: news!uunet!ffx.uu.net!newsfeed.mathworks.com!feeder.via.net!newshub2.rdc1.sfba.home.com!news.home.com!newsfeed.concentric.net!global-news-master Xref: news comp.lang.python:110026 Precedence: bulk List-Id: General discussion list for the Python programming language <python-list.python.org> From: Jon LaCour <jal(a)faxnet.com> Sender: python-list-admin(a)python.org To: python-list(a)python.org Subject: Python Problem - Important! Date: 29 Aug 2000 15:41:00 GMT Reply-To: jal(a)faxnet.com I am beginning development of a very large web application, and I would like to use Python (no, Zope is not an option). PyApache seems to be my best bet, but there is a MASSIVE problem with Python/PyApache that prevents it from being even marginally useful to me, and to most major software companies. My product requires database access, and the database module that I use for connecting depends on a library called mxDateTime. This is a very robust library that is in use all over our system (it has never given us problems). Yet, when I use PyApache to connect to a database, I have major issues. I have seen this same problem posted to this newsgroup and to the PyApache mailing list several times from over a year ago, and it appears to be unresolved. The essential problem is this: the second time a module is loaded, Python has cleaned up its dictionaries in its cleanup mechanism, and does not allow a re-init. With mxDateTime this gives an error: "TypeError: call of non-function (type None)" Essentially, this is a major problem in either the Python internals, or in PyApache. After tracing the previous discussions on this issue, it appears that this is a Python problem. I am very serious when I say that this problem *must* be resolved before Python can be taken seriously for use in web applications, especially when Zope is not an option. I require the use of Apache's security features, and several other Apache extensions. If anyone knows how to resolve this issue, or can even point out a way that I can resolve this *myself* I would love to hear it. This is the single stumbling block standing in the way of my company converting almost entirely to Python development, and I am hoping that python developers will take this bug and smash it quickly. Thanks in advance, please cc: all responses to my email address at jal(a)faxnet.com. Jonathan LaCour Developer, VertiSoft ------- end -------

4 6