Mailman 3 October 2001 - Python-Dev

Re: [Python-Dev] Fixing send()
by Anthony Baxter 29 Oct '01

29 Oct '01

> Will do - I plan to check in a bunch of fixes tomorrow morning. (continuing > gdb hell today). Just an update to this - my plans were wrecked by a cablemodem outage, however I'm spending tomorrow on branch mgmt - work is keen for me to take some of the 6 weeks leave I've built up, so I'm taking a few days off to work on this. As far as trying to delegate checkins of code - would people prefer I post a big list here, mail the original authors of the patches, or just do it myself? Anthony

3 2

class dict of subtyped types
by Thomas Heller 29 Oct '01

29 Oct '01

C:\>python Python 2.2b1+ (#25, Oct 19 2001, 14:30:05) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class INT(int): pass ... >>> INT.__dict__ <dict-proxy object at 0x00769680> >>> INT.__dict__.update Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'dict-proxy' object has no attribute 'update' >>> dir(INT.__dict__) ['__class__', '__contains__', '__delattr__', '__getattribute__', '__getitem__', '__hash__' , '__init__', '__iter__', '__len__', '__new__', '__reduce__', '__repr__', '__setattr__', ' __str__', 'copy', 'get', 'has_key', 'items', 'keys', 'values'] >>> Other dict attributes are missing as well in the dict-proxy. Is this intentional? Thomas

2 3

test_asynchat.py broken on Windows
by Tim Peters 29 Oct '01

29 Oct '01

Here on Windows, current CVS: C:\Code\python\PCbuild>python ../lib/test/test_asynchat.py Traceback (most recent call last): File "../lib/test/test_asynchat.py", line 58, in ? main() File "../lib/test/test_asynchat.py", line 53, in main c = echo_client() File "../lib/test/test_asynchat.py", line 34, in __init__ self.connect((HOST, PORT)) File "C:\CODE\PYTHON\lib\asyncore.py", line 311, in connect raise socket.error, err socket.error: 2 The DOS box is frozen at this point, but not accumulating any cycles. Worked 12 hours ago. What about Linux?

1 0

Re: Python's SSL: Would you like to help?
by Ng Pheng Siong 29 Oct '01

29 Oct '01

On Mon, Oct 29, 2001 at 01:53:07PM +0100, Gerhard Häring wrote: > I've meanwhile started a discussion about the future of SSL support in > Python itself on the python-dev mailinglist. > > The talk is about several issues, like redesign a whole new API > (yes/no), integrate an existing module (which one?), support much crypto > at all. > > As you seem to have a lot of experience in this field, perhaps you'd > like to share some of your opinions there? [ Not subscribed, hopefully this gets thru. ] Hello, Thanks for asking. I've just read the discussion in the archives. My own archives contain a similar (but much shorter) discussion that took place on the old python-crypto@egroups list in Apr 2000. I've also just downloaded 2.2b1, POW (Python OpenSSL wrappers) 0.5, and pyOpenSSL 0.4 to have a quick look-see. (Haven't been keeping track of the competition. ;-) I noticed there are several SSL patches on SF, mostly from Gerhard. I didn't read the patches, though. Here are some random thoughts based on my experience with M2Crypto: - To do simple multi-threading, you need to bracket calls to SSL_read(), SSL_write(), etc. with Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS. You also (apparently) need to implement the locking required by OpenSSL; see M2Crypto's _thread.i. IIRC, OpenSSL's docu warns of Bad Things should one fail to do so. (None of the others seem to do this.) If you want to do callbacks for certificate verification, it's a little more complicated. First, you need to muck around with Python's thread states in OpenSSL's structures. M2Crypto and pyOpenSSL do these mostly the same way. POW doesn't do this. Next, consider the Python "SSL Context" object that mirrors SSL_CTX: In M2Crypto, the "SSL Context" is implemented in Python; conveniently, I use it to keep additional Python-level policy stuff. Thus, when OpenSSL calls back into M2Crypto, I need a means to get at the Python SSL Context object, before calling back into Python. Implementing the SSL Context object in C may make this simpler. (I see 2.2b1 does only SSL_VERIFY_NONE. Ditto POW and pyOpenSSL, it seems.) - Even if you only want to do certificates within SSL, you need to wrap quite a bit of the X.509 API. See M2Crypto's _x509.i and X509.py. POW seems to have done so, as well. If you also want to do X.509 independent of SSL (say for implementing a CA), you'll need to do more housekeeping, like whether to free a given structure at the Python side or the C side. Grep for "_pyfree" in M2Crypto's Python code. - Asynchronous SSL: I think M2Crypto has this mostly right, since ZServerSSL works (2nd birthday came and went it seems ;-), and I've recently implemented Medusa-based FTP-over-TLS which interoperates with other people's clients. Based on my light reading of the code, none of 2.2b1, POW and pyOpenSSL do async-SSL properly at all. - FakeSocket, SSLFakeSocket and SSLFakeFile are ugly! M2Crypto wraps OpenSSL's "stackable BIOs". makefile() on an SSL connection pushes a buffering BIO on top of the SSL BIO and returns that, which then behaves like a Python file-like object. Even does readline()! See M2Crypto's BIO.py. 2.2b1 has a BIO member in PySSLObject but doesn't seem to use it. Nor do POW and pyOpenSSL, it appears. Well, that's only the SSL-related stuff that came to my mind readily. The Python development team has to decide how much of the above you want within Python, e.g., how much of the BIO and X.509 APIs to wrap. Not to mention PRNGs, secure memory handling and crypto-in-general. (Lastly, I'm pleased to note that M2Crypto is still ahead of the competition. Gotta keep moving, though! ;-) Cheers. -- Ng Pheng Siong <ngps(a)post1.com> * http://www.post1.com/home/ngps

1 0

Re: patchlevel.h
by Jack Jansen 29 Oct '01

29 Oct '01

> > Maybe I should start using the release branch for Mac releases after you are > > done with it for the Unix/Windows release. As there is an r22b1 tag to point > > to the exact revision used for the release there should be no adverse > > consequences. What do you think? > > As before, I think there should be only a single 2.2b1 release. If you > need to provide binaries, use what was released in the 2.2b1 source > distribution (which is *not* the Unix release, it is the source > distribution). Martin, while I completely agree with you in principle, in practice this isn't possible. When the release branch is made there's usually a flurry of minor fixes, and these are almost guaranteed to break something on the mac. Tiny things, like missing casts, but breaks nonetheless. Moreover, the "release loop" is now about 24 hours long, according to PEP101, and even extending it seriously (like to about a week) still wouldn't guarantee that I could react timely. Not only am I 6 hours away from the unix/win release folks, but I also have a paying job that is less and less MacPython-related, so I can't firmly commit myself. And it has happened to me already (twice, I think) that there was a showstopper bug on the Mac that has caused me to either be very late with a release or skip one altogether. This happens on the Mac more often than on Unix/Windows, because MacPython relies on a third party unix I/O emulation library. -- 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

4 4

PEP 273 - inporting from zipfiles
by Jack Jansen 29 Oct '01

29 Oct '01

Jim, for your implementation you might want to have a look at the Macintosh-specific code in import.c (and possibly at related code in Mac/macglue.c, but that's probably less relevant). MacPython can already have files on sys.path, and there's code to look through these files for PYC resources. Don't worry what they are or how it's done, but they contain compiled modules. I got a pretty significant increase of import speed is when I added a cache of which sys.path entries were files and which were directories, so for each sys.path entry you know that you can skip one leg of the find_module() code. This is all in import.c, so you could probably enable it verbatim for zipfile imports. -- 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

Re: [Python-Dev] status of OS/2 ports of Python
by Michael Muller 29 Oct '01

29 Oct '01

Guido van Rossum wrote: > > I would also propose to look after patches to the VAC++ build (such as > > Michael Muller's), on the basis that although I can't test the patches > > directly, I can test that they don't affect the rest of the system, and I > > can work with the submitter to resolve issues that affect OS/2 specific > > functionality. > > That sounds like a very good idea. Right now I don't really know what > to do with the two sets of OS/2 patches... Since Michael is cc'ed > here, Michael, what do you think of this? This works for me. As I've said in the notes on my patches, there is some "textual" conflict between Andrews patches and mine (meaning that my patches won't work after his have been applied). However, I see no functional conflicts, and as I've said I'd be happy to create new patches that will work with his. Also, Andrew: I have a lot of experience with CVS and I'm willing to offer any help you need. I can also test changes on Linux. My only wish is that this be resolved quickly so I don't have to keep revising my patches to keep up with the (rapidly evolving) baseline ;-). ============================================================================= michaelMuller = mmuller(a)enduden.com | http://www.cloud9.net/~proteus ----------------------------------------------------------------------------- In this book it is spoken of the Sephiroth, and the Paths, of Spirits and Conjurations; of Gods, Spheres, Planes and many other things which may or may not exist. It is immaterial whether they exist or not. By doing certain things certain results follow. - Aleister Crowley =============================================================================

1 0

Re: [Python-Dev] Re: patchlevel.h
by Jack Jansen 29 Oct '01

29 Oct '01

> > While this may happen in principle, and out of curiosity: Was this a > > problem in 2.2b1 also? Looking at the changes made on the 2.2b1 > > release branch, I see that a total of 7 files was changed. Except for > > patchlevel.h, and the \n\ fix on socketmodule.c, there were no changes > > to C code. > > What's more common is actually a flurry of checkins just *before* the > release branch is made (say in the last two days). These often > include a somewhat hasty commit of a project that's valuable to have > but introduces new bugs -- either Mac-specific or generic. The patch > that introduced the missing \n\ problem was an example of this. And, more serious, there's another example for the 2.2b1 release that I found just friday (so this bug is going to stay in MacPython 2.2b1, I'm afraid): importing packages from frozen programs is broken. There was a moderately simple fix to import.c, to test that submodules of frozen modules were also frozen, and not picked up from the filesystem. Unfortunately whoever did the patch wasn't aware that MacPython frozen modules work different, and hence broke it. -- 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

(no subject)
by chima adams 29 Oct '01

29 Oct '01

FROM THE DESK:Dr.CHIMA ADAMS, ACCOUNT DEPARTMENT (NNPC) FALOMO OFFICE COMPLEX, IKOYI LAGOS, NIGERIA TEL:234-8033084103 FAX: 234-1-7599186 ATTN: GENERAL MANAGER Dear Sir, I am Dr.Chima Adams chairman- audit committee, with the Nigerian National Petroleum Corporation (NNPC), I headed the audit committee whose assignment was to audit, review and recommend payment for all contracts awarded in the NNPC by the corrupt past military administration. In the course of our review, we discovered that the sum of USD 30 million (THIRTY MILLION DOLLARS) was floating unclaimed in the corporation account without beneficiary. This money emanated from an over-invoicing in the contract awarded to a foreign firm for the supply, fixing, erecting and computerized optimization of oil pipeline to one of our oil refineries during the past Military administration. Base on our status as senior government officials in top sensitive position of trust, we cannot stand to claim this money ourselves, hence, I decided to contact you. All modalities for this transfer have been fully worked out. We have already secured a preliminary order to effect this payment, we now require from you your BANKING PARTICULARS, FAX AND TELEPHONE NUMBER for smooth transfer of this money into your bank account. We intend to share the money in the following manner: 30% for you, 65% for us and 5% for any miscellaneous expenses. This business is 100% risk-free. We look forward to a fruitful business relationship with you. Best Regards Dr. Chima Adams Account Department (NNPC) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Re: [Python-Dev] Re: patchlevel.h
by Jack Jansen 29 Oct '01

29 Oct '01

> > It's just that I think very strict principles must be applied for the > > final release. If that means that the 2.2 release can't go without ok > > from you (or somebody else who has produced MacOS 9 binaries), I think > > we should add that to the release procedure. That check would be to > > avoid show-stopper bugs only, of course - anything complex needs to be > > detected long before the final release. > > I think that for the final release we should definitely attempt this. > Hopefully the speed and quality of change will reduce closer to the > final release. Also, the release candidate should help. For the final release I agree that this is a good idea. Let's try and make it so. -- 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