Mailman 3 June 2001 - Python-Dev

RE: What happened to Idle's extend.py?
by Tim Peters June 4, 2001

June 4, 2001

Guido's on vacation. Anyone have an answer for this? I don't, and can't make time to dig into now. If you can, David's address showed up as mailto:boogiemorg@aol.com > -----Original Message----- > From: python-list-admin(a)python.org > [mailto:python-list-admin@python.org]On Behalf Of David Morgenthaler > Sent: Wednesday, May 23, 2001 6:20 PM > To: python-list(a)python.org > Subject: What happened to Idle's extend.py? > > > Idle-0.3, shipped with Python 1.5.2 had an extend.py module that was > used to extend Idle. We've used this extensively, building entire > "applications" as Idle extensions. > > Now that we're moving to Python 2.1, we find the same old directions > for extending Idle (in extend.txt), but there appears to be no > extend.py in Idle-0.8. > > Does anyone know how we can add extensions to Idle-0.8? > > Thanks in advance, > David > -- > http://mail.python.org/mailman/listinfo/python-list

2 2

Re: [Python-Dev] readline not getting built when .so symlink doesn't exist
by Michael Hudson June 4, 2001

June 4, 2001

Skip Montanaro <skip(a)pobox.com> writes: > I recently upgraded to Mandrake 8.0. I find that the readline > module is no longer getting built. When building, it builds rgbimb > followed immediately by crypt. Readline, which is tested for in > between, is not built. Apparently, it can't find one of the > libraries required to build it. On my system, both readline and > termcap are in /lib. Neither has a static version available and > neither as a plain .so file available. The .so file always has a > version number tacked onto the end: > > % ls -l /lib/libtermcap* /lib/libreadline* > lrwxrwxrwx 1 root root 18 May 29 10:53 /lib/libreadline.so.4 -> libreadline.so.4.1 > -rwxr-xr-x 1 root root 152440 Mar 25 01:26 /lib/libreadline.so.4.1 > lrwxrwxrwx 1 root root 19 May 29 10:53 /lib/libtermcap.so.2 -> libtermcap.so.2.0.8 > -rwxr-xr-x 1 root root 11608 Mar 26 10:32 /lib/libtermcap.so.2.0.8 > > If I create the necessary .so symlinks it builds okay. > > Perhaps this is a bug in Mandrake 8.0 (it wouldn't be the first > one), but if it is valid for shared libraries to be installed with > only a version-numbered .so file, then it seems to me that distutils > ought to handle that. Hmm. Does compiling a proggie $ gcc foo.c -lreadline work? It doesn't here if I move libreadline.so & libreadline.a out of the way. If the C compiler isn't going to find readline, there ain't much point distutils trying to find it... > There are several programs in /usr/bin on my machine that seem to be > dynamically linked to libreadline. Those things will be directly linked to libreadline.so.whatever; I believe the libfoo.so files are only for the (compile time) linker's benefit. > In addition, /usr/lib/python2.0/lib-dynload/readline.so exists, > which suggests that the .so-without version number is valid as far > as ld is concerned. ld != ld.so. Do you need a readline-devel package or something? Cheers, M. -- It's actually a corruption of "starling". They used to be carried. Since they weighed a full pound (hence the name), they had to be carried by two starlings in tandem, with a line between them. -- Alan J Rosenthal explains "Pounds Sterling" on asr

2 1

Status of 2.0.1?
by barry＠digicool.com June 4, 2001

June 4, 2001

I've just fixed two buglets in the regression test suite for Python 2.0.1 (release20-maint branch). Now I get the following results from regrtest: 88 tests OK. 20 tests skipped: test_al test_audioop test_cd test_cl test_dbm test_dl test_gl test_imageop test_imgfile test_largefile test_linuxaudiodev test_minidom test_nis test_pyexpat test_rgbimg test_sax test_sunaudiodev test_timing test_winreg test_winsound Has anybody else tested out the 2.0.1 branch on anything? I'm going to run some quick tests with Mailman 2.0.x on Python 2.0.1 over the next hour or so. I'm just wondering what's left to do for this release, and how I can help out. -Barry

1 0

struct.getorder() ?
by Greg Wilson June 4, 2001

June 4, 2001

The 'struct' module allows packing and unpacking orders to be specified, but doesn't provide a hook to report on the order used by the machine the script is running on. As I'm likely going to be using this module in future runs of my course, I'd like to add 'struct.getorder()', which would return either "<" or ">" (the characters used to signal little-endian and big-endian respectively). Does this duplicate something in some other standard module? Does it seem like a sensible idea? Thanks Greg ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.

2 1

RE: [Python-Dev] struct.getorder() ?
by Greg Wilson June 4, 2001

June 4, 2001

> Python 2.0 introduced sys.byteorder; check it out: > http://www.python.org/doc/current/lib/module-sys.html Woo hoo! Thanks, Fred --- should've guessed someone would be ahead of me :-). Greg ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.

1 0

readline not getting built when .so symlink doesn't exist
by Skip Montanaro June 4, 2001

June 4, 2001

I recently upgraded to Mandrake 8.0. I find that the readline module is no longer getting built. When building, it builds rgbimb followed immediately by crypt. Readline, which is tested for in between, is not built. Apparently, it can't find one of the libraries required to build it. On my system, both readline and termcap are in /lib. Neither has a static version available and neither as a plain .so file available. The .so file always has a version number tacked onto the end: % ls -l /lib/libtermcap* /lib/libreadline* lrwxrwxrwx 1 root root 18 May 29 10:53 /lib/libreadline.so.4 -> libreadline.so.4.1 -rwxr-xr-x 1 root root 152440 Mar 25 01:26 /lib/libreadline.so.4.1 lrwxrwxrwx 1 root root 19 May 29 10:53 /lib/libtermcap.so.2 -> libtermcap.so.2.0.8 -rwxr-xr-x 1 root root 11608 Mar 26 10:32 /lib/libtermcap.so.2.0.8 If I create the necessary .so symlinks it builds okay. Perhaps this is a bug in Mandrake 8.0 (it wouldn't be the first one), but if it is valid for shared libraries to be installed with only a version-numbered .so file, then it seems to me that distutils ought to handle that. There are several programs in /usr/bin on my machine that seem to be dynamically linked to libreadline. In addition, /usr/lib/python2.0/lib-dynload/readline.so exists, which suggests that the .so-without version number is valid as far as ld is concerned. Skip

1 0

Re: [Python-Dev] another dict crasher
by Michael Hudson June 3, 2001

June 3, 2001

"Tim Peters" <tim.one(a)home.com> writes: > It would be better in this case to go back to the top and start > over. Yes. What you checked in is obviously better. I'll stick to being the bearer of bad tidings... > However, then an adversarial user can construct a case that never > terminates. I seem to have done this - it was odd, though - it only loops when I bump the dict to fairly enormous preportions for reasons I don't really (want to) understand. > Unclear what to do. Not worrying about it seems entirely reasonable - I now have sitting on my hard drive the wierdest way of spelling "while 1: pass" *I've* ever seen. and-I'll-stop-poking-holes-now-ly y'rs m. -- The rapid establishment of social ties, even of a fleeting nature, advance not only that goal but its standing in the uberconscious mesh of communal psychic, subjective, and algorithmic interbeing. But I fear I'm restating the obvious. -- Will Ware, comp.lang.python

2 1

new PEP candidates
by David Goodger June 3, 2001

June 3, 2001

I have just posted three related PEP candidates to the Doc-SIG: - PEP: Docstring Processing System Framework http://mail.python.org/pipermail/doc-sig/2001-June/001855.html - PEP: DPS Generic Implementation Details http://mail.python.org/pipermail/doc-sig/2001-June/001856.html - PEP: Docstring Conventions http://mail.python.org/pipermail/doc-sig/2001-June/001857.html These are all part of the newly created Python Docstring Processing System project, http://docstring.sf.net. Barry: Please assign PEP numbers to these if possible. Once PEP numbers have been assigned, I will post to comp.lang.python. Thanks. A related project is the second draft of reStructuredText, a docstring markup syntax definition. The project is http://structuredtext.sf.net, and I've posted the following to Doc-SIG: - An Introduction to reStructuredText http://mail.python.org/pipermail/doc-sig/2001-June/001858.html - Problems With StructuredText http://mail.python.org/pipermail/doc-sig/2001-June/001859.html - reStructuredText Markup Specification http://mail.python.org/pipermail/doc-sig/2001-June/001860.html - Python Extensions to the reStructuredText Markup Specification http://mail.python.org/pipermail/doc-sig/2001-June/001861.html I am not seeking PEP status for reStructuredText at this time; I think it's one step too far removed from the Python language to warrant a PEP. If you think it *should* be a PEP, I will be happy to convert it. -- David Goodger dgoodger(a)bigfoot.com Open-source projects: - Python Docstring Processing System: http://docstring.sf.net - reStructuredText: http://structuredtext.sf.net - The Go Tools Project: http://gotools.sf.net

1 0

Re: [Python-Dev] another dict crasher
by Michael Hudson June 3, 2001

June 3, 2001

"Tim Peters" <tim.one(a)home.com> writes: > > I can't easily see other examples of the problem; there certainly > > might be things you could do with comparisons that could trigger > > crashes, but that code's so hairy that it's almost impossible for me > > to be sure. > > It's easy to be sure: any code that tries to remember anything about a dict > (ditto any mutable object) across a "dangerous" call, other than the mere > address of the object, is a place you *can* provoke a core dump. It may not > be easy to provoke, and a given provoking test case may not fail across all > platforms, or even every time you run it on a single platform, but it's "an > obvious" hole all the same. Ah, like this one: dict = {} # let's force dict to malloc its table for i in range(1,10): dict[i] = i class Machiavelli2: def __eq__(self, other): dict.clear() return 1 def __hash__(self): return 0 dict[Machiavelli2()] = Machiavelli2() print dict[Machiavelli2()] I'll attach a patch, but it's another branch inside lookdict (though not lookdict_string which is I guess the really performance sensitive one). Cheers, M. Index: dictobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/dictobject.c,v retrieving revision 2.100 diff -c -1 -r2.100 dictobject.c *** dictobject.c 2001/06/02 08:27:39 2.100 --- dictobject.c 2001/06/02 11:36:47 *************** *** 273,274 **** --- 273,281 ---- cmp = PyObject_RichCompareBool(ep->me_key, key, Py_EQ); + if (ep0 != mp->ma_table) { + PyErr_SetString(PyExc_RuntimeError, + "dict resized on comparison"); + ep = mp->ma_table; + while (ep->me_value) ep++; + return ep; + } if (cmp > 0) { *************** *** 310,311 **** --- 317,325 ---- cmp = PyObject_RichCompareBool(ep->me_key, key, Py_EQ); + if (ep0 != mp->ma_table) { + PyErr_SetString(PyExc_RuntimeError, + "dict resized on comparison"); + ep = mp->ma_table; + while (ep->me_value) ep++; + return ep; + } if (cmp > 0) { Here's another test case to work out the second of those new if statements: dict = {} # let's force dict to malloc its table for i in range(1,10): dict[i] = i class Machiavelli3: def __init__(self, id): self.id = id def __eq__(self, other): if self.id == other.id: dict.clear() return 1 else: return 0 def __repr__(self): return "%s(%s)"%(self.__class__.__name__, self.id) def __hash__(self): return 0 dict[Machiavelli3(1)] = Machiavelli3(0) dict[Machiavelli3(2)] = Machiavelli3(0) print dict[Machiavelli3(2)] -- M-x psych[TAB][RETURN] -- try it

2 1

Re: [Python-Dev] What should changing/setting __getattr__ (and similars) after classdef time do ?
by Samuele Pedroni June 2, 2001

June 2, 2001

Hi. Is this a case that only the BDFL could know and pronounce on ... or I'm missing somenthing ... Thanks for any feedback, Samuele Pedroni. ----- Original Message ----- From: Samuele Pedroni <pedroni(a)inf.ethz.ch> To: <python-dev(a)python.org> Sent: Friday, June 01, 2001 2:49 PM Subject: [Python-Dev] __xxxattr__ caching semantic > Hi. > > What is the intendend semantic wrt to __xxxattr__ caching: > > class X: > pass > > def cga(self,name): > print name > > def iga(name): > print name > > x=X() > x.__dict__['__getattr__'] = iga # 1. > x.__getattr__ = iga # 2. > X.__dict__['__getattr__'] = cga # 3. > X.__getattr__ = cga # 4. > x.a > > for the manual > > http://www.python.org/doc/current/ref/customization.html > > with all the variants x.a should fail, they should have > no effect. In practice 4. work. > > Is that an implementation manual mismatch, is this indented, is there > code around using 4. ? > > I'm asking this because jython has differences/bugs in this respect? > > I imagine that 1.-4. should work for all other __magic__ methods > (this should be fixed in jython for some methods), > OTOH jython has such a restriction on __del__ too, and this one cannot > be removed (is not simply a matter of caching/non caching). > > regards, Samuele Pedroni. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev >

2 3