Mailman 3 February 2005 - Python-Dev

Re: [Python-Dev] Is msvcr71.dll re-redistributable?
by Anders J. Munch 03 Feb '05

03 Feb '05

>From Tony Meyer [mailto:t-meyer@ihug.co.nz]: > Can anyone here suggest a way to get around this? As a specific > example: the SpamBayes distribution includes a py2exe binary, and it > would be nice (although not essential) to build this with 2.4. > However, at the moment my name goes down as the release manager, and > I don't have (AFAICT) a licence to redistribute msvcr71.dl. Instead of redistributing msvcr71.dll on your own volition, help someone else distribute it: 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. 2. You, being the nice person you are, decide to help John X. Programmer. You do that by including msvcr71.dll in your software distribution. After all, the users of your software needs it. As you are merely aiding John X. Programmer in performing the redistribution that is within his rights to do, there is no need for anyone to be granted any additional rights, and specifically you do not need to agree to the EULA. Unless the EULA contains specific language to forbid such multi-stage open-ended redistribution, I'd say you can just re-redistribute away. but-then-I-am-not-a-lawyer-ly y'rs, Anders

5 4

RE: [Python-Dev] Is msvcr71.dll re-redistributable?
by Tony Meyer 02 Feb '05

02 Feb '05

[Thanks for bringing this up, BTW, Thomas]. [Thomas Heller] >> 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? [Vincent Wehren] > According to the EULA, Is that the EULA of MS VC++? > you may distribute anything listed in redist.txt: And, just to be clear, mscvr71.dll is in redist.txt? > """2.2 Redistributable Code-General. Microsoft grants you a > nonexclusive, royalty-free right to reproduce and distribute > the object code form of any portion of the Software listed in > REDIST.TXT ("Redistributable Code"). For general redistribution > requirements for Redistributable Code, see Section 3.1, below.""" Is it legit to redistribute an EULA? If so, would you mind sending me a copy of this (off-list)? > So the right to distribute is coupled to the a) the EULA and b) > redist.txt. (As a side note, the Microsoft Visual C++ Toolkit > 2003 for example contains NO redistributables per redist.txt). I'm not that familiar with the names of all these things. Is the "Microsoft Visual C++ Toolkit 2003" the free thing that you can get? > In the case of not owning a compiler at all, chances seem pretty slim > you have any rights to distribute anything. Well, I 'own' a copy of gcc, which is a compiler <wink>. Can anyone here suggest a way to get around this? As a specific example: the SpamBayes distribution includes a py2exe binary, and it would be nice (although not essential) to build this with 2.4. However, at the moment my name goes down as the release manager, and I don't have (AFAICT) a licence to redistribute msvcr71.dl. Should people in this situation just stick with 2.3 or buy a copy of a MS compiler? =Tony.Meyer

2 1

mimetypes and _winreg
by Mike Brown 02 Feb '05

02 Feb '05

I thought it would be nice to try to improve the mimetypes module by having it, on Windows, query the Registry to get the mapping of filename extensions to media types, since the mimetypes code currently just blindly checks posix-specific paths for httpd-style mapping files. However, it seems that the way to get mappings from the Windows registry is excessively slow in Python. I'm told that the reason has to do with the limited subset of APIs that are exposed in the _winreg module. I think it is that EnumKey(key, index) is querying for the entire list of subkeys for the given key every time you call it. Or something. Whatever the situation is, the code I tried below is way slower than I think it ought to be. Does anyone have any suggestions (besides "write it in C")? Could _winreg possibly be improved to provide an iterator or better interface to get the subkeys? (or certain ones? There are a lot of keys under HKEY_CLASSES_ROOT, and I only need the ones that start with a period). Should I file this as a feature request? Thanks -Mike from _winreg import HKEY_CLASSES_ROOT, OpenKey, EnumKey, QueryValueEx i = 0 typemap = {} try: while 1: subkeyname = EnumKey(HKEY_CLASSES_ROOT, i) try: subkey = OpenKey(HKEY_CLASSES_ROOT, subkeyname) if subkeyname[:1] == '.': data = QueryValueEx(subkey, 'Content Type')[0] print subkeyname, '=', data typemap[subkeyname] = data # data will be unicode except EnvironmentError, WindowsError: pass i += 1 except WindowsError: pass

3 4

python-dev Summary for 2004-12-16 through 2004-12-31 [draft]
by Brett C. 02 Feb '05

02 Feb '05

Nice and short summary this time. Plan to send this off Wednesday or Thursday so get corrections in before then. ------------------------------ ===================== Summary Announcements ===================== You can still `register <http://www.python.org/pycon/2005/register.html>`__ for `PyCon`_. The `schedule of talks`_ is now online. Jim Hugunin is lined up to be the keynote speaker on the first day with Guido being the keynote on Thursday. Once again PyCon looks like it is going to be great. On a different note, as I am sure you are all aware I am still about a month behind in summaries. School this quarter for me has just turned out hectic. I think it is lack of motivation thanks to having finished my 14 doctoral applications just a little over a week ago (and no, that number is not a typo). I am going to for the first time in my life come up with a very regimented study schedule that will hopefully allow me to fit in weekly Python time so as to allow me to catch up on summaries. And this summary is not short because I wanted to finish it. 2.5 was released just before the time this summary covers so most stuff was on bug fixes discovered after the release. .. _PyCon: http://www.pycon.org/ .. _schedule of talks: http://www.python.org/pycon/2005/schedule.html ======= Summary ======= ------------- PEP movements ------------- I introduced a `proto-PEP <http://mail.python.org/pipermail/python-dev/2005-January/050753.html>`__ to the list on how one can go about changing CPython's bytecode. It will need rewriting once the AST branch is merged into HEAD on CVS. Plus I need to get a PEP number assigned to me. =) Contributing threads: - ` proto-pep: How to change Python's bytecode <>`__ ------------------------------------ Handling versioning within a package ------------------------------------ The suggestion of extending import syntax to support explicit version importation came up. The idea was to have something along the lines of ``import foo version 2, 4`` so that one can have packages that contain different versions of itself and to provide an easy way to specify which version was desired. The idea didn't fly, though. The main objection was that import-as support was all you really needed; ``import foo_2_4 as foo``. And if you had a ton of references to a specific package and didn't want to burden yourself with explicit imports, one can always have a single place before codes starts executing doing ``import foo_2_4; sys.modules["foo"] = foo_2_4``. And that itself can even be lower by creating a foo.py file that does the above for you. You can also look at how wxPython handles it at http://wiki.wxpython.org/index.cgi/MultiVersionInstalls . Contributing threads: - `Re: [Pythonmac-SIG] The versioning question... <>`__ =============== Skipped Threads =============== - Problems compiling Python 2.3.3 on Solaris 10 with gcc 3.4.1 - 2.4 news reaches interesting places see `last summary`_ for coverage of this thread - RE: [Python-checkins] python/dist/src/Modules posixmodule.c, 2.300.8.10, 2.300.8.11 - mmap feature or bug? - Re: [Python-checkins] python/dist/src/Pythonmarshal.c, 1.79, 1.80 - Latex problem when trying to build documentation - Patches: 1 for the price of 10. - Python for Series 60 released - Website documentation - link to descriptor information - Build extensions for windows python 2.4 what are the compiler rules? - Re: [Python-checkins] python/dist/src setup.py, 1.208, 1.209 - Zipfile needs? fake 32-bit unsigned int overflow with ``x = x & 0xFFFFFFFFL`` and signed ints with the additional ``if x & 0x80000000L: x -= 0x100000000L`` . - Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2

2 2

RE: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up functioncalls)
by Michael Chermside 02 Feb '05

02 Feb '05

Evan Jones writes: > My knowledge about garbage collection is weak, but I have read a little > bit of Hans Boehm's work on garbage collection. [...] The biggest > disadvantage mentioned is that simple pointer assignments end up > becoming "increment ref count" operations as well... Hans Boehm certainly has some excellent points. I believe a little searching through the Python dev archives will reveal that attempts have been made in the past to use his GC tools with CPython, and that the results have been disapointing. That may be because other parts of CPython are optimized for reference counting, or it may be just because this stuff is so bloody difficult! However, remember that changing away from reference counting is a change to the semantics of CPython. Right now, people can (and often do) assume that objects which don't participate in a reference loop are collected as soon as they go out of scope. They write code that depends on this... idioms like: >>> text_of_file = open(file_name, 'r').read() Perhaps such idioms aren't a good practice (they'd fail in Jython or in IronPython), but they ARE common. So we shouldn't stop using reference counting unless we can demonstrate that the alternative is clearly better. Of course, we'd also need to devise a way for extensions to cooperate (which is a problem Jython, at least, doesn't face). So it's NOT an obvious call, and so far numerous attempts to review other GC strategies have failed. I wouldn't be so quick to dismiss reference counting. > My only argument for making Python capable of leveraging multiple > processor environments is that multithreading seems to be where the big > performance increases will be in the next few years. I am currently > using Python for some relatively large simulations, so performance is > important to me. CPython CAN leverage such environments, and it IS used that way. However, this requires using multiple Python processes and inter-process communication of some sort (there are lots of choices, take your pick). It's a technique which is more trouble for the programmer, but in my experience usually has less likelihood of containing subtle parallel processing bugs. Sure, it'd be great if Python threads could make use of separate CPUs, but if the cost of that were that Python dictionaries performed as poorly as a Java HashTable or synchronized HashMap, then it wouldn't be worth the cost. There's a reason why Java moved away from HashTable (the threadsafe data structure) to HashMap (not threadsafe). Perhaps the REAL solution is just a really good IPC library that makes it easier to write programs that launch "threads" as separate processes and communicate with them. No change to the internals, just a new library to encourage people to use the technique that already works. -- Michael Chermside

4 3

complex I/O problem
by Neal Becker 01 Feb '05

01 Feb '05

If I call "print" on a complex value, I may get this: '(2+2j)' But this is not acceptable as input: complex ('(2+2j)') Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: complex() arg is a malformed string Whatever format is used for output should be accepted as input!

4 3

Python reference count question
by cedric paille 01 Feb '05

01 Feb '05

Hi all, i'm working on an app that embed python 2.3 with Gnu/Linux, and i'd like to have some precisions: I'm making python's modules to extend my application's functions with a built in script editor. At now all works very well, but i'd like to know if i'm not forgetting some references inc/dec.... Here is a portion of my code: static PyObject * Scene_GetNodeGraph(PyObject *self, PyObject *args) { NodeGraph* Ng = NodeGraph::GetInstance(); std::vector<String> NodG; Ng->GetNodeGraph(NodG); PyObject* List = PyList_New(NodG.size()); PyObject* Str = NULL; std::vector<String>::iterator it = NodG.begin(); int i = 0; for (;it != NodG.end();it++) { Str = PyString_FromString(it->AsChar()); PyList_SetItem(List,i,Str); i++; } return List; } Can someone take a look at this and tell me if i must add some inc/decref ? Thanks.

2 1

Database import problems
by Steve Holden 01 Feb '05

01 Feb '05

I wonder if there is a developer with MySQL or sqlite and the appropriate Python interface module who can help me to understand a problem I'm experiencing trying to use PEP 302-style import hooks. Basically I suspect we've either got an import bug or (more likely IMHO) a documentation bug, but I don't want to file on sf until I know exactly what the problem is, and I'm reluctant to use too much bandwidth on python-dev, which I know to be a busy list. The background is visible in the Python-list archives starting at http://mail.python.org/pipermail/python-list/2005-January/262148.html Of course it's possible that a savvy developer can just tell me what the problem is by reading that thread. If not, being a bear of little brain I need help from someone who is used to running debugging interpreters and can see exactly what's going on - my debugging system is fine for Python source, but has no insight into the interpreter code itself. Since I'm not currently subscribed to python-dev an email response (or, better, a follow-up on the c.l.py thread) would be appreciated if you can solve this problem. I'm happy to send full code off-list (or on-list, come to that) to anybody who can assist. regards Steve -- Meet the Python developers and your c.l.py favorites Come to PyCon!!!! http://www.python.org/pycon/2005/ Steve Holden http://www.holdenweb.com/

2 1

RE: [Python-Dev] Speed up function calls
by Raymond Hettinger 01 Feb '05

01 Feb '05

> > In theory, I don't see how you could improve on METH_O and METH_NOARGS. > > The only saving is the time for the flag test (a predictable branch). > > Offsetting that savings is the additional time for checking min/max args > > and for constructing a C call with the appropriate number of args. I > > suspect there is no savings here and that the timings will get worse. > > I think tested a method I changed from METH_O to METH_ARGS and could > not measure a difference. Something is probably wrong with the measurements. The new call does much more work than METH_O or METH_NOARGS. Those two common and essential cases cannot be faster and are likely slower on at least some compilers and some machines. If some timing shows differently, then it is likely a mirage (falling into an unsustainable local minimum). The patch introduces range checks, an extra C function call, nine variable initializations, and two additional unpredictable branches (the case statements). The only benefit (in terms of timing) is possibly saving a tuple allocation/deallocation. That benefit only kicks in for METH_VARARGS and even then only when the tuple free list is empty. I recommend not changing ANY of the METH_O and METH_NOARGS calls. These are already close to optimal. > A beneift would be to consolidate METH_O, > METH_NOARGS, and METH_VARARGS into a single case. This should > make code simpler all around (IMO). Will backwards compatibility allow those cases to be eliminated? It would be a bummer if most existing extensions could not compile with Py2.5. Also, METH_VARARGS will likely have to hang around unless a way can be found to handle more than nine arguments. This patch appears to be taking on a life of its own and is being applied more broadly than is necessary or wise. The patch is extensive and introduces a new C API that cannot be taken back later, so we ought to be careful with it. For the time being, try not to touch the existing METH_O and METH_NOARGS methods. Focus on situations that do stand a chance of being improved (such as methods with a signature like "O|O"). That being said, I really like the concept. I just worry that many of the stated benefits won't materialize: * having to keep the old versions for backwards compatibility, * being slower than METH_O and METH_NOARGS, * not handling more than nine arguments, * separating function signature info from the function itself, * the time to initialize all the argument variables to NULL, * somewhat unattractive case stmt code for building the c function call. Raymond

17 22