[Python-Dev] Mac questions
I'm working on refactoring Python/import.c, currently the case_ok() function. I was wondering about these lines: /* new-fangled macintosh (macosx) */ #elif defined(__MACH__) defined(__APPLE__) defined(HAVE_DIRENT_H) Is this for Mac OSX? Does the Mac have a case insensitive file system (my experiments on the SF compile farm say no)? And finally: Is there any other way to find the true spelling of a file except than a linear search with opendir()/readdir()/closedir() ? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 246, redux
Alex Martelli [EMAIL PROTECTED] writes: PEP: 246 Title: Object Adaptation Minor nit (or not?): You could provide a pointer to the Liskov substitution principle, for those reader that aren't too familiar with that term. Besides, the text mentions three times that LiskovViolation is a subclass of AdaptionError (plus once in the ref impl section). Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
getattr and __mro__ (was Re: [Python-Dev] PEP 246, redux)
Armin Rigo [EMAIL PROTECTED] writes: ... is that the __adapt__() and __conform__() methods should work just like all other special methods for new-style classes. The confusion comes from the fact that the reference implementation doesn't do that. It should be fixed by replacing: conform = getattr(type(obj), '__conform__', None) with: for basecls in type(obj).__mro__: if '__conform__' in basecls.__dict__: conform = basecls.__dict__['__conform__'] break else: # not found and the same for '__adapt__'. The point about tp_xxx slots is that when implemented in C with slots, you get the latter (correct) effect for free. This is how metaconfusion is avoided in post-2.2 Python. Using getattr() for that is essentially broken. Trying to call the method and catching TypeErrors seems pretty fragile -- e.g. if you are calling a __conform__() which is implemented in C you won't get a Python frame in the traceback either. I'm confused. Do you mean that getattr(obj, somemethod)(...) does something different than obj.somemethod(...) with new style class instances? Doesn't getattr search the __dict__'s along the __mro__ list? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: 2.3.5 delayed til next week
Anthony Baxter [EMAIL PROTECTED] writes: As I'd kinda feared, my return to work has left me completely buried this week, and so I'm going to have to push 2.3.5 until next week. Thomas and Fred: does one of the days in the range 25-27 January suit you? The 26th is a public holiday here, and so that's the day that's most likely for me... 25-27 January are all ok for me. Will there be a lot of backports, or are they already in place? If they are already there, I can build the installer as soon as Fred has built the html docs. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is msvcr71.dll re-redistributable?
The 2.4 python.org installer installs msvcr71.dll on the target system. If someone uses py2exe or a similar tool to create a frozen application, is he allowed to redistribute this msvcr71.dll to other users together with his application or not, even if he doesn't own MSVC? This was asked on the py2exe users list, but I could not answer this question. Googling for msvcr71.dll finds some site which offer to download it, and they pretend that they are not violating any license, but I wasn't able to find definite words from MS about that. Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is msvcr71.dll re-redistributable?
Neil Hodgson [EMAIL PROTECTED] writes: Anders J. Munch: 1. John X. Programmer buys the product, agrees to the EULA and puts the DLL up for download, with the explicit and stated intent of distributing it to anyone who needs it. Disallowed in 3.1(a): # you agree: ... to distribute the Redistributables only ... in # conjunction with and as a part of a software application # product developed by you that adds significant and primary # functionality to the Redistributables All this pretty much subsumes what I was thinking. The only question that remains is: why are there some sites like http://www.dll-files.com/ which offer this and other MS dlls for download? For the spambayes binary, maybe there should be another person adding the msvcr71.dll to the distribution that Tony builds? Someone who has a MSVC license, and also is developer on the spambayes project? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ViewCVS on SourceForge is broken
Tim Peters [EMAIL PROTECTED] writes: [Trent Mick] Has anyone else noticed that viewcvs is broken on SF? It failed the same way from Virginia just now. I suppose that's your reward for kindly updating the Python copyright wink. The failure lasts already for several days: http://sourceforge.net/docman/display_doc.php?docid=2352group_id=1#1107968334 Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Python 2.4, distutils, and pure python packages
The following message is a courtesy copy of an article that has been posted to comp.lang.python as well. [CC to python-dev] Fuzzyman [EMAIL PROTECTED] writes: Python 2.4 is built with Microsoft Visiual C++ 7. This means that it uses msvcr7.dll, which *isn't* a standard part of the windows operating system. Nitpicking - it's MSVC 7.1, aka MS Visual Studio .NET 2003, and it's msvcr71.dll. This means that if you build a windows installer using distutils - it *requires* msvcr7.dll in order to run. This is true even if your package is a pure python package. This means that when someone tries to use a windows installer created with Python 2.4, on a machine with only python 2.3 - it will fail. Bummer. It's likely that nothing can be done about this (although for a pure python package there's no reason not to use the 'source distribution' and the setup.py). It does mean that I have to build my windows installer on a machine with python 2.3. There's a workaround, although ugly. bdist_wininst has a --target-version flag which allows to build an installer for another Python version. It works both for pure Python packages, and for (how are they called? non-pure?) packages containing compiled extensions. The 2.4 distutils package has all that is needed to create a installer running with python 2.3 or maybe even 2.2 (which uses msvcrt.dll instead of msvcr71.dll). The result, of course, is that the installer can only install for the version that you specified at build time. Because distutils cannot cross-compile extensions for other versions, you must have build extensions (if there are any to include) with the other Python version before - distutils will simply pick up the extensions it finds in build subdirectories for the other version. Anyway, whether you have extensions or not, you must also specify the --skip-build command line flag, distutils will complain if you don't. So, for a pure distribution you would typically run these commands to build separate installers for 2.3 and 2.4: \python24\python setup.py --skip-build --target-version 2.3 bdist_wininst \python24\python setup.py --skip-build --target-version 2.4 bdist_wininst and for non-pure packages you must compile with each version before building the installer (if you want for some reason to use python 2.4 to build the installer for 2.3): \python24\python setup.py build_ext \python23\python setup.py build_ext \python24\python setup.py --skip-build --target-version 2.3 bdist_wininst \python24\python setup.py --skip-build --target-version 2.4 bdist_wininst OTOH, it's no problem to install both python 2.3 and python 2.4 in separate directories on the same machine and always make native builds. -- To make this story even more complete, there have been also other bugs caused by the different runtime dlls used in 2.3 and 2.4, most only showing when you use the --install-script option. The installer was using msvcrt.dll and msvcr71.dll at the same time, which led to crashes when the install script was started - the PythonCard installer suffered from that, at least. The bug only occurred with pure python distributions, because then the dll problem occurred. The bug is solved in Python 2.3.5, and also in the 2.4.1 release which will be out soon, with one exception: if the install-script prints something the output will be lost instead of displayed on the last screen. At least that's better than crashing the process. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (no subject)
Phillip J. Eby [EMAIL PROTECTED] writes: At 05:34 AM 3/14/05 -0800, Michael Chermside wrote: Nice... thanks. But I have to ask: is this really the right set of metadata to be updating? Here are a few things that perhaps ought be copied by update_meta: f.__name__ (already included) f.__doc__ (already included) f.__dict__ (already included) f.__module__ (probably should include) f.func_code.co_filename (to match f.__name__, but I'd leave it alone) Leave __module__ alone, too, unless you want to play havoc with any inspection tools looking for the source code. there's also the annoying fact that in IDLE (and in some other python-aware IDEs) one can see the argument signature for a function as a tool tip or other hint. Very handy that, but if a decorator is applied then all you will see is func(*args, **kwargs) which is less than helpful. I'm not sure whether this CAN be duplicated... I believe it is generated by examining the following: f.func_code.co_argcount f.func_code.co_varnames f.func_code.co_flags 0x4 f.func_code.co_flags 0x8 ...and I suspect (experimentation seems to confirm this) that if you mangle these then the code object won't work correctly. If anyone's got a suggestion for fixing this, I'd love to hear it. One solution is to have a __signature__ attribute that's purely documentary. That is, modifying it wouldn't change the function's actual behavior, so it could be copied with update_meta() but then modified by the decorator if need be. __signature__ would basically be a structure like the one returned by inspect.getargspec(). Also, 'instancemethod' would have a __signature__ equal to its im_func.__signature__ with the first argument dropped off, thus making it easy to introspect wrapper chains. Another possibility (ugly, maybe) would be to create sourcecode with the function signature that you need, and compile it. inspect.getargspec() and inspect.formatargspec can do most of the work. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Error checking in initmodule functions
I always wondered why there usually is very sloppy error checking in
initmodule functions. Usually it goes like this (I removed
declarations and some other lines for clarity):
PyMODINIT_FUNC
PyInit_zlib(void)
{
m = Py_InitModule4(zlib, zlib_methods,
zlib_module_documentation,
(PyObject*)NULL,PYTHON_API_VERSION);
ZlibError = PyErr_NewException(zlib.error, NULL, NULL);
if (ZlibError != NULL) {
Py_INCREF(ZlibError);
PyModule_AddObject(m, error, ZlibError);
}
PyModule_AddIntConstant(m, MAX_WBITS, MAX_WBITS);
PyModule_AddIntConstant(m, DEFLATED, DEFLATED);
ver = PyString_FromString(ZLIB_VERSION);
if (ver != NULL)
PyModule_AddObject(m, ZLIB_VERSION, ver);
PyModule_AddStringConstant(m, __version__, 1.0);
}
Why isn't the result checked in the PyModule_... functions?
Why is the failure of PyErr_NewException silently ignored?
The problem is that when one of these things fail (although they are
probably supposed to NOT fail) you end up with a module missing
something, without any error message.
What would be the correct thing to do - I assume something like
if (PyModule_AddIntConstant(m, MAX_WBITS, MAX_WBITS)) {
PyErr_Print();
return;
}
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Five patch reviews patch request
Michiel De Hoon [EMAIL PROTECTED] writes: I'd like to ask your attention to this patch: [ 1049855 ] PyOS_InputHook inconsistency on Windows Kurt Kaiser has already looked at this patch, but was hesitant to check it in because he wasn't able to test it on Windows. I'd be happy to send a compiled Python for Windows to anybody willing to have a look at this patch. Comment about the patch (only from reading it): The PyOS_StdioReadline function calls my_fgets with a file pointer argument. The my_fgets function in the patch assumes that STD_INPUT_HANDLE is the handle to use - is this assumption always correct? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers
Nick Coghlan [EMAIL PROTECTED] writes: Gareth McCaughan wrote: [Keith Dart:] By normal integer I mean the mathematical definition. Then you aren't (to me) making sense. You were distinguishing this from a unified int/long. So far as I can see, a unified int/long type *does* implement (modulo implementation limits and bugs) the mathematical definition. What am I missing? Hmm, a 'mod_int' type might be an interesting concept (i.e. a type that performs integer arithmetic, only each operation is carried out modulo some integer). Then particular bit sizes would be simple ints, modulo the appropriate power of two. ctypes provides mutable platform integers and floats of various sizes (and much more). Currently they don't have any methods, only the value attribute. Maybe it would be useful to implement the standard numeric methods on them. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Guido van Rossum: Whoa! Do we really need a completely different mechanism for doing the same stuff we can already do? Neil Hodgson [EMAIL PROTECTED] writes: One benefit I see for the path module is that it makes it easier to write code that behaves correctly with unicode paths on Windows. Currently, to implement code that may see unicode paths, you must first understand that unicode paths may be an issue, then write conditional code that uses either a string or unicode string to hold paths whenever a new path is created. Indeed. This would probably handle the cases where you have to manipulate file paths in code. OTOH, Python is lacking a lot when you have to handle unicode strings on sys.path, in command line arguments, environment variables and maybe other places. See, for example http://mail.python.org/pipermail/python-list/2004-December/256969.html I had started to work on the sys.path unicode issues, but it seems a considerable rewrite of (not only) Python/import.c is required. But I fear the patch http://python.org/sf/1093253 is slowly getting out of date. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Neil Hodgson [EMAIL PROTECTED] writes: Thomas Heller: OTOH, Python is lacking a lot when you have to handle unicode strings on sys.path, in command line arguments, environment variables and maybe other places. A new patch #1231336 Add unicode for sys.argv, os.environ, os.system is now in SourceForge. New parallel features sys.argvu and os.environu are provided and os.system accepts unicode arguments similar to PEP 277. A screenshot showing why the existing features are inadequate and the new features an enhancement are at http://www.scintilla.org/pyunicode.png One problem is that when using python -c cmd args, sys.argvu includes the cmd but sys.argv does not. They both contain the -c. Not only that, all the other flags like -O and -E are also in sys.argvu but not in sys.argv. os.system was changed to make it easier to add some test cases but then that looked like too much trouble. There are far too many variants on exec*, spawn* and popen* to write a quick patch for these. Those are nearly obsoleted by the subprocess module (although I do not know how that handles unicode. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Neil Hodgson [EMAIL PROTECTED] writes: Guido van Rossum: Ah, sigh. I didn't know that os.listdir() behaves differently when the argument is Unicode. Does os.listdir(.) really behave differently than os.listdir(u.)? Yes: os.listdir(.) ['abc', ''] os.listdir(u.) [u'abc', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435'] Bah! I don't think that's a very good design (although I see where it comes from). Partly my fault. At the time I was more concerned with making functionality possible rather than convenient. Promoting only those entries that need it seems the right solution -- user code that can't deal with the Unicode entries shouldn't be used around directories containing unicode -- if it needs to work around unicode it should be fixed to support that! I'm sorry but that's not my opinion. Code that can't deal with unicode entries is broken, imo. The programmer does not know where the user runs this code at what he throws at it. I think that this will hide bugs. When I installed the first game written in Python with pygame on my daughter's PC it didn't run, simply because there was a font listed in the registry which contained umlauts somewhere. OTOH, I once had a bug report from a py2exe user who complained that the program didn't start when installed in a path with japanese characters on it. I tried this out, the bug existed (and still exists), but I was astonished how many programs behaved the same: On a PC with english language settings, you cannot start WinZip or Acrobat Reader (to give just some examples) on a .zip or .pdf file contained in such a directory. OK, I'll work on a patch for that but I'd like to see the opinions of the usual unicode guys as this will produce more opportunities for UnicodeDecodeError. The modification will probably work in the opposite way, asking for all the names in unicode and then attempting to convert to the default code page with failures retaining the unicode name. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception Reorg PEP revised yet again
Brett Cannon [EMAIL PROTECTED] writes: On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote: Then I don't follow what you mean by moved under os. In other words, to get the exception, do ``from os import WindowsError``. Unfortunately we don't have a generic win module to put it under. Maybe in the platform module instead? -1 on either. The WindowsError exception needs to in the main exception tree. It occurs in too many different modules and applications. That is a good reason for being in the main tree. Where is it used so much? In the stdlib, grepping for WindowsError recursively in Lib in 2.4 turns up only one module raising it (subprocess) and only two modules with a total of three places of catching it (ntpath once, urllib twice). In Module, there are no hits. I don't know how you've been grepping, but the Python api functions to raise WindowsErrors are named like PyErr_SetFromWindowsErr() or so. Typically, WindowsErrors are raised when Win32 API functions fail. In the core extension modules, I find at least mmapmodule.c, posixmodule.c, _subprocess.c, and _winreg.c raising them. It may be a bit hidden, because the docs for _winreg mention only EnvironmentError, but they are wrong: C:\py Python 2.5a0 (#60, Jul 4 2005, 19:53:27) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import _winreg _winreg.OpenKey(_winreg.HKEY_CLASSES_ROOT, blah) Traceback (most recent call last): File stdin, line 1, in ? WindowsError: [Errno 2] Das System kann die angegebene Datei nicht finden If the name bugs you, I would support renaming it to PlatformError or somesuch. That would make it free for use with Mac errors and Linux errors. Also, it wouldn't tie a language feature to the name of an MS product. I can compromise to this if others prefer this alternative. Anybody else have an opinion? Win32 has the FormatError() api to convert error codes into descriptions - these descriptions are very useful, as are the error codes when you catch errors in client code. I would say as long as the Python core contains win32 specific modules like _winreg WindowsError should stay. For the name, I have no preference but I see no need to change it. Thomas PS: For ctypes, it doesn't matter if WindowsError stays or not. No problem to invent my own WindowsError if it goes away. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
Neil Schemenauer [EMAIL PROTECTED] writes: [Please mail followups to [EMAIL PROTECTED] The PEP has been rewritten based on a suggestion by Guido to change str() rather than adding a new built-in function. Based on my testing, I believe the idea is feasible. It would be helpful if people could test the patched Python with their own applications and report any incompatibilities. I like the fact that currently unicode(x) is guarateed to return a unicode instance, or raises a UnicodeDecodeError. Same for str(x), which is guaranteed to return a (byte) string instance or raise an error. Wouldn't also a new function make the intent clearer? So I think I'm +1 on the text() built-in, and -0 on changing str. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
Michael Hudson [EMAIL PROTECTED] writes: Raymond Hettinger [EMAIL PROTECTED] writes: [Raymond Hettinger] This patch should be reverted or fixed so that the Py2.5 build works again. It contains a disasterous search and replace error that prevents it from compiling. Hence, it couldn't have passed the test suite before being checked in. [Michael Hudson] It works for me, on OS X. Passes the test suite, even. I presume you're on Windows of some kind? Here's an excerpt from the check-in note for sha512module.c: RND(S[0],S[1],S[2],S[3],S[4],S[5],S[6],S[7],0,0x428a2f98d728ae22ULL); RND(S[7],S[0],S[1],S[2],S[3],S[4],S[5],S[6],1,0x7137449123ef65cdULL); RND(S[6],S[7],S[0],S[1],S[2],S[3],S[4],S[5],2,0xb5c0fbcfec4d3b2fULL); RND(S[5],S[6],S[7],S[0],S[1],S[2],S[3],S[4],3,0xe9b5dba58189dbbcULL); RND(S[4],S[5],S[6],S[7],S[0],S[1],S[2],S[3],4,0x3956c25bf348b538ULL); Perhaps OS X has some sort of Steve Jobs special constant suffix ULL that Mr. Gates and the ANSI C folks have yet to accept ;-) It's an C99 unsigned long long literal, AFAICT (p70 of the PDF I found lying around somewhere...), so I think it's just Bill who's behind. However, Python doesn't require C99, so it's pretty dodgy code by our standards. Hmm. You have PY_LONG_LONG #define-d, right? Does VC++ 6 (that's what you use, right?) support any kind of long long literal? The suffix seems to be 'ui64'. From vc6 limits.h: #if _INTEGRAL_MAX_BITS = 64 /* minimum signed 64 bit value */ #define _I64_MIN(-9223372036854775807i64 - 1) /* maximum signed 64 bit value */ #define _I64_MAX 9223372036854775807i64 /* maximum unsigned 64 bit value */ #define _UI64_MAX 0xui64 #endif Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Fredrik Lundh [EMAIL PROTECTED] writes: Greg Ewing wrote: Maybe backquotes could be repurposed in Py3k for interpolated string literals? backquotes are a PITA to type on many non-US keyboards. Even more since they are especially broken in Windows XEmacs. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
Bob Ippolito [EMAIL PROTECTED] writes: Personally my biggest issue with the way the CPython VM works is that you can't reliably do multiple interpreters in a single process. If that worked well, you could start an independent interpreter per thread and with a per-interpreter GIL you'd have pretty much everything you needed... but this would horribly break the C API and may be a performance hit. My use case for this isn't so much about threads, but plug-ins. Writing multiple Python-based plug-ins for an application is always a mess, because they share too much (sys.modules, sys.path, etc.). PyObjC would benefit greatly from this feature, because you can write Python-based plug-ins for any Cocoa app that supports plug-ins, even if they're otherwise unaware of Python's existence. There are workarounds, of course, with import hooks and similar hacks. I think that mod_python would also benefit from this, and probably other such systems. Just a note in case you didn't know this already, probably off-topic for python-dev, but not meant as advertisement for py2exe): the same (plug-in) problem occurs with an inprocess COM server and a Python client program, or more than one inproc COM server in any client program. The 0.6 py2exe release with it's bundle-file option allows to build COM dlls (and client EXE programs, if needed) that APPEAR to have a statically linked copy of Python##.dll, and so have several CPython VMs running in the same process. In case anybody want's to take a look or experiment with it. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] linecache problem
Oleg Broytmann [EMAIL PROTECTED] writes: On Fri, Sep 30, 2005 at 09:17:39AM +0200, Thomas Heller wrote: On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. [skip] The bug is present in 2.3, 2.4, and current CVS. I have seen such tracebacks in all versions of Python AFAIR. I think it's a severe bug that needs to be fixed. Tracebacks showing the wrong sourcelines leave the impression 'the Python installation is totally broken'. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] linecache problem
Guido van Rossum [EMAIL PROTECTED] writes: On 9/30/05, Thomas Heller [EMAIL PROTECTED] wrote: On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. Finally I traced it down to a problem in the linecache code, which tries to be smart in up updatecache function. When os.stat() on the filename fails with os.error, it walks along sys.path and returns the first file with a matching basename. This *may* make sense for toplevel modules, but never for modules in packages. The bug is present in 2.3, 2.4, and current CVS. Probably my fault (I wrote linecache, 13 years ago (before Python had packages!). But looking at the code I don't understand why this is; there's no code to descend into subdirectories of directories found on sys.path. I wonder if the problem isn't on PIL's end, which puts the PIL directory on sys.path? It seems PIL cannot decide if it wants to be a package or not, but better would be to ask the author. /F, ? It installs a PIL.pth file in lib/site-packages, which contains 'PIL' only - that's where the sys.path entry comes from. OTOH, the lib/site-packages/PIL directory contains an __init__.py file. PIL.pth is the only .pth file that I have where the directory contains an __init__.py file. Anyway, don't hesitate to suggest a patch on sourceforge -- python-dev really isn't the forum for further discussion of this issue. https://sourceforge.net/tracker/index.php?func=detailaid=1309567group_id=5470atid=105470 Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conversion to Subversion is complete
[EMAIL PROTECTED] writes: The Python source code repository is now converted to subversion; please feel free to start checking out new sandboxes. For a few days, this installation probably still needs to be considered in testing. If there are no serious problems found by next Monday, I would consider conversion of the data complete. The CVS repository will be kept available read-only for a while longer, so you can easily forward any patches you may have. Most of you are probably interested in checking out one of these folders: svn+ssh://[EMAIL PROTECTED]/python/trunk svn+ssh://[EMAIL PROTECTED]/python/branches/release24-maint svn+ssh://[EMAIL PROTECTED]/peps Works out of the box for me, thanks, Martin (but we have debugged this before). Can anyone recommend an XEmacs svn plugin to use - I've tried psvn.el from http://www.xsteve.at/prg/emacs/psvn.el which seems to work? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PYTHOPN_API_VERSION
Shouldn't PYTHON_API_VERSION be different between 2.3 and 2.4? It is 1012 in both versions. I tried to detect whether PyTuple_Pack is supported, which was added in 2.4. Or is this only to detect changed apis, and not added apis? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Plea to distribute debugging lib
Guido van Rossum [EMAIL PROTECTED] writes: I vaguely recall that there were problems with distributing the debug version of the MS runtime. Right: the debug runtime dlls are not disributable. Anyway, why can't you do this yourself for all Boost users? It's all volunteer time, you know... Doesn't any boost user need a C compiler anyway, so it should not really be a problem to compile Python? Anyway, AFAIK, the activestate distribution contains Python debug dlls. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
Bob Ippolito [EMAIL PROTECTED] writes: On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote: It's a shame that 1) there's no equivalent of java -jar, i.e., python -z FILE.ZIP, and This should work on a few platforms: env PYTHONPATH=FILE.zip python -m some_module_in_the_zip It should, yes - but it doesn't: -m doesn't work with zipimport. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build failure and problem on Windows
Thomas Heller [EMAIL PROTECTED] writes: Building the svn trunk on Windows fails because Python\pyarena.c is missing in the pythoncore.vcproj file (I'm not yet up to speed with svn, otherwise I would have checked in a fix for this myself). Worse, when running the built exe it segfaults in Py_GetBuildInfo(), because it is picking up somehow a definition of #define BUILD 'b' (from cPickle.c? Could that be?) I should have known better, but BUILD is defined in the MSVC project file as BUILD=60. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Build failure and problem on Windows
Building the svn trunk on Windows fails because Python\pyarena.c is missing in the pythoncore.vcproj file (I'm not yet up to speed with svn, otherwise I would have checked in a fix for this myself). Worse, when running the built exe it segfaults in Py_GetBuildInfo(), because it is picking up somehow a definition of #define BUILD 'b' (from cPickle.c? Could that be?) Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] os.startfile with optional second parameter
Would a patch be accepted that implemented an optional second parameter for the os.startfile function on Windows? Sometimes I missed the possibility to write os.startfile(mydocs.pdf, print) Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.startfile with optional second parameter
Thomas Heller [EMAIL PROTECTED] writes: Would a patch be accepted that implemented an optional second parameter for the os.startfile function on Windows? Sometimes I missed the possibility to write os.startfile(mydocs.pdf, print) The other possibility would be to extend the subprocess module with this functionality. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build failure and problem on Windows
Thomas Heller [EMAIL PROTECTED] writes: Thomas Heller [EMAIL PROTECTED] writes: Building the svn trunk on Windows fails because Python\pyarena.c is missing in the pythoncore.vcproj file (I'm not yet up to speed with svn, otherwise I would have checked in a fix for this myself). Worse, when running the built exe it segfaults in Py_GetBuildInfo(), because it is picking up somehow a definition of #define BUILD 'b' (from cPickle.c? Could that be?) I should have known better, but BUILD is defined in the MSVC project file as BUILD=60. I've committed a fix for both (Hope these comments aren't off-topic nowadays for python-dev). Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] API changes
The ast-branch merge apparently changed some formerly public functions to macros. The two that I found out about are PyRun_SimpleString and PyRun_InteractiveLoop, I have not checked if there are more or not. This breaks apps which dynamically link at runtime to the Python dll (the latest py2exe does this). Was this change intentional, or can it be reverted? Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API changes
Jeremy Hylton [EMAIL PROTECTED] writes: On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote: The ast-branch merge apparently changed some formerly public functions to macros. The two that I found out about are PyRun_SimpleString and PyRun_InteractiveLoop, I have not checked if there are more or not. This breaks apps which dynamically link at runtime to the Python dll (the latest py2exe does this). Was this change intentional, or can it be reverted? Thanks, Thomas The intent was to provide binary compatibility, but redirect all newly linked code to the newer variants. We did this correctly for PyParser_SimpleParseFile and PyParser_SimpleParseString, but didn't do it for the rest of the changed functions. Can you file a bug report? (Or just fix the ones that bother you.) We ought to update the docs, too. I'm not sure I understand the 'we did this correctly for ...'. PyParser_SimpleParseFile is a function in 2.4, and a macro in 2.5. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API changes
Jeremy Hylton [EMAIL PROTECTED] writes: On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote: Jeremy Hylton [EMAIL PROTECTED] writes: On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote: The ast-branch merge apparently changed some formerly public functions to macros. The two that I found out about are PyRun_SimpleString and PyRun_InteractiveLoop, I have not checked if there are more or not. This breaks apps which dynamically link at runtime to the Python dll (the latest py2exe does this). The intent was to provide binary compatibility, but redirect all newly linked code to the newer variants. We did this correctly for PyParser_SimpleParseFile and PyParser_SimpleParseString, but didn't do it for the rest of the changed functions. Can you file a bug report? (Or just fix the ones that bother you.) I'm not sure I understand the 'we did this correctly for ...'. PyParser_SimpleParseFile is a function in 2.4, and a macro in 2.5. There's a function by the same name at the end of pythonrun.c. Nothing in the Python core should link to it, but it's still available for third-party code. Now we can mark PyParser_SimpleParseFile as deprecated remove it in some future release. I see. I doesn't help on Windows, though, since the functions are not declared DL_EXPORT(). All in all, I'm unsure if it is worth fixing this - maybe it would be better to change py2exe. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
[EMAIL PROTECTED] writes: I delayed upgrading from 10.2 for awhile and was given the same advice. I was further told (check the mac sig archives) that you'd be able to stick with 10.3 for much longer because new apps wouldn't need to require 10.4. So I upgraded. Now you're telling me that it's somehow obsolete and that I should upgrade because we can't be bothered to fix a compiler warning? Python supports much older versions of other platforms. What makes Mac OSX so special in this regard? There are 10.1 and 10.2 boxes in the sourceforge compile farm which could probably used for testing. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Include ctypes into core Python?
I would like to suggest to include ctypes into core Python, starting with the 2.5 release. ctypes is nearing the 1.0 release, and works on Windows, OS X, linux, possibly other platforms (provided that the processor is supported by libffi), and just recently even on Windows CE. ctypes does not depend on a libfii library installed on the system, instead the libfii source code is compiled into the extension module. libffi is copyright Red Hat, Inc, and released under a MIT style license. Up-to date docs for ctypes still have to be written, but I assume that the 2.5 release timeframe leaves enough time for that. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Guido van Rossum [EMAIL PROTECTED] writes: On 1/10/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: Guido van Rossum wrote: On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote: I would like to suggest to include ctypes into core Python, starting with the 2.5 release. On the one hand I agree that this is a useful module, popular, mature etc. On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). I don't expect this to count against including ctypes; but I do want it to be dealt with somehow! As was pointed out on c.l.py, the `dl` module suffers the exact same problem (I don't know myself, as I've never used it). There are no warnings about this in the `dl` module documentation. Good point. I think there should be such warnings though. I can't see how it would be possible to guarantee that such a module could not cause crashes. And I'm not asking for that. I'm of the opinion that having a big red warning at the top of the module documentation that this is a contributed module, and incorrect use could cause segmentation faults/crashes, etc would be sufficient. Works for me. Another possibility would be to emit a warning when the module (dl or ctypes, if included) is imported. warnings.warn(Incorrect usage of this module may crash Python, RuntimeWarning, stacklevel=2) Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Delaney, Timothy (Tim) [EMAIL PROTECTED] writes: Martin v. Löwis wrote: So as for dealing with it somehow: I would make ctypes a dynamically loaded module (ctypes.pyd), so administrators could remove it, and I could also make it a separate option in the Windows installer, so administrators could reject to install it. I like this solution. Of course, Thomas (author of both py2exe and ctypes) may like the ability to have ctypes built into python.dll ... It is getting offtopic, but I don't care too much about that. I requested that zlib be changed to a builtin module too allow easier bootstrapping of py2exe'd apps which have a compressed library archive. The nearly only reason for me to implement the single-file option for py2exe was that the implementation simulates a static linked Python-dll, which allows for several totally-isolated interpreters in the same process. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Martin v. Löwis [EMAIL PROTECTED] writes: Guido van Rossum wrote: On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). I don't expect this to count against including ctypes; but I do want it to be dealt with somehow! I think the strongest point *for* ctypes is the inclusion of dl in the source distribution, which has the very same flaws as ctypes in terms of crashability. So as for dealing with it somehow: I would make ctypes a dynamically loaded module (ctypes.pyd), so administrators could remove it, and I could also make it a separate option in the Windows installer, so administrators could reject to install it. Sounds good, although it should be noted that ctypes is a package now, with a ctypes.wrap subpackage (contains the code generator), a ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X), and ctypes.test subpackage whcih contains several test modules. Plus the _ctypes.(dll|so) extension module. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Martin v. Löwis [EMAIL PROTECTED] writes: Thomas Heller wrote: Sounds good, although it should be noted that ctypes is a package now, with a ctypes.wrap subpackage (contains the code generator), a ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X), and ctypes.test subpackage whcih contains several test modules. Plus the _ctypes.(dll|so) extension module. Ok. The installer should then combine them all into a feature. Still, the admin could disable all of this just by removing _ctypes.dll, right? Right. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev Summary for 2005-12-16 through 2005-12-31
Tony Meyer [EMAIL PROTECTED] writes: -- Adding zlib module to python25.dll -- Thomas Heller and Martin Heller had been discussing whether the zlib Should be 'Martin v. Löwis', as we all know. module should become builtin, at least on Windows (i.e. part of python25.dll). This would simplify both the build process and py2exe, the latter could then bootstrap extraction from the compressed file just with pythonxy.dll, but this is currently not done, because the pythoncore.vcproj would then not be buildable anymore unless you also have the right version of zlib on disk. To solve this problem, Thomas proposed that the Python release could incorporate a copy of zlib, primarily for use on Windows (with the project files appropriately adjusted). This change was later made. Contributing thread: - `Incorporation of zlib sources into Python subversion http://mail.python.org/pipermail/python-dev/2005-December/058873.html`__ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Martin v. Löwis [EMAIL PROTECTED] writes: Guido van Rossum wrote: On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). I don't expect this to count against including ctypes; but I do want it to be dealt with somehow! I think the strongest point *for* ctypes is the inclusion of dl in the source distribution, which has the very same flaws as ctypes in terms of crashability. So as for dealing with it somehow: I would make ctypes a dynamically loaded module (ctypes.pyd), so administrators could remove it, and I could also make it a separate option in the Windows installer, so administrators could reject to install it. It looks like we need a pronouncement now. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Building on OS X 10.4 fails
Building the readline on OS X 10.4 fails, is this known, or am I doing something wrong? Thanks, Thomas building 'readline' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/Users/theller/svn/trunk/./Include -I/Users/theller/svn/trunk/./Mac/Include -I./Include -I. -I/Users/theller/svn/trunk/Include -I/Users/theller/svn/trunk -c /Users/theller/svn/trunk/Modules/readline.c -o build/temp.darwin-8.4.0-Power_Macintosh-2.5/readline.o /Users/theller/svn/trunk/Modules/readline.c: In function 'write_history_file': /Users/theller/svn/trunk/Modules/readline.c:112: warning: implicit declaration of function 'history_truncate_file' /Users/theller/svn/trunk/Modules/readline.c: In function 'py_remove_history': /Users/theller/svn/trunk/Modules/readline.c:301: warning: implicit declaration of function 'remove_history' /Users/theller/svn/trunk/Modules/readline.c:301: warning: assignment makes pointer from integer without a cast /Users/theller/svn/trunk/Modules/readline.c:310: warning: passing argument 1 of 'free' discards qualifiers from pointer target type /Users/theller/svn/trunk/Modules/readline.c:312: warning: passing argument 1 of 'free' discards qualifiers from pointer target type /Users/theller/svn/trunk/Modules/readline.c: In function 'py_replace_history': /Users/theller/svn/trunk/Modules/readline.c:338: warning: implicit declaration of function 'replace_history_entry' /Users/theller/svn/trunk/Modules/readline.c:338: warning: assignment makes pointer from integer without a cast /Users/theller/svn/trunk/Modules/readline.c:347: warning: passing argument 1 of 'free' discards qualifiers from pointer target type /Users/theller/svn/trunk/Modules/readline.c:349: warning: passing argument 1 of 'free' discards qualifiers from pointer target type /Users/theller/svn/trunk/Modules/readline.c: In function 'get_current_history_length': /Users/theller/svn/trunk/Modules/readline.c:453: error: 'HISTORY_STATE' undeclared (first use in this function) /Users/theller/svn/trunk/Modules/readline.c:453: error: (Each undeclared identifier is reported only once /Users/theller/svn/trunk/Modules/readline.c:453: error: for each function it appears in.) /Users/theller/svn/trunk/Modules/readline.c:453: error: 'hist_st' undeclared (first use in this function) /Users/theller/svn/trunk/Modules/readline.c:455: warning: implicit declaration of function 'history_get_history_state' /Users/theller/svn/trunk/Modules/readline.c: In function 'insert_text': /Users/theller/svn/trunk/Modules/readline.c:503: warning: implicit declaration of function 'rl_insert_text' /Users/theller/svn/trunk/Modules/readline.c: In function 'on_completion': /Users/theller/svn/trunk/Modules/readline.c:637: error: 'rl_attempted_completion_over' undeclared (first use in this function) /Users/theller/svn/trunk/Modules/readline.c: In function 'flex_complete': /Users/theller/svn/trunk/Modules/readline.c:675: warning: passing argument 2 of 'completion_matches' from incompatible pointer type /Users/theller/svn/trunk/Modules/readline.c: In function 'setup_readline': /Users/theller/svn/trunk/Modules/readline.c:700: warning: passing argument 2 of 'rl_bind_key_in_map' from incompatible pointer type /Users/theller/svn/trunk/Modules/readline.c:701: warning: passing argument 2 of 'rl_bind_key_in_map' from incompatible pointer type /Users/theller/svn/trunk/Modules/readline.c: In function 'readline_until_enter_or_signal': /Users/theller/svn/trunk/Modules/readline.c:758: warning: passing argument 2 of 'rl_callback_handler_install' from incompatible pointer type /Users/theller/svn/trunk/Modules/readline.c:788: warning: implicit declaration of function 'rl_free_line_state' /Users/theller/svn/trunk/Modules/readline.c:789: warning: implicit declaration of function 'rl_cleanup_after_signal' /Users/theller/svn/trunk/Modules/readline.c: In function 'call_readline': /Users/theller/svn/trunk/Modules/readline.c:883: error: 'HISTORY_STATE' undeclared (first use in this function) /Users/theller/svn/trunk/Modules/readline.c:883: error: 'state' undeclared (first use in this function) /Users/theller/svn/trunk/Modules/readline.c:885: warning: assignment discards qualifiers from pointer target type ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Martin v. Löwis [EMAIL PROTECTED] writes: Guido van Rossum wrote: On 1/16/06, Thomas Heller [EMAIL PROTECTED] wrote: It looks like we need a pronouncement now. Sorry. It appeared to me that there was general agreement to using a strongly worded warning in the docs, so I tuned out of the rest of the discussion. So for the record, I'm fine with that. Ok. If Thomas checks in the code and the documentation, I'll do the Windows/setup part of it. Great. Now, I'm trying to build ctypes on OS X as the first non-windows platform. As I said, ctypes currently has its own source copy of libffi (since there are no separate releases of libffi, and the only platform that comes with libffi by default that I know is cygwin). It is built into a static non-shared library with a call to configure like this: cd build_dir src_dir/configure --disable-shared --enable-static \ --enable-multilib=no --prefix=inst_dir make install then libffi.a is linked into the _ctypes extension module. I know near to nothing about 'configure', can/should a call to os.system with the commands above be added to setup.py, or how could this be approached? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Tony Meyer [EMAIL PROTECTED] writes: - Adding ctypes to the standard library - Thomas Heller suggested that ctypes be included in core Python (starting with 2.5). The common response was that while ctypes is a useful, popular, mature module, it does make it very easy to get a core dump, which violates the guideline that if you get a core dump it's a bug in Python or in a third party extension or you're doing something harebrained. On the other hand, it was pointed out that the dl module suffers from the same problem, and is included without any warnings (the documentation was later fixed to include warnings). Martin v. Löwis suggested making ctypes a dynamically loaded module (ctypes.pyd), so administrators could remove it, and I could also make it a separate option in the Windows installer, so administrators could opt out of installing it. Everyone seemed happy with prominent warnings in the documentation, and so this is how it was checked in. Well, it is *not* yet checked in. The current state is that ctypes uses GPL'd tools to build libffi, and those can't be committed into Python SVN. http://mail.python.org/pipermail/python-dev/2006-January/059937.html Currently I tend to agree with Martin and drop the idea for now, but this probably doesn't belong into your summary ;-). Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Thomas Wouters [EMAIL PROTECTED] writes: On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote: The current state is that ctypes uses GPL'd tools to build libffi, and those can't be committed into Python SVN. http://mail.python.org/pipermail/python-dev/2006-January/059937.html But http://mail.python.org/pipermail/python-dev/2006-January/059938.html was never responded to. Lack of time - sorry. And licenses are fluid, it may be a piece of cake to get one of those 'tools' un-GPL'ed, even if they are. I wouldn't even know whom to ask. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
James Y Knight [EMAIL PROTECTED] writes: On Jan 19, 2006, at 4:24 PM, Thomas Heller wrote: Several of these files are licensed under GPL: aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh ltconfig missing Are you sure? The copies of aclocal.m4 and config-ml.in both disagree with you. aclocal seems to have a completely liberal license, and config-ml has a whatever the license of the program it's building license. It seems you are right: config-ml.in: GPL with special exception. config.guess: GPL with special exception. config.sub: GPL with special exception. configure: no limitation depcomp: GPL with special exception. install-sh: X-11 license ltcf-c.sh:GPL with special exception. ltconfig: GPL with special exception. ltmain.sh:GPL with special exception. aclocal.m4: see below Is aclocal.m4 an exception? It has several copyright notices. The first one gives unlimited permissions to copy and/or distribute, but sections after that have no exception clause. I'm unsure what this means. The files that ctypes uses are in CVS here: http://cvs.sourceforge.net/viewcvs.py/ctypes/ctypes/source/gcc/libffi/?only_with_tag=branch_1_0 Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Ronald Oussoren [EMAIL PROTECTED] writes: On Jan 26, 2006, at 9:22 AM, Ronald Oussoren wrote: It shouldn't be too hard to use Python's main configure script to calculate the information necessary to build libffi. A lot of it is already calculated anyway (sizeof various type, endianness), some can be hardcoded (FFI_NO_RAW_API). In PyObjC I just compile the files I need from my setup.py. But I have an easy task, I just need to support two CPU architectures on one OS. Merging the two configure files might be a good idea anyway, that would take away the need to run configure from setup.py. IANAL, but I don't quite get how a GPL'd support script, if there is such a thing, in the build machinery of an extension library would require that Python itself is GPL'd. Anyhow, in my copy of libffi (a snapshot where the last entry in the Changelog is from 2004-04-26) the only the following files at the toplevel op libffi are GPL licensed: config.guess, config.sub, config-ml.in, ltcf-c.sh, ltconfig, ltmain.sh, missing. All of these contain an exception clause like this one in config.guess: ctypes libffi is somewhat newer, around 2005-05-09. # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. I'd say that it should be save to include these in the Python distribution. As I said in the other thread (where the discussion should probably be continued anyway): http://mail.python.org/pipermail/python-dev/2006-January/060113.html only aclocal.m4 isn't clear to me about the license. Anyway, it could be that this file isn't needed after all - I don't know enough about the GNU toolchain to be sure. Can anyone comment on this? Neither do I know enough to merge the configure scripts. Contributions would really, really gratefully be accepted. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
John J Lee [EMAIL PROTECTED] writes: On Thu, 26 Jan 2006, Thomas Heller wrote: [...] As I said in the other thread (where the discussion should probably be continued anyway): http://mail.python.org/pipermail/python-dev/2006-January/060113.html only aclocal.m4 isn't clear to me about the license. Anyway, it could be that this file isn't needed after all - I don't know enough about the GNU toolchain to be sure. Can anyone comment on this? From 'info autoconf': | The Autoconf macros are defined in several files. Some of the files | are distributed with Autoconf; `autoconf' reads them first. Then it | looks for the optional file `acsite.m4' in the directory that contains | the distributed Autoconf macro files, and for the optional file | `aclocal.m4' in the current directory. Those files can contain your | site's or the package's own Autoconf macro definitions (*note Writing [...] So, I assume aclocal.m4 is under the same license as the rest of the libffi you're using. I cannot uinderstand your reasoning. How can 'info autoconf' incluence the license of the aclocal.m4 file? Or do I misunderstand something? Given that all kind of *nix experts are here on this list - can someone tell if aclocal.m4 is needed for building libffi at all or not? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] (libffi) Re: Copyright issue
[I've added python-dev to cc:] Anthony Green [EMAIL PROTECTED] writes: On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote: Anyway, another question is: Is aclocal.m4 needed at all for building (or maybe for regenerating the configure scripts), or is it optional? aclocal.m4 is required, but is only used as a build-time tool. The fact that aclocal.m4 is distributed under the GPL should have no impact on the licensing terms used for software built using aclocal.m4. If I understand correctly this means that the Python source distribution would have to be GPL licensed, while the built programs would be able to use another license. I'm pretty sure this kills the whole idea (to include libffi in python). Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Anthony Green [EMAIL PROTECTED] writes: On Fri, 2006-01-27 at 18:03 +0100, Thomas Heller wrote: [I've added python-dev to cc:] Anthony Green [EMAIL PROTECTED] writes: On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote: Anyway, another question is: Is aclocal.m4 needed at all for building (or maybe for regenerating the configure scripts), or is it optional? aclocal.m4 is required, but is only used as a build-time tool. The fact that aclocal.m4 is distributed under the GPL should have no impact on the licensing terms used for software built using aclocal.m4. If I understand correctly this means that the Python source distribution would have to be GPL licensed, while the built programs would be able to use another license. I'm pretty sure this kills the whole idea (to include libffi in python). I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Andrew Pinski [EMAIL PROTECTED] writes: Does phython already use autoconf? I think it does, if so then there should be no issues. [Anthony Green] I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. [Thomas Heller] I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. Giovanni Bajo [EMAIL PROTECTED] writes: That's no different. If you burn a CD containing a copy of the GCC and a copy of a commercial software you are not violating any license. If you distribute an .ISO file containing a copy of the GCC and a copy of a commercial software, you are not violating any license. If you distribute a .zip file containing a copy of GCC and a copy of a commercial software, you are not violating any license. There is an important difference between aggreggation of different programs, and static/dynamic linking of parts. Autoconf is a build tool, and it does not impose any license on the software you use it with. Plus some files have the special exception from GPL so that even the files *generated* by autoconf (and partly made of pieces of autoconf) do not require to be GPL. This is exactly like GCC's runtime library (libgcc, and also libstdc++) which are GPL with the special exception, and you can use them also for commercial products. Also, do not understimate previous history. There are zillions of programs out there using Autconf and *not* being GPL. Ok, understood - there is no problem. Hopefully the rest of the pythondev team is also convinced. The only question I have (maybe this is too off-topic, but since we're here already): Nearly all the tools that autoconf and automake use are careful to include an exception clause to the GPL license. Why is aclocal.m4 different? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Hye-Shik Chang [EMAIL PROTECTED] writes: On 1/28/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Heller wrote: Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? My understanding that doing so would be in violation of section 2b) of the GPL. However, I still think it is possible to include libffi - we just have to discard the build process, and do our own. I did some work to make ctypes+libffi compacter and liberal. http://openlook.org/svnpublic/ctypes-compactffi/ (svn) I removed sources/gcc and put sources/libffi copied from gcc 4.0.2. And removed all automake-related build processes and integrated them into setup.py. There's still aclocal.m4 in sources/libffi. But it is just identical to libffi's acinclude.m4 which looks liberal. That's great! Would you like to integrate these changes into to ctypes CVS repository yourself? I indend to do a few releases still from there, before the first Python 2.5. If so, please tell me your SF username and I'll add you as developer. Also, please note that all work should be done on the 'branch_1_0' CVS branch - the HEAD is only experimental code (and not currently used). Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Hye-Shik Chang [EMAIL PROTECTED] writes: On 1/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Well done! Would you like to derive a Python patch from that? Yup. I'll do. On 1/30/06, Thomas Heller [EMAIL PROTECTED] wrote: That's great! Would you like to integrate these changes into to ctypes CVS repository yourself? I indend to do a few releases still from there, before the first Python 2.5. If so, please tell me your SF username and I'll add you as developer. Also, please note that all work should be done on the 'branch_1_0' CVS branch - the HEAD is only experimental code (and not currently used). My SF username is perky. Added. I'll try to make it portable but it'll lose some platforms through compilers because few of libffi sources are in preprocessed assembly (.S) which isn't supported by distutils yet. So, we'll need tests on various compiler/platforms before the release. Isn't it sufficient to append .S to self.compiler.src_extensions? Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes patch
Hye-Shik Chang [EMAIL PROTECTED] writes: On 1/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Hye-Shik Chang wrote: I did some work to make ctypes+libffi compacter and liberal. http://openlook.org/svnpublic/ctypes-compactffi/ (svn) I removed sources/gcc and put sources/libffi copied from gcc 4.0.2. And removed all automake-related build processes and integrated them into setup.py. There's still aclocal.m4 in sources/libffi. But it is just identical to libffi's acinclude.m4 which looks liberal. Well done! Would you like to derive a Python patch from that? Don't worry about MSVC, yet, I will do that once the sources are in the subversion. Here goes patches for the integration: [1] http://people.freebsd.org/~perky/ctypesinteg-f1.diff.bz2 [2] http://people.freebsd.org/~perky/ctypesinteg-f2.diff.bz2 I implemented it in two flavors. [1] runs libffi's configure along with Python's and setup.py just builds it. And [2] has no change to Python's configure and setup.py runs libffi configure and builds it. And both patches don't have things for documentations yet. My plan is to make separate ctypes releases for 2.3 and 2.4, even after it is integrated into Python 2.5, so it seems [2] would be better - it must be possible to build ctypes without Python. As I said before, docs need still to be written. I think content is more important than markup, so I'm writing in rest, it can be converted to latex later. I expect that writing the docs will show quite some edges that need to be cleaned up - that should certainly be done before the first 2.5 release. Also I want to make a few releases before declaring the 1.0 version. This does not mean that I'm against integrating it right now. (Of course, for due process, it would be better if this code gets integrated into the official ctypes first, and then we incorporate some named/versioned snapshot into /external, and svn cp it into python/trunk from there). Thomas and I collaborated on integration into the ctypes repository and testing on various platforms yesterday. My patches for Python are derived from ctypes CVS with a change of only one line. Hye-Shik has done a great job! Many thanks to him for that. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes patch (was: (libffi) Re: Copyright issue)
Hye-Shik Chang [EMAIL PROTECTED] writes: I did some work to make ctypes+libffi compacter and liberal. http://openlook.org/svnpublic/ctypes-compactffi/ (svn) Here goes patches for the integration: [1] http://people.freebsd.org/~perky/ctypesinteg-f1.diff.bz2 [2] http://people.freebsd.org/~perky/ctypesinteg-f2.diff.bz2 I implemented it in two flavors. [1] runs libffi's configure along with Python's and setup.py just builds it. And [2] has no change to Python's configure and setup.py runs libffi configure and builds it. And both patches don't have things for documentations yet. [Thomas Heller] My plan is to make separate ctypes releases for 2.3 and 2.4, even after it is integrated into Python 2.5, so it seems [2] would be better - it must be possible to build ctypes without Python. As I said before, docs need still to be written. I think content is more important than markup, so I'm writing in rest, it can be converted to latex later. I expect that writing the docs will show quite some edges that need to be cleaned up - that should certainly be done before the first 2.5 release. Also I want to make a few releases before declaring the 1.0 version. This does not mean that I'm against integrating it right now. Martin v. Löwis [EMAIL PROTECTED] writes: Not sure whether you think you need further approval: if you are ready to check this into the Python trunk, just go ahead. As I said, I would prefer if what is checked in is a literal copy of the ctypes CVS (as far as reasonable). I was not looking for further approval, I wanted to explain why I prefer the patch [2] that Hye-Shik posted above. I'll do at least one separate ctypes release before checking this into the Python trunk. Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Martin v. Löwis [EMAIL PROTECTED] writes: I just came up with an idea how to resolve the VC versioning problems for good: Python should link with mscvrt.dll (which is part of the operating system), not with the CRT that the compiler provides. To do that, we would need to compile and link with the SDK header files and import libraries, not with the ones that visual studio provides. For that to work, everyone building Python or Python extensions (*) would have to install the Platform SDK (which is available for free, but contains quite a number of bits). Would that be acceptable? Disclaimer: I haven't tried yet whether this would actually work. Regards, Martin (*) For Python extensions, it should be possible to use mingw instead, and configure it for linking against msvcrt. I think think would remove a lot of headaches. Downloading and installing the Platform SDK should not be an issue, imo. The only problem that I see is this: I'm not sure the platform SDK include files (.H and .IDL) are really compatible with VC7.1. I remember that we (on our company, building C++ software) had to 'Unregister the PSDK Directories with Visual Studio' (available from the start menu) before building the stuff, otherwise there were compiler errors. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
Jason Orendorff wrote:
Instead of byte literals, how about a classmethod bytes.from_hex(), which
works like this:
# two equivalent things
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
I hope this will also be equivalent:
expected_md5_hash = bytes.from_hex('5c 53 50 24 ca c5 19 91 53 e3 83 4f e5
c9 2e 6a')
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: defaultdict
Guido van Rossum wrote: So here's a new proposal. Let's add a generic missing-key handling method to the dict class, as well as a default_factory slot initialized to None. The implementation is like this (but in C): def on_missing(self, key): if self.default_factory is not None: value = self.default_factory() self[key] = value return value raise KeyError(key) When __getitem__() (and *only* __getitem__()) finds that the requested key is not present in the dict, it calls self.on_missing(key) and returns whatever it returns -- or raises whatever it raises. __getitem__() doesn't need to raise KeyError any more, that's done by on_missing(). Will this also work when PyDict_GetItem() does not find the key? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: defaultdict
[cc to py-dev again] Guido van Rossum wrote: On 2/17/06, Thomas Heller [EMAIL PROTECTED] wrote: Guido van Rossum wrote: So here's a new proposal. Let's add a generic missing-key handling method to the dict class, as well as a default_factory slot initialized to None. The implementation is like this (but in C): def on_missing(self, key): if self.default_factory is not None: value = self.default_factory() self[key] = value return value raise KeyError(key) When __getitem__() (and *only* __getitem__()) finds that the requested key is not present in the dict, it calls self.on_missing(key) and returns whatever it returns -- or raises whatever it raises. __getitem__() doesn't need to raise KeyError any more, that's done by on_missing(). Will this also work when PyDict_GetItem() does not find the key? Ouch, tricky. It should, of course, but the code will be a tad tricky because it's not supposed to inc the refcount. Thanks for reminding me! Ahem, I'm still looking for ways to 'overtake' the dict to implement weird and fancy things. Can on_missing be overridden in subclasses (writing the subclass in C would not be a problem)? Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator.is*Type
Fuzzyman wrote: Hello all, Feel free to shoot this down, but a suggestion. The operator module defines two functions : isMappingType isSquenceType These return a guesstimation as to whether an object passed in supports the mapping and sequence protocols. These protocols are loosely defined. Any object which has a ``__getitem__`` method defined could support either protocol. The docs contain clear warnings about that. I suggest we either deprecate these functions as worthless, *or* we define the protocols slightly more clearly for user defined classes. I have no problems deprecating them since I've never used one of these functions. If I want to know if something is a string I use isinstance(), for string-like objects I would use try: obj + except TypeError: and so on. An object prima facie supports the mapping protocol if it defines a ``__getitem__`` method, and a ``keys`` method. An object prima facie supports the sequence protocol if it defines a ``__getitem__`` method, and *not* a ``keys`` method. As a result code which needs to be able to tell the difference can use these functions and can sensibly refer to the definition of the mapping and sequence protocols when documenting what sort of objects an API call can accept. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] str(Exception) changed, is that intended?
I know that my unittests should not rely on this, but is this change intended? c:\sf\ctypes_headpy24 Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) 'exceptions.Exception' ^Z c:\sf\ctypes_headpy Python 2.5a0 (trunk:42903M, Mar 7 2006, 22:01:07) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. str(Exception) class 'exceptions.Exception' ^Z ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how about adding ping's uuid module to the standard lib ?
Paul Moore wrote: On 3/7/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 06:29 AM 3/7/2006 +0100, Fredrik Lundh wrote: see subject and http://python.org/sf/1368955 comments ? would be nice if you could just call UUID() to create a generic UUID in a platform-appropriate way. PEAK's uuid module does this such that if win32all is present, you get a Windows GUID, or if you have a FreeBSD 5+ or NetBSD 2+ kernel you use the local platform uuidgen API. See e.g.: Given that ctypes is going to be in Python 2.5, it might be reasonable to use it to access platform-specific APIs like this. It certainly makes some sense for Windows, where running an external process is slow, and the existence of suitable external utilities (and the format of their output!) is unreliable... (I haven't looked at the code, so I don't know if this applies to Ping's use of ipconfig). IMO that is a perfect use-case for ctypes - access 2 or 3 platform-specific api functions. Too bad that ctypes whill be an optional module, so I'm not sure if it could be used in the Python library itself. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how about adding ping's uuid module to the standard lib ?
Oleg Broytmann wrote: On Tue, Mar 07, 2006 at 10:19:03PM +0100, Thomas Heller wrote: Too bad that ctypes whill be an optional module, so I'm not sure if it could be used in the Python library itself. try: import ctypes except ImportError: def fallback(): ... else: def real_thing(): ... Personally, I don't like standard modules to behave different if I install other stuff, so please change 'could' to 'should' in this sentence: not sure if it could be used in the Python library itself. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mail.python.org disruption
Thomas Wouters wrote: [ Mailed to python-dev and python-list, as that should cover most of the users ;P ] There was a slight disruption on mail.python.org this morning. For about three and a half hours, it was rejecting most of its mail with the message: Client host [] blocked using singlehop.dsbl.org; Your mail has been rejected because the server you are sending to is misconfigured. The error means mail.python.org was using singlehop.dsbl.org as a DNSBL list, but that list doesn't exist, so it rejects all mail. Someone (not me :) added that blacklist at 08:15 local time (07:15 GMT) and I fixed it at 11:46 (10:46 GMT). Blame lingering PyCon-jetlag for me not catching it earlier, sorry. About 7759 mails were bounced, although a decent portion of them will have been actual spam (of which python.org gets massive amounts.) If you sent legitimate mail in that period, and got a bounce back with a message like the one above, it's safe to re-send it now. Sorry for the inconvenience. Has this also to do with that http://svn.python.org/ doesn't work? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ctypes is in SVN now.
ctypes is in SVN now, and the buildbot is green, after I disabled a test that dumped core on sparc solaris. The crash was apparently caused Missing are .vcproj files for Windows, both for the _ctypes.pyd extension and the _ctypes_test.pyd extension needed for testing. IIRC, Martin promised to create them - is this offer still valid? I could do that myself, but only for x86, while other .pyd files also have build settings for Itanium and x86_64. (I find it always very painful to click through the settings dialog in MSVC - isn't there any other way to create these files?) Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes is in SVN now.
Giovanni Bajo wrote: Thomas Heller [EMAIL PROTECTED] wrote: Missing are .vcproj files for Windows, both for the _ctypes.pyd extension and the _ctypes_test.pyd extension needed for testing. IIRC, Martin promised to create them - is this offer still valid? I could do that myself, but only for x86, while other .pyd files also have build settings for Itanium and x86_64. (I find it always very painful to click through the settings dialog in MSVC - isn't there any other way to create these files?) I discussed with Martin a bit about the opportunity of generating .vcproj files with a script-driven tool. I'm going to try and setup something as soon as I find some spare time. The goal of this work would exactly fit your need: make the creation of extension modules trivially easy (just as easy as adding the modules to the main python.dll). My personal goal, in fact, is to move many of those builtin extension modules from python.dll out into their own .pyd files where they'd belong (were not for this technical annoyance of being forced to use the settings dialog in MSVC). Ideally this would be integrated with distutils because the setup-script has most of the information that's needed. OTOH, extensions could be built with distutils even for core Python, and even on Windows. For extensions that are *not* builtin or not included with Python itself distutils works good enough. Oh, IIRC the pywin32 setup script has code that is able to parse MSVC6 project files and create a distutils Extension instance from them - maybe this can help you. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes is in SVN now.
Giovanni Bajo wrote: Thomas Heller [EMAIL PROTECTED] wrote: I discussed with Martin a bit about the opportunity of generating .vcproj files with a script-driven tool. I'm going to try and setup something as soon as I find some spare time. Ideally this would be integrated with distutils because the setup-script has most of the information that's needed. OTOH, extensions could be built with distutils even for core Python, and even on Windows. For extensions that are *not* builtin or not included with Python itself distutils works good enough. I fear this is an orthogonal change. Alas, using distutils to build core extensions is not something I'm ready to tackle at the moment. I was just thiking of something much more naive like using a free tool to build .vcproj/.sln (see www.cmake.org for instance) from a script description. With such a tool, it would be very easy to build a .pyd file around a self-contained .c file (like _heapqmodule.c, etc.), it would mostly be a couple of line changes in the script file, and then re-run the tool executable to regenerate vcproj/sln. OTOH, both the tool executable (cmake.exe in this example) and the current version of the generated vcproj/sln files would be committed in SVN under PCbuild, so to have a minimal impact on developer habits. While I don't understand *why* you would want to do this (building Python interpreters with a customized list of builtin modules could be a reason for this, I've had thought about something like that for py2exe a long time ago), I've clicked myself through the MSVC dialog and I'm happy now because the two .vcproj files are ready. I'll commit them and let others (Martin, probably) extend them for 64-bit Windows versions ;-). Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r42929 - python/trunk/Tools/scripts/svneol.py
Tim Peters wrote: [Tim Peters] Added: python/trunk/Tools/scripts/svneol.py (contents, props changed) Log: Simple utility to add svn:eol-style to text files under SVN control. Like reindent.py, I expect to run this mindlessly from time to time, checking in whatever it happens to do ;-) [Thomas Heller] Should 'sln' and 'vcproj' be added to the extensions list? I think these are text-files too. Although PCBuild\pcbuild.sln has a binary mime-type property, so the script would not change that. I don't know whether they're text files in the SVN eol-style native sense. The corresponding file types under VC 6 were not: in SVN terms, they should have svn:eol-style set to CRLF (Visual Studio required \r\n line ends for some inscrutable reason -- it would not I know. In CVS, they had to be added using the -kb flag, IIRC. tolerate \n line ends, and this mattered when, e.g., some Linux-head tried to run Visual Studio from a Linux-native checkout of Python; CRLF was still required, and we faked that under CVS by calling those files binary; SVN offers finer control; I don't know how picky the .NET 2003 MSDev is about this). I remember that someone has tested that the .vcproj files actually did work even if they had the wrong line endings, so it should be ok. AFAIK, noone tried that with the .sln file - anyway, I have removed the svn:mem-type property and the script then set svn:eol-style native. Maybe a different set of svn properties were better, I have to learn about them. The problem that I saw is that 'svn diff' refused to provide a diff when pcbuild.sln had changed - I would consider this diff useful, both in commit-emails as well as run on the command line before checking in. The Linux-head is the release manager, prepaing the release on a unixish platform, in combination with the windows guy who downloads the source distribution and tries to compile that on Windows. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes is in SVN now.
Tim Peters wrote: [Thomas Heller] ... And I never had tried it before on a sparc machine - all the intel and ppc processors seem to have no problems with it. Pentiums don't enforce natural alignment restrictions, but run much slower on unaligned access (varying by specific chip model, and generally more heavily penalized as time goes on). In the good old days, Pentium was one of dozens of competing architectures, and was the oddball in catering to unaligned access. Now it's eternal backward compatibility with an early implementation accident. Most other architectures never catered to unaligned access, or did so only at the cost of generating an interrupt so that kernel-mode software could fake unaligned access. Bottom line is that unaligned access isn't portable and never was, and even on architectures where it works it can be extremely expensive to use it. I'm old enough to know this, but thanks anyway. I'm not so speed paranoid to care about these nanoseconds, maybe timeit can tell if there's a measurable difference. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes is in SVN now.
Tim Peters wrote: [Thomas Heller] ... I could do that myself, but only for x86, while other .pyd files also have build settings for Itanium and x86_64. (I find it always very painful to click through the settings dialog in MSVC - isn't there any other way to create these files?) Under VC 6 I generally just renamed a copy of a similar existing project file and used a text editor to change the paths. I haven't tried that under the 7.1 MSDev. That's what I did when I created _ctypes_test.vcproj from _ctypes.vcproj. I had to insert a new guid though. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r42929 - python/trunk/Tools/scripts/svneol.py
Tim Peters wrote: [Thomas Heller] ... The Linux-head is the release manager, prepaing the release on a unixish platform, in combination with the windows guy who downloads the source distribution and tries to compile that on Windows. That sounds like an artificial (process-created) problem, then. Since a release should be made from a tag, there doesn't seem a real reason to make the Windows release wait for a source-release tarball to get made (the Windows dweeb should be able to do a native checkout of the tag, and do their stuff in parallel -- that's how I used to do Windows releases, and it worked fine -- the only thing the Windows release serialized on was waiting for the release's final docs to get cut). I did it the same way for the 2.3 releases that I made. But I did not mean the official binary Windows installer, I mean someone who downloads the official source tarball, and compiles that himself. There was at least one 2.3 release where one could not compile with MSVC6 from the source tarball because of wrong line endings. Setting project files to some flavor of text mode makes sense for your other reasons regardless (like getting useful diffs). Sure. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes is in SVN now.
Thomas Wouters wrote: (about ctypes and Py_ssize_t) you want to do that yourself, or do you want me to submit a patch? (Or I could just check it in ;) You can do it faster then me, I assume - so go ahead and check it in. I'll backport it to the upstream ctypes CVS repository. I'm not sure if I'll be faster. It's quite a lot of work to make it completely Py_ssize_t-aware (but worth it, IMHO; ints just don't cut it on 64-bit platforms. :) I have a simple patch to silence the warnings, but it doesn't support indexing beyond int-size and such. I'm also going through all of the code and changing most appropriate things into Py_ssize_t's, and that would be much nicer. I'll probably have some XXX markers left when I'm done, though. Also, how stable should the C API be? Does the C code have any direct users besides Python? Apart from a few functions that are used as foreign functions from ctypes itself (memmove and memset currently), the C api is not used from the outside. The important thing when changing something in the ctypes sources is to run the unittests (*) on as many platforms and Python versions as possible - currently I do this on all the sourceforge compile farm machines that have either Python = 2.3, or where I have been able to compile Python myself. Plus WindowsXP 32 and OSX 10.4. This is for the ctypes upstream version, of course. If your patch is going to change more than a few int - Py_ssize_t replacements it would probably be less work to do it in ctypes CVS instead of Python SVN. Maintaining code in multiple repositories is no fun ;) (*) ctypes unittests are run by 'python ctypes/test/runtests.py', for example. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Developing/patching ctypes (was: Re: integrating ctypes into python)
[CC to python-dev again] Hye-Shik Chang wrote: On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote: Hye-Shik Chang wrote: On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote: I've now committed ctypes 0.9.9.4 into SVN. It seems to build, at least on the buildbots that are online. Good work! It's all green on my machines (FreeBSD amd64/sparc64). But gcc outputs some warnings: 1) libffi/include/ffi.h.in: void (*fn)() - void (*void)(void) This is not the only file that would have to be changed. I wonder why they don't change it in gcc itself. This *is* the only change to calm gcc warnings down except Py_ssize_t stuff. :-) 2) many of Py_ssize_t / int prototype mismatches. (eg. sq_repeat) Could we make ctypes Py_ssize_t clean? 3) ctypes doesn't support Py_ssize_t nor ssize_t yet. Because major portion of our pythonapi uses it now, it would be better to have it. This should be done in ctypes CVS, and the result imported into python SVN after that. At least ctypes (the Python module) has an c_size_t type now ;-). I'll do it in this weekend. I saw that branch_1_0 is merged into HEAD. Which branch are you using for Python integration at now? I did 'cvs export -r release_0_9_9_4' from the SF repository and then imported this into python SVN external/ctypes-0.9.9.4. The 'release_0_9_9_4' tag is on the 'branch_1_0' branch. I moved on a little bit on that branch, later merged everything into SF CVS HEAD, and continued to work there. We'll have to coordinate this. Different people working in different repositories will become a maintaince nightmare, so there should be an official 'master' repository for ctypes. Question for python-dev: Would it be a solution to move the 'official' ctypes development into Python SVN external/ctypes, or would this be considered abuse? Another location in SVN could be used as well, if external is though to contain only vendor drops... Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Thomas Wouters wrote: On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote: Would it be a solution to move the 'official' ctypes development into Python SVN external/ctypes, or would this be considered abuse? Another location in SVN could be used as well, if external is though to contain only vendor drops... If all the developers are also python-developers (or at least have svn access), and the source is supposed to be identical, SVN obviously beats SVN I didn't know that SVN is *that great* :) ! :) I can work equally well with the main repository in CVS, though, and I've had quite a bit of practice in merging changes. Cool. Martin v. Löwis wrote: external indeed is meant only for vendor drops. I personally don't mind having the upstream ctypes repository also in svn.python.org; this would be similar to distutils, setuptools, and (I think) the email package. Currently, some of them live in sandbox/trunk, but I wouldn't mind it living in /ctypes/trunk, either. Be aware that the set of committers to svn.python.org/projects is currently restricted to Python committers. I think the currently active ctypes developers are also Python committers, additionally I've asked on the ctypes-users list for objections. I'll think about this stuff over the weekend, currently I tend to moving ctypes to Python SVN. Whether it will be /ctypes/trunk or sandbox/ctypes I don't really care. In the meantime, please: If anyone is going to make fixes to the ctypes source code (apart from Tim's regular whitespace cleanup), please do this in the ctypes CVS repository on sourceforge, in the trunk. If anyone (of the Python developers) wants to do this and doesn't currently have commit access, please mail me your SF userid privately. Note that both perky and Thomas Wouters have promised to do Py_ssize_t fixes - please coordinate that to avoid double work. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Tim Peters wrote: [Thomas Heller] ... In the meantime, please: If anyone is going to make fixes to the ctypes source code (apart from Tim's regular whitespace cleanup), please do this in the ctypes CVS repository on sourceforge, in the trunk. FYI, my regular whitespace cleanup consists of running reindent.py from the root of a Python checkout (cd python; reindent.py -r .). There's nothing specific to the Python project about that little procedure, and, e.g., I regularly did the same for Zope Corp's ZODB project. I've nothing against that, and I should myself get used to do the same in my own repositories from time to time. BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 Is there a way to get the actual failures somehow? Running the tests in verbose mode by default is probably not a good idea, because it may make tests fail, AFAIK. If not, I have no other choice (since I don't have a 64-bit machine myself) than to test this in the sourceforge compilefarm amd64 machine, which is a pain since they don't allow outbound network from there. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes is in SVN now.
Tim Peters wrote: [Thomas Heller] ... And I never had tried it before on a sparc machine - all the intel and ppc processors seem to have no problems with it. Pentiums don't enforce natural alignment restrictions, but run much slower on unaligned access (varying by specific chip model, and generally more heavily penalized as time goes on). In the good old days, Pentium was one of dozens of competing architectures, and was the oddball in catering to unaligned access. Now it's eternal backward compatibility with an early implementation accident. Most other architectures never catered to unaligned access, or did so only at the cost of generating an interrupt so that kernel-mode software could fake unaligned access. Bottom line is that unaligned access isn't portable and never was, and even on architectures where it works it can be extremely expensive to use it. I was astonished to find out that also the ARM processor on Windows CE doesn't support unaligned accesses. When one thinks about it, it probably makes sense on small devices. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Martin v. Löwis wrote: Thomas Heller wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: FWIW, ctypes doesn't even build on a Windows AMD64 machine. It wants to use the Windows x86 FFI code, which does not compile with the AMD64 compiler. On such a machine probably other source files should be used. I have no such machine - is it possible to build the 64-bit version on a 32-bit machine (with the platform SDK)? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Neal Norwitz wrote: On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 Is there a way to get the actual failures somehow? Running the tests in verbose mode by default is probably not a good idea, because it may make tests fail, AFAIK. I want to modify regrtest so the traceback info is stored in a file, so you can still retrieve the data after a test run. I haven't started making this mod yet. There are also sporadic test failures on the OSX machine: http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/345/step-test/0 I think the test is broken - but what I find interesting is that in this case the actual failure is printed: test_set test_ctypes test test_ctypes failed -- Traceback (most recent call last): File /Users/buildslave/bb/trunk.4/build/Lib/ctypes/test/test_leaks.py, line 68, in test_cycles_refcount self.fail(leaking refcounts) AssertionError: leaking refcounts test_long_future Why is that? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
Martin v. Löwis wrote: Josiah Carlson told me had has given up getting a Windows buildbot running, because every time he installed VS.NET on his machine, the installation would immediately crash. So if anybody wants to contribute both a machine and time to operate it (including the likely very tedious phase to get any results out of this at all), please contact me. Are there any estimates how much network traffic a buildbot would generate? And how must it be connected to the internet - I assume it must be reachable from the outside. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Thomas Wouters wrote: On 3/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Heller wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 Is there a way to get the actual failures somehow? They are now in http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/280/step-test/0 I suspect that some of those failures probably aren't ctypes failures, but re-running-ctype-tests-in-the-same-process failures (like the very first one) -- I get more errors when running -R:: than I do when running the test verbosely directly. I can reproduce that now - thanks for finding the problem. IMO, some of the ctypes tests are kind-of broken, since they keep state although they should not. Maybe re-running the test could be done in a freshly spawned Python? I'll try to fix the ctypes-tests starting on Monday, so I assume that would not be necessary. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
Trent Mick wrote: Yup. Looks like my build worked. Another TODO now though: - Figure out why usage of: winsound.PlaySound(something, winsound.SND_ALIAS) fails on my Win2k box. This is why the test suite fails on that box. Doesn't that always fail when there is no soundcard in the machine? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Developing/patching ctypes
Neal Norwitz wrote:
On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote:
Would it be a solution to move the 'official' ctypes development into
Python SVN external/ctypes, or would this be considered abuse? Another
location in SVN could be used as well, if external is though to contain
only vendor drops...
Thomas,
I'd be fine with the official ctypes repo being Python SVN.
The attached patch fixes all the ctypes tests so they pass on amd64.
It also fixes several warnings. I'm not sure what else to do with the
patch. Let me know how you want to handle these in the future.
I'm not sure the patch is 100% correct. You will need to decide what
can be 64 bits and what can't. I believe
sq_{item,slice,ass_item,ass_slice} all need to use Py_ssize_t. The
types in ctypes.h may not require all the changes I made. I don't
know how you want to support older version, so I unconditionally
changed the types to Py_ssize_t.
n
Thanks, Neal, I'll look into that this night.
In the future I hope to have access to a amd64-linux system, and I'll try
to keep this stuff up-to-date myself.
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Tim Peters wrote: [Martin] ... I believe it does: the ctypes maintainer wants to keep the code identical across releases (AFAICT). Correct, that's why I listed it in PEP 291. Fair enough -- I reverted the checkin. It's going to need #if'ery on the Python version, though, if it wants to match a Python-version-dependent data width with an appropriate format code. You could have left it in, I'm very thankful for any help that I get. Making the patch version independent is my job - unless someone else takes care of it, of course. BTW: Is a porting guide to make extension modules compatible with 2.5 available somewhere? PEP 353 scratches only the surface... Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] towards a stricter definition of sys.executable
Fredrik Lundh wrote: the definition of sys.executable is a bit unclear, something that has led to incompatible use in deployed code. the docstring for sys.executable says pathname of this Python interpreter, which can be interpreted as either a) sys.executable points to the executable that was used to load the Python interpreter library/dll. this use is supported by the docstring and the implementation, and is quite common in the wild. an application using this interpretation may - call sys.executable to run another instance of itself - extract data from resources embedded in (or attached to) sys.executable - locate configuration data etc via os.path.dirname(sys.executable) etc. or b) sys.executable points to a standard Python interpreter executable of the same version, and having the same library, as the currently running interpreter instance. this use is supported by more strict interpretation of the word interpreter (as an executable, rather than an implementation DLL), and is quite common in the wild. an application using this interpretation may - call sys.executable to run a Python script in the same environment as itself. etc. or c) sys.executable points to the file containing the actual (this) interpreter. I haven't seen any code that assumes this, probably because no implementation uses this interpretation... for programs that are invoked via the standard interpreter, case (a) and (b) are of course identical. py2exe used the a) interpretation. It uses sys.executable to find the exe that is currently running, for registration of COM servers, and for finding resources in the exe: the manifest file that's needed for GUI applications on WindowsXP to give the native XP look and feel, icons, typelibs, and more. the problem is when the interpreter library is embedded in some other application; should sys.executable be set to the actual EXE used to start the program, or to something else ? if it's set to something else, how can that application do the things that's described under (a) ? The use case for b) 'call sys.executable to run a Python script' makes no sense for a py2exe'd application. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Martin v. Löwis wrote: Thomas Heller wrote: BTW: Is a porting guide to make extension modules compatible with 2.5 available somewhere? PEP 353 scratches only the surface... Wrt. ssize_t changes, PEP 353 is meant to be comprehensive. Which particular aspect are you missing? I suggest to change this: #if PY_VERSION_HEX 0x0205 typedef int Py_ssize_t; #endif with this: #if (PY_VERSION_HEX 0x0205) typedef int Py_ssize_t; #define lenfunc inquiry #define readbufferproc getreadbufferproc #define writebufferproc getwritebufferproc #define segcountproc getsegcountproc #define charbufferproc getcharbufferproc #define ssizeargfunc intargfunc #define ssizessizeargfunc intintargfunc #define ssizeobjargproc intobjargproc #define ssizessizeobjargproc intintobjargproc ... more defines #endif Maybe a complete list of defines needed can be given? Then, from only reading the PEP without looking up the sources, it is not clear to me what the PY_SIZE_T_CLEAN definition does. Finally, the format codes to use for Py_ssize_t arguments passed to PyBuild_Value, PyString_FromFormat, PyObject_CallFunction (and other functions) are not mentioned at all. Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
Martin v. Löwis wrote: M.-A. Lemburg wrote: I think it's only fair that I ask the patch authors to complete the PEP, since the ssize_t patch is causing extension authors enough trouble already. Well, the PEP is complete as it stands. It's possible to provide more guidelines, but the specification part of it says precisely what I intend it to say. Also, the API documentation ought to be in the Python documentation, and, for these changes, it is. If you want quick adoption of the changes, you have to make it as easy as possible for the authors to port their extensions to the new API. Otherwise, we'll end up having quite a large number of users who can't switch to Python 2.5 simply because their favorite extensions don't work with it. I don't see how giving a complete list of all changed functions helps in any way. I'm not sure if this is what Marc-Andre means, but maybe these definitions could go into a new include file: #if (PY_VERSION_HEX 0x0205) typedef int Py_ssize_t; #define lenfunc inquiry #define readbufferproc getreadbufferproc #define writebufferproc getwritebufferproc #define segcountproc getsegcountproc #define charbufferproc getcharbufferproc #define ssizeargfunc intargfunc #define ssizessizeargfunc intintargfunc #define ssizeobjargproc intobjargproc #define ssizessizeobjargproc intintobjargproc ... more defines #endif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c
M.-A. Lemburg wrote: Martin v. Löwis wrote: Thomas Heller wrote: I'm not sure if this is what Marc-Andre means, but maybe these definitions could go into a new include file: How would that include file be used? You would have to copy it into your own source base, and include it, right? We could put it into a b/w compatibility header file, e.g. #include pycompat.h #include pep353.h ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Building Python for AMD64 (Windows)
I'm trying out to build Python for 64-bit Windows, running the tools on WinXP SP2 (32-bit). I have installed: - MSVC .NET 2003 - Platform SDK Feb 2003 - vsextcomp 0.6 Then I fire up MSVC, select the ReleaseAMD64 configuration, and try to build the pythoncore project. After lots of compiler warnings, the build fails with this message: cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON getbuildinfo2.c -DSUBWCREV -Fogetbuildinfo.o -I..\Include -I..\PC Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. getbuildinfo2.c Linking... LINK : warning LNK4044: unrecognized option '/USELINK:MS_SDK'; ignored getbuildinfo.o : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'AMD64' Build log was saved at file://c:\svn\trunk\PCbuild\amd64-temp-release\pythoncore\BuildLog.htm pythoncore - 1 error(s), 229 warning(s) Is there something wrong on my side? Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building Python for AMD64 (Windows)
Thomas Heller wrote: Martin v. Löwis wrote: Thomas Heller wrote: Then I fire up MSVC, select the ReleaseAMD64 configuration, and try to build the pythoncore project. After lots of compiler warnings, the build fails with this message: ... For some reason, VS.NET hasn't picked up the PATH modifications, so that it doesn't invoke the linker wrapper (which would have invoked the right compiler and linker). This sometimes happens, and I don't know why. As the first measure, open Tools/External compiler configuration, and see whether this reports changes to the path. If it does, throw all object files away, and recompile. Otherwise, please try editing the executable path manually: Tools/Options/Projects/VC++ Directories/Executable Files should start with c:\program files\vsextcompiler. Please let me know whether that works. Yes, that worked. vsextcomp complained that the PATH was not correct, but it did then repair it itself. Ok, so now I'm able to make itanium builds (which I don't want because I don't have such amachine). The Feb 2003 Platform SDK apparently doesn't have an AMD64 compiler. In the meantime, I installed a fresh copy of MSVC on a second machine (Athlon64, running Windows XP 64bit), plus the Platform SDK for Win Server 2003 SP1 - April 2005 Edition. Same problems with vsextcomp, but vsextcomp repairs the path itself again. But here, starting the build it complains: CL.EXE Wrapper for VSExtCompiler Plugin Error 2 while trying to open SDK path key from registry ... Error: Could not determine installation directory of Microsoft SDK. Guess I'll install the 2003 SP1 SDK on the first machine and try it there. Ok, the Win32 Server 2003 SP1 April 2005 SDK is installed on the first machine, the build now fails with this: -- Build started: Project: pythoncore, Configuration: ReleaseAMD64 Win32 -- Compiling resources... generate buildinfo C:\Programme\TortoiseSVN\bin\subwcrev.exe .. ..\Modules\getbuildinfo.c getbuildinfo2.c SubWCRev: 'c:\svn\trunk' Last committed at revision 43226 Updated to revision 43226 Local modifications found cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -MD -MD /USECL:MS_OPTERON getbuildinfo2.c -DSUBWCREV -Fogetbuildinfo.o -I..\Include -I..\PC getbuildinfo2.c -- CL.EXE Wrapper for VSExtCompiler Plugin -- Linking... Creating library .\./python25.lib and object .\./python25.exp zipimport.obj : error LNK2001: unresolved external symbol __security_cookie traceback.obj : error LNK2001: unresolved external symbol __security_cookie typeobject.obj : error LNK2001: unresolved external symbol __security_cookie unicodeobject.obj : error LNK2001: unresolved external symbol __security_cookie (lots of similar errors...) gzio.obj : error LNK2001: unresolved external symbol __security_check_cookie inftrees.obj : error LNK2001: unresolved external symbol __security_check_cookie trees.obj : error LNK2001: unresolved external symbol __security_check_cookie _codecs_cn.obj : error LNK2001: unresolved external symbol __security_check_cookie ./python25.dll : fatal error LNK1120: 2 unresolved externals -- LINK.EXE Wrapper for VSExtCompiler Plugin -- Build log was saved at file://c:\svn\trunk\PCbuild\amd64-temp-release\pythoncore\BuildLog.htm pythoncore - 107 error(s), 0 warning(s) -- Done -- Build: 2 succeeded, 1 failed, 0 skipped Is there a library missing? BTW: When this eventually builds, will this run on an Athlon64, or does it need an Opteron processor? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building Python for AMD64 (Windows)
Trent Mick wrote: [Thomas Heller wrote] Linking... Creating library .\./python25.lib and object .\./python25.exp zipimport.obj : error LNK2001: unresolved external symbol __security_cookie traceback.obj : error LNK2001: unresolved external symbol __security_cookie typeobject.obj : error LNK2001: unresolved external symbol __security_cookie unicodeobject.obj : error LNK2001: unresolved external symbol __security_cookie (lots of similar errors...) I have this patch to the python 2.4 sources to get win64-ia64 to build (that I haven't yet had the chance to submit to SF). I think it will require a little massaging for the trunk. Does this work for you? Yes, I was able to compile pythoncore when I added bufferoverflowU.lib to the project. However, starting python.exe immediately crashes with an access violation, in sys_getwindowsversion, in the PyBuild_Value() call. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Libref sections to put new modules under?
Fred L. Drake, Jr. wrote: On Monday 27 March 2006 16:26, Phillip J. Eby wrote: Any thoughts on where documentation for the new contextlib module should go in the library reference? Most definately in Python Runtime Services. A similar issue exists for ctypes module, although I imagine an argument could easily be made for putting it with Optional Operating System Services. I'm less sure of that one. It could reasonably go in Python Runtime Services, Generic Operating System Services, or Optional Operating System Services. I had the same thought as Philip. For a preview of what it could look like, see http://starship.python.net/crew/theller/python-docs/html/lib/ , especially http://starship.python.net/crew/theller/python-docs/html/lib/module-ctypes.html . Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error msgs for new-style division
Georg Brandl wrote: Hi, (this makes test_ctypes fail, therefore I noticed) currently with -Qnew: 2/0 Traceback (most recent call last): File stdin, line 1, in ? ZeroDivisionError: float division 2L/0 Traceback (most recent call last): File stdin, line 1, in ? ZeroDivisionError: long division or modulo by zero 2/0L Traceback (most recent call last): File stdin, line 1, in ? ZeroDivisionError: long division or modulo by zero I'll fix that in the ctypes tests. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
Gregory P. Smith wrote: On Sat, Mar 11, 2006 at 07:08:14PM +0100, Thomas Heller wrote: Martin v. L?wis wrote: Josiah Carlson told me had has given up getting a Windows buildbot running, because every time he installed VS.NET on his machine, the installation would immediately crash. So if anybody wants to contribute both a machine and time to operate it (including the likely very tedious phase to get any results out of this at all), please contact me. This is an ideal job for VMWare on an existing linux build machine if someone can ante up a win xp and msvc++ license to the cause. A vmware license for the build host probably isn't even necessary assuming vmware player works and one of us with a license can setup the vmware image (http://www.vmware.com/products/player/). (theres also a chance we could get vmware inc. to donate a license to python if one was needed) Right. I have setup 64-bit Ubuntu on a new Athon64 machine, created WinXP and WinXP64 empty virtual machines with VMWare workstation, then installed XP and XP64 into these images. The images run on the Ubuntu machine in VMWare player. I don't think we need more x86 or x86-64 buildbots, so I made no attempt to install the buildbots. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64
Martin v. Löwis wrote: I have now produces a snapshot of a Win64 build for AMD64 processors (also known as EM64T or x64); this is different from IA-64 (which is also known as Itanium)... Anyway, the binaries are http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13199.amd64.msi This is from today's trunk. If you have general remarks/discussion, please post to python-dev. If you have specific bug reports, file them on SF. Bug fixes are particularly welcome. Is this no longer available? BTW: When I build Python for ReleaseAMD64 myself, the exe crashes at the first Py_BuildValue call. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] alpha problems -- need input
Neal Norwitz wrote: These issues are on HEAD. There might be some others I missed. With cc there are at least 2 issues: * test_file causes interpreter exit due to sys.stdin.seek(-1) * test_pty fails apparently due to whitespace differences http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/18/step-test/0 Should we skip the test for an invalid seek on stdin on osf1? I haven't investigated the test_pty failure further. With gcc, there are also several issues: * test_float and test_struct fail due to NaN handling * test_long fails * test_ctypes ... test_ctypes fails because _findLib() doesn't seem to work properly on OSF1. Note: libc.so = /usr/shlib/libc.so ERROR: test_find (ctypes.test.test_loading.LoaderTest) -- Traceback (most recent call last): File /net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/test/test_loading.py, line 40, in test_find cdll.find(name) File /net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/_loader.py, line 205, in find raise OSError(Library %r not found % name) OSError: Library 'c' not found The ctypes findLib stuff for 'os.name == posix' was written by Andreas Degert, he used fancy calls to gcc, /sbin/ldconfig, and objdump to find the shared lib that would be used for the linker's -llibname flag. Apparently this only works on *some* systems. On OSX, Bob Ippolito's macholib is used. If someone could implement this for other systems it would be great, otherwise it would probably be best to enable this test only on linux . Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64
Martin v. Löwis wrote: Thomas Heller wrote: Is this no longer available? Sorry, I just deleted that. I now replaced it with python-2.5.13231.amd64.msi Thanks, I'll try that. BTW: When I build Python for ReleaseAMD64 myself, the exe crashes at the first Py_BuildValue call. That doesn't happen for me... can you find out why it crashes? (and what is the buildvalue call it crashes on)? In sys_getwindowsversion: return Py_BuildValue(s, ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion); The crash disappears if I change the first parameter in the Py_BuildValue call to s. No idea why. With this change, I can start the exe without a crash, but sys.versioninfo starts with (IIRC) (2, 0, 5,...). Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64
Martin v. Löwis wrote: Thomas Heller wrote: In sys_getwindowsversion: return Py_BuildValue(s, ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion); The crash disappears if I change the first parameter in the Py_BuildValue call to s. No idea why. With this change, I can start the exe without a crash, but sys.versioninfo starts with (IIRC) (2, 0, 5,...). Very strange. What is your compiler version (first line of cl /?)? 'H' isn't exactly right, since these are DWORDs, so they are unsigned longs, not unsigned ints (so 'k' should be right), however, the actually bug apparently is elsewhere - something like memory corruption. Can you find out what the value of szCSDVersion is (e.g. by putting a printf right before that)? I would prefer to examine this further when I'm able to compile Python on the AMD64 machine. Currently I'm not, because the VSExtCompiler Plugin cannot determine the SDK path from the registry. This is vsextcomp 0.6. I have installed the 2003 Server SP1 SDK. I tried installing the Feb 2003 SDK (since that did work on a 32-bit machine), but this won't install on XP-64. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming sqlite3
Martin v. Löwis wrote: I just tried creating a pysqlite VS project, and ran into a naming conflict: the Windows DLL is called sqlite3.dll. So if it is on sys.path import sqlite3 might find the DLL, instead of finding the package. Python then finds that there is no entry point in sqlite3, and raises an ImportError. I see three options: 1. rename sqlite3 again 2. link sqlite3 statically into _sqlite3.pyd 3. stop treating .DLL files as extension modules I'm actually leaning towards option 3: what is the rationale for allowing Python extension modules to be named .DLL? Don't know. But if you make the change to implement option 3, IMO it would be a good idea to add the Python version number to the .pyd basename as well. pywin32 already has to do this, since pythoncomXY.pyd and pywintypesXY.pyd have to live (if possible) in the windows directory. There have been other conflicts reported before: I remember Windows\system32\wmi.dll conflicting with Tim Golden's wmi.py module. In addition, wmi.dll is very special, since it doesn't have an import table, IIRC. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Renaming sqlite3
Martin v. Löwis wrote: Thomas Heller wrote: But if you make the change to implement option 3, IMO it would be a good idea to add the Python version number to the .pyd basename as well. Can you please elaborate? In the name of what .pyd file do you want the Python version number? And why? Since on Windows binary extensions have to be compiled for the exact major version of Python, it seems logical (to me, at least), to include that version number into the filename. Say, _socket25.pyd. And why is that related to not supporting extensions with .DLL names anymore? IMO changing that would require a PEP (but I may be wrong), and this is only another idea which should be considered when writing or discussing that. If you don't like the idea, or don't see any advantages in this, I retract the request. pywin32 already has to do this, since pythoncomXY.pyd and pywintypesXY.pyd have to live (if possible) in the windows directory. I think this is a very special case: it could have been implemented with separate DLLs which just provide the COM entry points, and find the location of pythoncom.pyd from the registry. I would discourage people from providing additional entry points to an extension module. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
