Mailman 3 June 2001 - Python-Dev

IPv6 and Windows
by Martin v. Loewis June 25, 2001

June 25, 2001

> I haven't looked at the patches, but couldn't we have the IPv6 code > be #ifdef'ed out, so that those who care about IPv6 can periodically > test it while the various OS-level libraries are ramped up over the > next months/years, but w/o disturbing the 'current' builds? Not if we are going to introduce itojun's patch. In that patch, the IPv6 code *is* actually ifdef'ed out. It is getaddrinfo/getnameinfo that gives problems, which isn't IPv6 specific at all. The problem is that the library patches (httplib, ftplib, etc) do use getaddrinfo to find out how to contact a remote system, which is the right thing to do IMO. So even if the IPv6 support can be activated only if desired, getaddrinfo absolutely has to work. So the only question then is where we get an implementation of these functions if the system doesn't provide one. itojun has suggested the WIDE libraries; since they apparently don't compile on Windows, I've suggested the MS TP emulation. If the latter is not acceptable, we either have to fix the WIDE implementation to work on Windows also; As for the problems Mark reported: I think they can get fixed. Regards, Martin

5 6

Problems with socketmodule (getnameinfo & getaddrinfo)
by Martin v. Loewis June 25, 2001

June 25, 2001

> 1: socketmodule.c now #includes getnameinfo.c and > getaddrinfo.c. These functions both use offsetof(), which is defined > (on my system, at least) in stddef.h. That should be fixed now. stddef.h is included in socketmodule.c; if it is not available or does not define offsetof, an additional definition is provided. > 2. [...] Changes to either of the get{name,addr}info.c files will > not cause socketmodule to be rebuilt. I don't know how to solve this one. If distutils builds the modules, makefile dependencies won't help. > 3. The socket module still does not work, however, since it refers > to an unresolved symbol inet_pton I took the simplest solution that I could think of, delegating inet_{pton,ntop} to inet_{ntoa,addr} for AF_INET, failing for all other address families (AF_INET6 in particular). I've verified that this code does the same as the builtin functions on my Linux system; please let me know whether it compiles for you. Regards, Martin

2 3

Re: [Python-Dev] os.path.normcase() in site.py
by Jack Jansen June 25, 2001

June 25, 2001

> I noticed that these days __file__ attributes of modules are case normalized > (ie. lowercased on case insensitive file systems), or at least the directory > part. Then I noticed that this is caused by the fact that all sys.path entries > are case normalized. It turns out that site.py does this, in a function called > makepath(), added by Fred about 8 months ago. > > I think this is wrong: we should always try to *preserve* case. There is an added problem with the makepath() stuff that I hadn't reported here yet: it has broken MacPython on some non-western machines. Specifically I've had reports of people running a Japanese MacOS that things will break if they run Python from a pathname that has any non-7-bit-ascii characters in the name. Apparently normcase normalizes more than just ascii upper/lowercase letters. And aside from that I fully agree with Just: seeing a stacktrace with all lowercase filenames is _very_ disconcerting. I would disable the case-normalization for MacPython, except that I don't know whether it actually has a function. With MacPython's way of finding the initial sys.path contents we don't have the Windows-Python problem that we add the same directory 5 times (once in uppercase, once in lowercase, once in mixed case, once in mixed-case with / for \, etc:-), so if this is what it's trying to solve we can take it out easily. -- 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

5 6

2.1.1 vs. os.normcase()
by aahz＠rahul.net June 25, 2001

June 25, 2001

It's too late for 2.0.1, but should this bugfix go into 2.1.1? (Just to be clear, this is the problem that Just reported with site.py calling os.normcase() in makepath().) ((I'm only asking about this bug in specific because we're getting down to the wire on 2.1.1 IIUC.)) -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista I don't really mind a person having the last whine, but I do mind someone else having the last self-righteous whine.

2 1

RE: Python-Dev digest, Vol 1 #1437 - 13 msgs
by Greg Wilson June 25, 2001

June 25, 2001

> Guido: > Since you have already obtained the same speedup with your approach, I > think there's great promise. Count on sending in a paper for the next > Python conference! Greg: "Doctor Dobb's Journal" would also be interested in an article. Who knows --- it might even be done before the ones on stackless, garbage collection, Zope acquisition, and generators... :-) 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

xrange vs generators
by Skip Montanaro June 25, 2001

June 25, 2001

With generators in the language, should xrange be deprecated? Skip

6 9

Re: [Python-Dev] Python Specializing Compiler
by Samuele Pedroni June 25, 2001

June 25, 2001

Hi. [Armin Rigo] > In particular, I believe we won't need to change the way the current Python > interpreted encodes data. For example, instances currently have a > dictionary of attributes and no "fixed slots", but this is not a problem > for Psyco, which can encode instances in better ways (e.g. as a C struct) > as long as it is only accessed by Psyco-compiled Python code and no > "legacy" code. This makes sense, but I'm asking if it is affordable to have all code executed (if we aim for usage-transparency) through Psyco-compiled code (memory foot-print, compilation vs. execution trade-offs for rarely executed code) Otherwise in a mixed execution context we would pay for conversions. I can see how a dynamic compiler can deal with methods together with the interpreter that notifies when a dynamic change to hierarchy, method defs can potetianlly invalidate compiled code. I see more problems with instance data slots, because there are no strong hints in the code about which are the "official" slots of a class, and undisciplined code can treat instances just as dicts. regards, Samuele Pedroni.

1 0

os.path.normcase() in site.py
by Just van Rossum June 25, 2001

June 25, 2001

I noticed that these days __file__ attributes of modules are case normalized (ie. lowercased on case insensitive file systems), or at least the directory part. Then I noticed that this is caused by the fact that all sys.path entries are case normalized. It turns out that site.py does this, in a function called makepath(), added by Fred about 8 months ago. I think this is wrong: we should always try to *preserve* case. I see os.path.normcase() as a tool to be able to better compare two paths, but you shouldn't *store* paths this way. I for one am irritated when I see a path that doesn't have the proper case. The intention of makepath() in site.py seems good -- it turns all paths into absolute paths -- but is the normcase really neccesary? *** Please CC follow-ups to me, as I'm not on python-dev. Just

5 5

Re: [Python-Dev] Python Specializing Compiler
by Samuele Pedroni June 25, 2001

June 25, 2001

Hi. Just after reading the README, it's very intriguing and interesting, (if I remember well this resemble the customization approach of the Self VM compiler) ideally it could evolve in a loadable extension, that then works together with the normal interp (unchanged up to offering some hooks*) in a trasparent way for the user ... emitting native code for the major platforms or just specialized bytecodes. I will give a serious look at it. regards, Samuele Pedroni. *: some possible useful hooks would be: - minimal profiling support in order to specialize only things called often - feedback for dynamic changing of methods, class hierarchy, ... if we want to optimize method lookup (which would make sense) - a mixed fixed slots/dict layout for instances.

2 2

IPv6 and Windows
by Martin v. Loewis June 25, 2001

June 25, 2001

After integrating the first chunk of IPv6 changes, Tim Peters quickly found that they won't compile on Windows - even though this was the least-critical part of the patch. Specifically, this code emulates the getaddrinfo and getnameinfo calls, which will be exposed to Python programs in a later patch. Therefore, it is essential that they are available on every system, either directly or through emulation. For Windows, one option is to use the Microsoft-provided emulation, which is available from http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp To use this emulation, only the header files of the package are required; it is not necessary to actually install the IPv6 preview on the system. The MS emulation will try to load a few DLLs which are known to provide getaddrinfo. If neither DLL is found, the code in the header file falls back to an emulation. That way, the resulting socket.pyd would use the true API function on installations that provide them, and the emulation on all other systems. The only requirement for building Python is then that the header file from the technology preview is available on the build machine (tpipv6.h). It may be that the header file is also included in recent SDK releases, I haven't checked. Is such a requirement acceptable for building the socket module on Windows? Regards, Martin

5 7