Re: [Python-Dev] Re: No new features
Donovan Baarda [EMAIL PROTECTED] writes: G'day again, [...] You missed the minor releases bit in my post. major releases, ie 2.x - 3.0, are for things that can break existing code. They change the API so that things that run on 2.x may not work with 3.x. minor releases, ie 2.2.x -2.3.0, are for things that cannot break existing code. They can extend the API such that code for 2.3.x may not work on 2.2.x, but code that runs on 2.2.x must work on 2.3.x. micro releases, ie 2.2.1 -2.2.2, are for bug fixes only. There can be no changes to the API, so that all code that runs on 2.2.2 should work with 2.2.1, barring the bugs fixed. The example you cited of adding bool was an extension to the API, and hence should have been a minor release, not a micro release. I just read the PEP-6, and it doesn't seem to use this terminology, or make this distinction... does something else do this anywhere? I thought this approach was common knowledge... I see. You were proposing a much larger change to the way Python releases work than I (and perhaps you? :) realised. Not breaking any code 2.x to 2.x+1 is a nice idea, but doesn't really seem feasible in practice. Cheers, mwh -- nonono, while we're making wild conjectures about the behavior of completely irrelevant tasks, we must not also make serious mistakes, or the data might suddenly become statistically valid. -- Erik Naggum, comp.lang.lisp ___ 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] LinkedHashSet/LinkedHashMap equivalents
Delaney, Timothy C (Timothy) [EMAIL PROTECTED] writes: Set: Items are iterated over in the order that they are added. Adding an item that compares equal to one that is already in the set does not replace the item already in the set, and does not change the iteration order. Removing an item, then re-adding it moves the item to the end of the iteration order. Well, this could be satisfied by an append_new operation on lists, right (thinking of Common Lisps #'cl:pushnew)? Complexity not that great, of course, but I've written code like: if a not in l: l.append(a) and not suffered that badly for it before now... Dict: Keys are iterated over in the order that they are added. Setting a value using a key that compares equal to one already in the dict replaces the value, but not the key, and does not change the iteration order. Removing a key (and value) then re-adding it moves the key to the end of the iteration order. And these are what CL types call association lists, in effect. Cheers, mwh -- #ifndef P_tmpdir printf( Go buy a better computer ); exit( ETHESKYISFALLINGANDIWANTMYMAMA ); -- Dimitri Maziuk on writing secure code, asr ___ 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] Decimal returning NotImplemented (or not)
Nick Coghlan wrote: Guido van Rossum wrote: No, the reason is that if we did this with exceptions, it would be liable to mask errors; an exception does not necessarily originate immediately with the code you invoked, it could have been raised by something else that was invoked by that code. The special value NotImplemented must pretty much originate directly in the invoked code, since the implementation guarantees that e.g. a+b can never *return* NotImplemented: if a.__add__(b) and b.__radd__(a) both return NotImplemented, TypeError is raised. That makes sense - although for that reasoning, a TypeError subclass that the binary operation machinery promotes to a standard TypeError would seem to work too (with the advantage of also raising at least some sort of exception when the method is called directly) I have to correct Guido's explanation a bit: the original reason for using a special singleton instead of an exception was indeed a significant difference in performance (raising exceptions at the Python level is expensive, not so much at the C level). I don't remember the details, but I did some measurements at the time which made the decision to use a singleton rather easy :-) The NotImplemented singleton was part of the coercion proposal: http://www.egenix.com/files/python/CoercionProposal.html (pretty old stuff, now that I look at it again ;-) That said, Guido's point is just valid. We would have had to add code that saves the current exception to avoid masking any pending errors - code like that always turns into a mess sooner or later. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 10 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] itemgetter/attrgetter extension
Raymond Hettinger wrote:
Any objections to extending itemgetter() and attrgetter() to be able to
extract multiple fields at a time?
# SELECT name, rank, serialnum FROM soldierdata
map(attrgetter('name', 'rank', 'serialnum'), soldierdata)
# SELECT * FROM soldierdata ORDER BY unit, rank, proficiency
sorted(soldierdata, key=attrgetter('unit', 'rank', 'proficiency'))
Breaking the symmetry with getattr() bothers me a little, as does the signature
change that occurs when multiple arguments are given (returning a tuple, whereas
the single argument returns just the retrieved attribute).
For itemgetter, I'd like to see multiple arguments eventually map to
multi-dimensional slices (to preserve symmetry with indexing syntax).
Call it -1 for itemgetter and -0 for attrgetter.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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] LinkedHashSet/LinkedHashMap equivalents
Delaney, Timothy C (Timothy) wrote: OTOH, ordered set and ordered dict implies different things to different people - usually sorted rather than the order things were put in. Perhaps temporally-ordered ;) OTGH*, I would expect an OrderedDict / OrderedSet to have 'add to the end' semantics, but also provide a 'sort()' method so that the ordering could be changed at a later date. IOW, by default the ordering is temporal. Sorting the ordered dict/set changes the iteration order for the current contents. Further additions are still added in temporal order until such time as the dict/set is sorted again. The parallels are to using list.append() to build a list, and list.sort() to order the current contents (in fact, a simplistic approach could use that exact technique to remember the order of keys, at the cost of doubling key storage requirements). Cheers, Nick. *OTGH: On the gripping hand :) -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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] LinkedHashSet/LinkedHashMap equivalents
On Wed, 2005-03-09 at 19:39, Tommy Burnette wrote: I'd say I'm +0. fwiw- I've been using a locally-rolled OrderedDict implementation for the last 5-6 years in which insertion order is the only order respected. I use it all over the place (in a code base of ~60k lines of python code). so there's another use case for you. bust as you say, easy to do yourself... I'm -0 on adding it to the stdlib, but mostly because I don't like the name, and I suspect it's going to be one of those nuggets lurking in the standard library that few people will use, tending either to overlook it or just roll their own anyway because the standard one doesn't have quite the right semantics. FWIW, email.Message.Message /exposes/ an ordered dictionary-like interface even though it's implemented as a simple list. It was considered at the time that the number of headers in an email message wouldn't be so large that anything else would be worth the complexity. I think that still holds, for the original uses cases at least. -Barry signature.asc Description: This is a digitally signed message part ___ 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] LinkedHashSet/LinkedHashMap equivalents
I would LOVE for **kwargs to be an ordered dict. It would allow me to write code like this: .class MyTuple: .def __init__(self, **kwargs): .self.__dict__ = ordereddict(kwargs) . .def __iter__(self): .for k, v in self.__dict__.items(): .yield v . .t = MyTuple(r = 99, g = 12, b = 4) .r, g, b = t .print r, g, b I know it goes beyond the original intention of the proposal, but I figure I'd mention it anyway because the unorder of **kwargs has been bugging me alot. -- mvh Björn ___ 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] LinkedHashSet/LinkedHashMap equivalents
On Thursday 10 March 2005 17:29, Raymond Hettinger wrote: Or the implementation can have a switch to choose between keep-first logic or replace logic. The latter seems a bit odd to me. The key position would be determined by the first encountered while the value would be determined by the last encountered. Starting with [(10, v1), (20, v2), (10.0, v3)], the ordered dictionary's items would look like [(10, v3), (20, v2)]. Or, alternately, we keep the last occurence, and move it to the new position. There's a wide number of different use cases, each with a slightly different final result, and for this reason alone I'm -0 on it for the library. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] LinkedHashSet/LinkedHashMap equivalents
[BJörn Lindqvist] I would LOVE for **kwargs to be an ordered dict. It would allow me to write code like this: .class MyTuple: .def __init__(self, **kwargs): .self.__dict__ = ordereddict(kwargs) This doesn't work. The kwargs are already turned into a regular dictionary before ordereddict sees it. Raymond Hettinger ___ 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] SWT PyCon Sprint?
At 01:38 AM 3/10/05 -0500, Nicholas Bastin wrote: I realize that this is exceedingly late in the game, but is anybody interested in doing a Write-Python-Bindings-for-SWT sprint? It's been brought up before in various places, and PyCon seems the likely place to get enough concentrated knowledge to actually get it kicked off and somewhat working... I'm certainly interested in the concept in general, though I'm curious whether the planned approach is a GCJ/SWIG wrapper, or a javaclass (bytecode translation)+ctypes dynamic approach. I'm somewhat more interested in the latter approach, as I find C++ a bit of a pain with respect to buildability. An additional complication is that SWT is a different package on each platform, so it's not so much port SWT to Python as port SWT-windows to Python, port SWT-Mac to Python, etc. (I assume that you're talking about porting to a JVM-less CPython extension, since if you were to leave it in Java you could just use Jython or one of the binary Python-Java bridges to access SWT as-is.) ___ 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] Can't build Zope on Windows w/ 2.4.1c1
I don't know how far I'll get with this. Using the current Zope-2_7-branch of the Zope module at cvs.zope.org:/cvs-repository, building Zope via python setup.py build_ext -i worked fine when I got up today, using the released Python 2.4. One of its tests fails, because of a Python bug that should be fixed in 2.4.1. So I wanted to test that. After uninstalling 2.4, then installing 2.4.1c1, then deleting Zope's lib\python\build directory, the attempt to build Zope works fine for quite a while (successfully compiles many chunks of Zope C code), but dies here: ... building 'ZODB.cPickleCache' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -IC:\Code\Zope-2_7-branch\lib\Components\ExtensionClass\src -IC:\python24\include -IC:\python24\PC /TcZODB/cPickleCache.c /Fobuild\temp.win32-2.4 \Release\ZODB/cPickleCache.obj cPickleCache.c error: No such file or directory I don't know which file it's complaining about. In contrast, output I saved from building Zope with 2.4 this morning appears identical up to this point: ... building 'ZODB.cPickleCache' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -IC:\Code\Zope-2_7-branch\lib\Components\ExtensionClass\src -IC:\python24\include -IC:\python24\PC /TcZODB/cPickleCache.c /Fobuild\temp.win32-2.4 \Release\ZODB/cPickleCache.obj cPickleCache.c but then, instead of an error, it goes on to link (and build more C stuff): C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\python24\libs /LIBPATH:C:\python24\PCBuild /EXPORT:initcPickleCache build\temp.win32-2.4\Release\ZODB/cPickleCache.obj /OUT:ZODB\cPickleCache.pyd /IMPLIB:build\temp.win32-2.4\Release\ZODB\cPickleCache.lib Creating library build\temp.win32-2.4\Release\ZODB\cPickleCache.lib and object build\temp.win32-2.4\Release\ZODB\cPickleCache.exp building 'ZODB.TimeStamp' extension Gets stranger: cPickleCache.c is really part of ZODB, and python setup.py build continues to work fine with 2.4.1c1 from a ZODB3 checkout (and using the same branch tag as was used for Zope). Anyone change anything here for 2.4.1 that rings a bell? Can anyone confirm that they can or can't build current Zope 2.7 on Windows with 2.4.1c1 too? If it's not unique to my box, is it unique to Windows (e.g., can anyone build current Zope on Linux with 2.4.1c1)? ___ 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] Can't build Zope on Windows w/ 2.4.1c1
It works on Linux, with Zope 2.7.4. Just as a note to others (I've mentioned this to Tim already) if you set an environment variable DISTUTILS_DEBUG before running a setup.py, you get very verbose information about what's going on, and, more importantly, full tracebacks rather than terse error messages. error: No such file or directory looks like a distutils error message. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] Can't build Zope on Windows w/ 2.4.1c1
[Anthony Baxter] It works on Linux, with Zope 2.7.4. Thanks! Just as a note to others (I've mentioned this to Tim already) if you set an environment variable DISTUTILS_DEBUG before running a setup.py, you get very verbose information about what's going on, and, more importantly, full tracebacks rather than terse error messages. error: No such file or directory looks like a distutils error message. This helped a lot, although I'm even more confused now: building 'ZODB.cPickleCache' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -IC:\Code\Zope-2_7-branch\lib\Components\ExtensionClass\src -IC:\python24\include -IC:\python24\PC /TcZODB/cPickleCache.c /Fobuild\temp.win32-2.4\Release\ZODB/cPickleCache.obj cPickleCache.c error: No such file or directory Traceback (most recent call last): File C:\Code\Zope-2_7-branch\setup.py, line 1094, in ? distclass=ZopeDistribution, File C:\python24\lib\distutils\core.py, line 149, in setup dist.run_commands() File C:\python24\lib\distutils\dist.py, line 946, in run_commands self.run_command(cmd) File C:\python24\lib\distutils\dist.py, line 966, in run_command cmd_obj.run() File C:\python24\lib\distutils\command\build_ext.py, line 279, in run self.build_extensions() File C:\python24\lib\distutils\command\build_ext.py, line 405, in build_extensions self.build_extension(ext) File C:\python24\lib\distutils\command\build_ext.py, line 502, in build_extension target_lang=language) File C:\python24\lib\distutils\ccompiler.py, line 847, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File C:\python24\lib\distutils\msvccompiler.py, line 422, in link if not self.initialized: self.initialize() File C:\python24\lib\distutils\msvccompiler.py, line 239, in initialize os.environ['path'] = string.join(self.__paths, ';') File C:\python24\lib\os.py, line 419, in __setitem__ putenv(key, item) OSError: [Errno 2] No such file or directory LOL -- or something wink. Before going to sleep, Anthony suggested that Bug #1110478: Revert os.environ.update to do putenv again. might be relevant. HTF can we get a no such file or directly out of a putenv()?! Don't be shy. ___ 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] Can't build Zope on Windows w/ 2.4.1c1
This is going to need someone who understands distutils internals.
The strings we end up passing to putenv() grow absurdly large, and
sooner or later Windows gets very unhappy with them.
os.py has a
elif name in ('os2', 'nt'): # Where Env Var Names Must Be UPPERCASE
class controlling introduction of a _Environ class. I changed its
__setitem__ like so:
def __setitem__(self, key, item):
if key.upper() == PATH: # new line
print len(item), len(item) # new line
putenv(key, item)
self.data[key.upper()] = item
As setup.py build_ext -i goes on while compiling Zope, this is the
output before putenv barfs:
len(item) 1025
len(item) 1680
len(item) 2335
len(item) 2990
len(item) 3645
len(item) 4300
len(item) 4955
len(item) 5610
len(item) 6265
len(item) 6920
len(item) 7575
len(item) 8230
len(item) 8885
len(item) 9540
len(item) 10195
len(item) 10850
len(item) 11505
len(item) 12160
len(item) 12815
len(item) 13470
len(item) 14125
len(item) 14780
len(item) 15435
len(item) 16090
len(item) 16745
len(item) 17400
len(item) 18055
len(item) 18710
len(item) 19365
len(item) 20020
len(item) 20675
len(item) 21330
len(item) 21985
len(item) 22640
len(item) 23295
len(item) 23950
len(item) 24605
len(item) 25260
len(item) 25915
len(item) 26570
len(item) 27225
len(item) 27880
len(item) 28535
len(item) 29190
len(item) 29845
len(item) 30500
len(item) 31155
len(item) 31810
len(item) 32465
The PATH isn't gibberish at this point -- it just keeps adding the
MSVC directories (like
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\bin
) again and again and again. I don't know what the environ limits are
on various flavors of Windows; empirically, on my Win XP Pro SP2 box,
the values have to be 32K or putenv() dies. But there's surely no
need for distutils to make PATH grow without bound, so I think this is
a distutils bug.
A workaround for building Zope is easy but embarrassing wink: kill
setup.py before it hits this error, then start it again. Lather,
rinse, repeat. After a few iterations, everything builds fine.
___
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] Can't build Zope on Windows w/ 2.4.1c1
On Thu, Mar 10, 2005 at 12:46:23PM -0500, Tim Peters wrote: This is going to need someone who understands distutils internals. The strings we end up passing to putenv() grow absurdly large, and sooner or later Windows gets very unhappy with them. In distutils.msvccompiler: def __init__ (self, verbose=0, dry_run=0, force=0): ... self.initialized = False def compile(self, sources, output_dir=None, macros=None, include_dirs=None, debug=0, extra_preargs=None, extra_postargs=None, depends=None): if not self.initialized: self.initialize() ... def initialize(self): ... does not seem to set self.initialized to True! I think the fix is to add 'self.initialized = True' to the initialize() method, but can't test it (no Windows). This fix should also go into 2.4.1-final, I expect. --amk ___ 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] Can't build Zope on Windows w/ 2.4.1c1
[ A.M. Kuchling] In distutils.msvccompiler: def __init__ (self, verbose=0, dry_run=0, force=0): ... self.initialized = False def compile(self, sources, output_dir=None, macros=None, include_dirs=None, debug=0, extra_preargs=None, extra_postargs=None, depends=None): if not self.initialized: self.initialize() ... def initialize(self): ... does not seem to set self.initialized to True! I think the fix is to add 'self.initialized = True' to the initialize() method, but can't test it (no Windows). This fix should also go into 2.4.1-final, I expect. Dunno, but sounds good. We certainly ought to fix it for 2.4.1 final, whatever the fix is. I opened a bug report: http://www.python.org/sf/1160802 ___ 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] SWT PyCon Sprint?
On Mar 10, 2005, at 11:00 AM, Phillip J. Eby wrote: At 01:38 AM 3/10/05 -0500, Nicholas Bastin wrote: I realize that this is exceedingly late in the game, but is anybody interested in doing a Write-Python-Bindings-for-SWT sprint? It's been brought up before in various places, and PyCon seems the likely place to get enough concentrated knowledge to actually get it kicked off and somewhat working... I'm certainly interested in the concept in general, though I'm curious whether the planned approach is a GCJ/SWIG wrapper, or a javaclass (bytecode translation)+ctypes dynamic approach. I'm somewhat more interested in the latter approach, as I find C++ a bit of a pain with respect to buildability. I'm open to either approach. I don't know a lot about JNI, so I was hoping somebody would come along for the ride who could answer certain questions about how SWT is implemented. A third option would be to grovel over SWT and implement an identical functionality in Python (pure-python plus ctypes), and make a mirror implementation, rather than a wrapper. What approach we take depends largely on who shows up and what they feel comfortable with. An additional complication is that SWT is a different package on each platform, so it's not so much port SWT to Python as port SWT-windows to Python, port SWT-Mac to Python, etc. The API is identical for each platform, however, so depending on the level at which you wrapped it, this is only a build problem. (I assume that you're talking about porting to a JVM-less CPython extension, since if you were to leave it in Java you could just use Jython or one of the binary Python-Java bridges to access SWT as-is.) Yes, JVM-less CPython extension would be the plan. -- Nick ___ 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] Re: Can't build Zope on Windows w/ 2.4.1c1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Peters wrote: | [Tres Seaver] | |Unit tests for Zope 2.7.4's 'zdaemon' package, which passed under Python |2.4, now fail under 2.4.1c1: | | | Are you sure they passed under 2.4? Yep. I showed output from that in the original post (and below). | Derrick Hudson changed run() to | _run() in the SVN version of zdaemon way back on Jan 19, with this | checkin comment: | | Log message for revision 28881: | Renamed run() method to _run(). Python 2.4's unittest.TestCase class | defines all of the test logic in the run() method instead of in __call__() | (as 2.3 did). The rename prevents overriding the base implementation and | causing the tests to fail. | | Changed: | U Zope3/trunk/src/zdaemon/tests/testzdrun.py | | I then ported that to where it belonged (zdaemon isn't part of Zope3 | under SVN, it's stitched in to Zope3, from time to time, from the | distinct zdaemon SVN trunk). | | I suppose that never got ported to the CVS version -- well, until | today, cuz it looks like Stefan Holek checked in the same kinds of | changes to testzdrun.py about 2.5 hours ago. Right. In fact, he beat me to the commit, and gave me a nice CVS conflict as lagniappe. | [BTW, the zdaemon tests don't run at all on Windows, so I'll never | notice anything wrong with them] | | |$ uname -a |Linux secretariat 2.6.8.1-5-686 #1 Sat Feb 12 00:50:37 UTC 2005 i686 \ |GNU/Linux |$ ../Python-2.4/python test.py -v zdaemon |Running unit tests at level 1 |Running unit tests from |/home/tseaver/projects/Zope-CVS/Zope-2.7.4/lib/python |/home/tseaver/projects/Zope-CVS/Python-2.4/Lib/whrandom.py:38: |DeprecationWarning: the whrandom module is deprecated; please use the |random module |~ DeprecationWarning) | |- -- |Ran 28 tests in 2.278s | |OK |$ ../Python-2.4.1c1/python test.py -v zdaemon |Running unit tests at level 1 |Running unit tests from |/home/tseaver/projects/Zope-CVS/Zope-2.7.4/lib/python |/home/tseaver/projects/Zope-CVS/Python-2.4.1c1/Lib/whrandom.py:38: |DeprecationWarning: the whrandom module is deprecated; please use the |random module |~ DeprecationWarning) |...Traceback (most recent call last): |~ File test.py, line 918, in ? |~process_args() |~ File test.py, line 908, in process_args |~bad = main(module_filter, test_filter, libdir) |~ File test.py, line 698, in main |~runner(files, test_filter, debug) |~ File test.py, line 599, in runner |~r = runner.run(suite) |~ File test.py, line 366, in run |~return unittest.TextTestRunner.run(self, test) |~ File /home/tseaver/projects/Zope-CVS/Python-2.4.1c1/Lib/unittest.py, |line 696, in run |~test(result) |~ File /home/tseaver/projects/Zope-CVS/Python-2.4.1c1/Lib/unittest.py, |line 428, in __call__ |~return self.run(*args, **kwds) |~ File /home/tseaver/projects/Zope-CVS/Python-2.4.1c1/Lib/unittest.py, |line 424, in run |~test(result) |~ File /home/tseaver/projects/Zope-CVS/Python-2.4.1c1/Lib/unittest.py, |line 428, in __call__ |~return self.run(*args, **kwds) |~ File /home/tseaver/projects/Zope-CVS/Python-2.4.1c1/Lib/unittest.py, |line 424, in run |~test(result) |~ File /home/tseaver/projects/Zope-CVS/Python-2.4.1c1/Lib/unittest.py, |line 428, in __call__ |~return self.run(*args, **kwds) |~ File /home/tseaver/projects/Zope-CVS/Python-2.4.1c1/Lib/unittest.py, |line 424, in run |~test(result) |~ File /home/tseaver/projects/Zope-CVS/Python-2.4.1c1/Lib/unittest.py, |line 281, in __call__ |~return self.run(*args, **kwds) |~ File |/home/tseaver/projects/Zope-CVS/Zope-2.7.4/lib/python/zdaemon/tests/testzdrun.py, |line 97, in run |~zdctl.main([-s, self.zdsock] + args) |AttributeError: 'ZDaemonTests' object has no attribute 'zdsock' | |By staring at the code of the failing test, it looks like the MRO of the |testcase class has changed: it declares a 'run' method, which is |supposed to run the external process, which clashes with the 'run' |method of unittest.TestCase. I don't know what change in the 2.4 - |2.4.1c1 update would have mucked with the MRO (if a MRO issue is involved). | |Tres. | | | Pretty baffling. I assume that if you did cvs up, the test would | pass now (because of Stefan's recent checkin). | | Sounds anyway like an unintended unittest incompatibility snuck in | somewhere between 2.3 and 2.4. I think somebody tweaked either the base classes of unittest.TestCase or else the MRO algoritm (if it *is* algorithmic, that is ;) Tres. - -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCMLekGqWXf00rNCgRAofeAJ9nEbAMmklXhH3BpRzihinTVFuiiQCfZA2q
Re: [Python-Dev] SWT PyCon Sprint?
At 04:06 PM 3/10/05 -0500, Nicholas Bastin wrote: On Mar 10, 2005, at 11:00 AM, Phillip J. Eby wrote: At 01:38 AM 3/10/05 -0500, Nicholas Bastin wrote: I realize that this is exceedingly late in the game, but is anybody interested in doing a Write-Python-Bindings-for-SWT sprint? It's been brought up before in various places, and PyCon seems the likely place to get enough concentrated knowledge to actually get it kicked off and somewhat working... I'm certainly interested in the concept in general, though I'm curious whether the planned approach is a GCJ/SWIG wrapper, or a javaclass (bytecode translation)+ctypes dynamic approach. I'm somewhat more interested in the latter approach, as I find C++ a bit of a pain with respect to buildability. I'm open to either approach. I don't know a lot about JNI, so I was hoping somebody would come along for the ride who could answer certain questions about how SWT is implemented. By design, SWT is pure Java with an as-thin-as-possible JNI wrapping of the native platform GUI. It's akin to writing a pure Python GUI for Windows using ctypes or simple Pyrex wrappers to directly call Windows C APIs. The important thing to be aware of here is that this means that you can't just take the SWT .dll's or .so's and put a Python binding on them, because all you'd end up with is a wrapper to the Windows or Mac or GTK API. I'll repeat this, because it's a common source of confusion about SWT: the SWT implementation is *all* Java. The native dynamic libraries for SWT are just the glue to be able to call platform API's, they do not contain *any* high-level code. This is both good and bad. It's good in that you don't have to worry about the JNI issue if you want to port SWT to another platform, you just have to have a way to call the platform's APIs. It's bad in that you can't just put a new language binding on the native libraries and have an SWT port. A third option would be to grovel over SWT and implement an identical functionality in Python (pure-python plus ctypes), and make a mirror implementation, rather than a wrapper. If you're going to do that, you might as well use javaclass to do the grunt work of the translation, and simply replace the native library with a ctypes-based module. An additional complication is that SWT is a different package on each platform, so it's not so much port SWT to Python as port SWT-windows to Python, port SWT-Mac to Python, etc. The API is identical for each platform, however, so depending on the level at which you wrapped it, this is only a build problem. I'm just pointing out that the source code for each platform is different. The native library for each platform is different. The native libraries also expose different APIs on each platform, because they just expose that platform's native API. So sure, there's probably some code that's similar or identical, but the whole point of SWT is that each one is a custom implementation for its platform, as distinct from approaches like AWT, Swing, wxWidgets, et al. (I assume that you're talking about porting to a JVM-less CPython extension, since if you were to leave it in Java you could just use Jython or one of the binary Python-Java bridges to access SWT as-is.) Yes, JVM-less CPython extension would be the plan. Then here are the possible architectures, as I understand them: Layer 1: Native Platform Interface Option 1: Use the JNI libraries supplied with SWT (forces GCJ at layer 2) Option 2: Create a Python wrapper for the corresponding APIs * Possibly semi-autogenerated from JNI metadata * ctypes, Pyrex, or C Layer 2: SWT Java Implementations Option 1: Compile with GCJ (requires JNI approach at layer 1) Option 2: Translate Java bytecode to Python bytecode w/javaclass Option 3: Translate Java bytecode to Pyrex or C (by modifying javaclass) Option 4: Translate Java source to Python or Pyrex by hand (for *each* platform!) Layer 3: Python wrapper (only needed for GCJ scenario) Option 1: SWIG (needs a C++/SWIG guru) Option 2: Boost::Python Option 3: Plain C++ So as you can see, the choices are basically GCJ versus everything else, but the GCJ approach forces C++ into the mix and requires good knowledge of either C++ or SWIG, maybe both. But it only needs to be done once, and should then be buildable on all platforms. OTOH, if I had the necessary skills, I'd have probably already taken on the effort. It would be cool if somebody created a SWIG wrapper generator that could pull the necessary info from Java class files to make a GCJ wrapper. But as far as I know, everybody who's wrapped Java libraries for Python using GCJ wrote their wrappers by hand. Anyway, this is now getting *way* off topic for Python-Dev, so if there aren't any other interested parties we should take this off-list. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
[Python-Dev] FWD: SD MAgazine.com - Jolt Awards Winners
Guido may not be able to go. Anyone else already going? - Forwarded message from [EMAIL PROTECTED] - Subject: Request - SD MAgazine.com - Jolt Awards Winners To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Date: Thu, 10 Mar 2005 16:02:35 -0800 HI Python.org, You may or may not be aware that Python is a finalist in the 15th Annual Jolt Awards in the Languages and Development Category.The awards ceremony will take place at SD West, in the Santa Clara Convention Center, Auditorium, on March 16th from 6:30-7:30 p.m., when the winners will be announced. Is there anyway that a representative of Python.org be present to accept the award if they should win? I will have badges for these individuals at the registration desk to attend the awards ceremony. I understand the Guido van Rossum will be attending SD West. Is there anyway that he can be present? All finalists and conference alumni are invited to a poolside party with food, drinks and entertainment after the ceremony at the Westin, which is adjacent to the Conference Center. Hope to see you there. Dress should be business casual. Looking forward to hearing from you. Rosalyn (415) 947-6182 = Rosalyn Lum Technical Editor Software Development Magazine CMP Media 600 Harrison St., 6th Floor San Francisco, CA 94107 www.sdmagazine.com - End forwarded message - -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR ___ 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] Adding any() and all()
See my blog: http://www.artima.com/forums/flat.jsp?forum=106thread=98196 Do we even need a PEP or is there a volunteer who'll add any() and all() for me? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] RELEASED Python 2.4.1, release candidate 1
Anthony Baxter wrote: On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.1 (release candidate 1). Python 2.4.1 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the bugs squished in this release. I'd like to encourage feedback on whether the Windows installer works for people. It replaces the VBScript part in the MSI package with native code, which ought to drop the dependency on VBScript, but might introduce new incompatibilities. 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/archive%40mail-archive.com
RE: [Python-Dev] Adding any() and all()
See my blog: http://www.artima.com/forums/flat.jsp?forum=106thread=98196 Do we even need a PEP or is there a volunteer who'll add any() and all() for me? I'll volunteer for this one. Will leave it open for discussion for a bit so that folks can voice any thoughts on the design. Raymond Hettinger ___ 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 any() and all()
At 06:38 PM 3/10/05 -0800, Bill Janssen wrote: Guido, I think there should be a PEP. For instance, I think I'd want them to be: def any(S): for x in S: if x: return x return S[-1] def all(S): for x in S: if not x: return x return S[-1] Or perhaps these should be called first and last. More precisely (since S might be an iterator, or empty): def any(S): x = False for x in S: if x: break return x def all(S): x = True for x in S: if not x: break return x However, first and last don't make sense to me as names. First what? Last what? Actually, any and all don't make that much sense to me either. I find myself wanting to call them or and and, or maybe or_iter and and_iter. Or perhaps until_false or until_true. Nah, the and/or names make more sense, as they exactly match the behavior of the corresponding logical operators, if you could call them as a function. At least, if they took *args anyway. ___ 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 any() and all()
[Bill Janssen] I think I'd want them to be: def any(S): for x in S: if x: return x return S[-1] def all(S): for x in S: if not x: return x return S[-1] Or perhaps these should be called first and last. -1 Over time, I've gotten feedback about these and other itertools recipes. No one has objected to the True/False return values in those recipes or in Guido's version. Guido's version matches the normal expectation of any/all being a predicate. Also, it avoids the kind of errors/confusion that people currently experience with Python's unique implementation of and and or. Returning the last element is not evil; it's just weird, unexpected, and non-obvious. Resist the urge to get tricky with this one. Raymond Hettinger ___ 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] Re: Can't build Zope on Windows w/ 2.4.1c1
On Friday 11 March 2005 08:09, Tres Seaver wrote: |By staring at the code of the failing test, it looks like the MRO of the |testcase class has changed: it declares a 'run' method, which is |supposed to run the external process, which clashes with the 'run' |method of unittest.TestCase. I don't know what change in the 2.4 - |2.4.1c1 update would have mucked with the MRO (if a MRO issue is |involved). Looking in Misc/NEWS, I suspect that this fix is responsible. - unittest.TestCase.run() and unittest.TestSuite.run() can now be successfully extended or overridden by subclasses. Formerly, the subclassed method would be ignored by the rest of the module. (Bug #1078905). -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] branch release24-maint is unfrozen, 2.4.1rc2?
Ok, the branch is unfrozen. At the current point in time, I think we're going to need an rc2. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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 any() and all()
Over time, I've gotten feedback about these and other itertools recipes. No one has objected to the True/False return values in those recipes or in Guido's version. Guido's version matches the normal expectation of any/all being a predicate. Also, it avoids the kind of errors/confusion that people currently experience with Python's unique implementation of and and or. Returning the last element is not evil; it's just weird, unexpected, and non-obvious. Resist the urge to get tricky with this one. Fine, but then let's keep reduce(), which has this nice property. Bill ___ 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 any() and all()
On Thu, Mar 10, 2005 at 10:22:45PM -0500, Raymond Hettinger wrote: [Bill Janssen] I think I'd want them to be: def any(S): for x in S: if x: return x return S[-1] def all(S): for x in S: if not x: return x return S[-1] Or perhaps these should be called first and last. -1 Over time, I've gotten feedback about these and other itertools recipes. No one has objected to the True/False return values in those recipes or in Guido's version. Guido's version matches the normal expectation of any/all being a predicate. Also, it avoids the kind of errors/confusion that people currently experience with Python's unique implementation of and and or. Returning the last element is not evil; it's just weird, unexpected, and non-obvious. Resist the urge to get tricky with this one. Perl returns the last true/false value as well, and it is a subtle trap. I worked at a perl shop that had a long style guide which outlawed using that side effect but people did anyway. I'm +1 on having it return a true boolean for the same reason if (x = calc_foo()): isn't supported, if there is a quirky side effect available someone will use it and someone else won't notice. [in fact we had a guy who was downsized for doing things like calling database queries on the return value of a function that was documented as returning True/False] Perl shops require long style guides becuase perl is, ummm, perl. Python is a boon because YAGN (a style guide). The fewer side effects the better. -Jack ___ 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] Urllib code or the docs appear wrong
It seems to me that either urllib's docs are wrong or its code is wrong w.r.t. how the User-agent header is handled. Guido I propose fixing the docs... Done (also backported to 2.4 branch). Skip ___ 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: No new features (was Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36)
Anthony Initially, I was inclined to be much less anal about the Anthony no-new-features thing. But since doing it, I've had a quite Anthony large number of people tell me how much they appreciate this Anthony approach - vendors, large companies with huge installed bases Anthony of Python, and also from people releasing software written in Anthony Python. Same here. People are amazed at work when I tell them I can just install a micro release without any breakage. Anthony I should also add that the above is really just policy as it's Anthony evolved - if people want to discuss this (am I being too Anthony strict?) I'm happy to talk about it. Current policy gets a big +1 from me. Skip ___ 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] rationale for the no-new-features approach
Anthony Goal 4: Try and prevent something like Anthony try: Anthony True, False Anthony except NameError: Anthony True, False = 1, 0 Anthony from ever ever happening again. I will point out that in the transition from 2.3 to 2.4 our code that uses sets has try: x = set except NameError: from sets import Set as set else: del x Rather ugly. I suppose I could just put the necessary incantation in sitecustomize to dump the set name in builtins, but it would be kinda nice if this sort of thing could be avoided in the future. Skip ___ 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] RELEASED Python 2.4.1, release candidate 1
[Martin v. Löwis] I'd like to encourage feedback on whether the Windows installer works for people. It replaces the VBScript part in the MSI package with native code, which ought to drop the dependency on VBScript, but might introduce new incompatibilities. Worked fine here. Did an all-default all users install, WinXP Pro SP2, from local disk, and under an account with Admin rights. I uninstalled 2.4 first. I suppose that's the least stressful set of choices I could possibly have made, but at least it confirms a happy baseline. ___ 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] rationale for the no-new-features approach
On Mar 9, 2005, at 8:03 AM, Skip Montanaro wrote: Anthony Goal 4: Try and prevent something like Anthony try: Anthony True, False Anthony except NameError: Anthony True, False = 1, 0 Anthony from ever ever happening again. I will point out that in the transition from 2.3 to 2.4 our code that uses sets has try: x = set except NameError: from sets import Set as set else: del x Rather ugly. I suppose I could just put the necessary incantation in sitecustomize to dump the set name in builtins, but it would be kinda nice if this sort of thing could be avoided in the future. try: set except NameError: from sets import Set as set You don't need the rest. -bob ___ 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 any() and all()
On Thu, Mar 10, 2005, Bill Janssen wrote: Raymond Hettinger: Over time, I've gotten feedback about these and other itertools recipes. No one has objected to the True/False return values in those recipes or in Guido's version. Guido's version matches the normal expectation of any/all being a predicate. Also, it avoids the kind of errors/confusion that people currently experience with Python's unique implementation of and and or. Returning the last element is not evil; it's just weird, unexpected, and non-obvious. Resist the urge to get tricky with this one. +1 Fine, but then let's keep reduce(), which has this nice property. -1 -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR ___ 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] RELEASED Python 2.4.1, release candidate 1
[Martin v. Löwis] I'd like to encourage feedback on whether the Windows installer works for people. It replaces the VBScript part in the MSI package with native code, which ought to drop the dependency on VBScript, but might introduce new incompatibilities. [Tim Peters] Worked fine here. Did an all-default all users install, WinXP Pro SP2, from local disk, and under an account with Admin rights. I uninstalled 2.4 first. I suppose that's the least stressful set of choices I could possibly have made, but at least it confirms a happy baseline. Also works fine for me with: * WinXP Pro SP2, from local disk, with admin rights, all defaults, over the top of 2.4.0 * Win2k SP4, from network disk, without admin rights, all defaults, with no previous 2.4 * Win2k SP4 (different machine), from local disk, with admin rights, defaults apart from skipped test suite, over the top of 2.4.0 =Tony.Meyer ___ 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
