Re: [Python-Dev] __file__
On Sun, 2010-02-28 at 18:11 -0800, Brett Cannon wrote: ... > So then looking for a .pyc alongside a .py or vice versa > should be almost free, and we shouldn't be worrying about > it. > But that is making the assumption that all filesystems operate this > way (.e.g does NFS have the same performance characteristics?). NFS doesn't cache pages, rather it caches individual entries. I do not know if adjacent data is pre-populated into an NFS client cache. I rather suspect not, but the general point is true - many filesystems cache by pages, not all. And some have unsorted lists or might have hash tables rather than b-trees or sorted lists, where locality of reference doesn't help at all. (VFAT is unsorted list, IIRC). > hot cache: > % time seconds usecs/call callserrors > syscall > -- --- --- - - > > 45.100.000368 92 4 > getdents > > 0.000.00 0 734 625 stat > > > Further supporting the idea that stat calls are negligible > once the cache is warmed up. > > > But that's the point: once it's warmed up. This is not the case when > executing a script once every once in a while compared to something > bzr where you are most likely going to execute the command multiple > times within a small timeframe. bzr would /love/ cold cache times to come down. They are one of the most glaring performance differences between a large C program, and a large python program. Even though the second run is fast, it hurts the first time you run 'bzr st'. (**) -Rob (**) To the extent that I've seriously considered an import hook to disable normal imports under bzrlib, and special case how the search works so that we only load pyc's and assume all imports are absolute. signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
Antoine Pitrou a écrit : Le Sun, 28 Feb 2010 21:45:56 +0100, Baptiste Carvello a écrit : bytecode-only in a zip is used by py2exe, cx_freeze and the like, for space reasons. Disabling it would probably hurt them. Source code compresses quite well. I'm not sure it would make much of a difference. I did a quick check on the stdlib: a zip with .py and .pyc is about 80% bigger than one with .pyc only. If you use only the bytecode, this can be seen as waisted space. On the other hand, if you ever need to debug the application, source is very handy... Anyway, I'm a bit worried if bytecode-only is disabled from zipimport without some input from the developpers of py2exe/cx_freeze/etc, as they are big users of it. Cheers, Baptiste ___ Python-Dev mailing list [email protected] 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 PEP on RSON configuration file format
> Finding .ini configuration files too limiting, JSON and XML to hard to > manually edit [snip] > I call the new format RSON (for "Readable Serial Object Notation"), > and it is designed to be a superset of JSON. Quick question: if JSON is too hard to manually edit, how can RSON be any easier when it is a *superset* of JSON? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
Brett Cannon wrote: > So there are a total of five to six depending on the OS (actually, VMS > goes up to eight!) before a search path is considered not to contain a > module. The windows list is actually going to be slightly different (dir, pyd, py, pyw, py[co]). It looks for .pyd files rather than either flavour of .so file (we stopped allowing .dll files some time back due to the sqlite3 DLL naming conflict). So I believe it is always 5 stat calls on the major platform - dropping the bytecode filename check saves 20% of them on a miss. I'm not convinced that saving is worth the hassle of incurring a whole pile of subtle backward compatibility problems. It seems better to say "Python doesn't create in-place bytecode files anymore, but if you arrange to put them there yourself we'll still read them". I certainly wouldn't support removing the feature without some solid benchmarks to say that it really is going to significantly speed up typical import times for non-trivial modules (given that part of the definition of "non-trivial" is "significant amounts of code to be run when imported", that bar is likely to be a tough one to clear). > And thanks to doing this I realized importlib is not stat'ing the > directory first which should fail faster than checking for the __init__ > files every time. That would explain why we had different ideas as to what the interpreter was doing :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
Le Mon, 01 Mar 2010 09:09:09 +0100, Baptiste Carvello a écrit : > > I did a quick check on the stdlib: a zip with .py and .pyc is about > 80% bigger than one with .pyc only. If you use only the bytecode, > this can be seen as waisted space. On the other hand, if you ever > need to debug the application, source is very handy... My point is that the wasted size compared to the total bundle size (with interpreter and 3rd party C libs) would probably be small. > Anyway, I'm a bit worried if bytecode-only is disabled from zipimport > without some input from the developpers of py2exe/cx_freeze/etc, as > they are big users of it. Granted. Regards Antoine. ___ Python-Dev mailing list [email protected] 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 PEP on RSON configuration file format
On Mon, Mar 1, 2010 at 3:02 AM, Daniel Fetchinson wrote: > Quick question: if JSON is too hard to manually edit, how can RSON be > any easier when it is a *superset* of JSON? > Well, Python is essentially a superset of JSON, with string escape handling being ever so slightly different, and using True instead of true, False instead of false, and None instead of null. YMMV, but I find it possible, even probable, to write Python that is far easier to edit than JSON, and in fact, I have used Python for configuration files that are only to be edited by programmers or other technical types. Regards, Pat ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
Nick Coghlan wrote: Michael Foord wrote: Can't it look for a .py file in the source directory first (1st stat)? When it's there check for the .pyc in the cache directory (2nd stat, magic number encoded in filename), if it's not check for .pyc in the source directory (2nd stat + read for magic number check). Or am I missing a subtlety? The problem is doing this little dance for every path on sys.path. To unpack this a little bit for those not quite as familiar with the import system (and to make it clear for my own benefit!): for a top-level module/package, each path on sys.path needs to be eliminated as a possible location before the interpreter can move on to check the next path in the list. So the important number is the number of stat calls on a "miss" (i.e. when the requested module/package is not present in a directory). Currently, with builtin support for bytecode only files, there are 3 checks (package directory, py source file, pyc/pyo bytecode file) to be made for each path entry. The PEP proposes to reduce that to only two in the case of a miss, by checking for the cached pyc only if the source file is present (there would still be three checks for a "hit", but that only happens at most once per module lookup). While the PEP is right in saying that a bytecode-only import hook could be added, I believe it would actually be a little tricky to write one that didn't severely degrade the performance of either normal imports or bytecode-only imports. Keeping it in the core import, but turning it off by default seems much less likely to have unintended performance consequences when it is switched back on. Another option is to remove bytecode-only support from the default filesystem importer, but keep it for zipimport (since the stat call savings don't apply in the latter case). What if ... a bytecode-only mode is triggered by "__main__" loading from a bytecode file, otherwise the .py files are needed and are checked to make sure the bytecode files are current. Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Status of PEP 381
Hey folks -- Can someone point me to some information on what's going on with PEP 381 (PyPI mirroring)? There's a bunch of XXX'd material, and it doesn't appear that pypi.python.org implements the statistics or providing parts. I'd be willing -- happy, actually -- to fill in the missing pieces, but only if I'm not stepping on anyone's toes. I'd also need some help adding code to pypi.python.org if that's a necessary part -- I'm not very good at finding my way around that codebase. Thanks, Jacob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of PEP 381
On 3/1/2010 2:45 PM, Jacob Kaplan-Moss wrote: Hey folks -- Can someone point me to some information on what's going on with PEP 381 (PyPI mirroring)? There's a bunch of XXX'd material, and it doesn't appear that pypi.python.org implements the statistics or providing parts. I'd be willing -- happy, actually -- to fill in the missing pieces, but only if I'm not stepping on anyone's toes. I'd also need some help adding code to pypi.python.org if that's a necessary part -- I'm not very good at finding my way around that codebase. There is a separate catalog/pypi mailing list, mirrored as gmane.comp.python.catalog. Ask there. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
On Mon, Mar 1, 2010 at 08:30, Ron Adam wrote: > > > Nick Coghlan wrote: > >> Michael Foord wrote: >> >>> Can't it look for a .py file in the source directory first (1st stat)? When it's there check for the .pyc in the cache directory (2nd stat, magic number encoded in filename), if it's not check for .pyc in the source directory (2nd stat + read for magic number check). Or am I missing a subtlety? >>> The problem is doing this little dance for every path on sys.path. >>> >> >> To unpack this a little bit for those not quite as familiar with the >> import system (and to make it clear for my own benefit!): for a >> top-level module/package, each path on sys.path needs to be eliminated >> as a possible location before the interpreter can move on to check the >> next path in the list. >> >> So the important number is the number of stat calls on a "miss" (i.e. >> when the requested module/package is not present in a directory). >> Currently, with builtin support for bytecode only files, there are 3 >> checks (package directory, py source file, pyc/pyo bytecode file) to be >> made for each path entry. >> >> The PEP proposes to reduce that to only two in the case of a miss, by >> checking for the cached pyc only if the source file is present (there >> would still be three checks for a "hit", but that only happens at most >> once per module lookup). >> >> While the PEP is right in saying that a bytecode-only import hook could >> be added, I believe it would actually be a little tricky to write one >> that didn't severely degrade the performance of either normal imports or >> bytecode-only imports. Keeping it in the core import, but turning it off >> by default seems much less likely to have unintended performance >> consequences when it is switched back on. >> >> Another option is to remove bytecode-only support from the default >> filesystem importer, but keep it for zipimport (since the stat call >> savings don't apply in the latter case). >> > > What if ... a bytecode-only mode is triggered by "__main__" loading from a > bytecode file, otherwise the .py files are needed and are checked to make > sure the bytecode files are current. > > That's way too magical for my tastes, especially if you mess up and accidentally leave behind a __main__.pyc after moving the __main__.py file. -Brett > Ron > > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Who needs to be added to python-committers?
Any people who have commit privileges not subscribed to python-committers? We have gained some new people recently so I just want to make sure everyone is subscribed to the list. Also, anyone have an email address for Hirokazu Yamamoto? His mailbox is full so Mailman unsubscribed him. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of PEP 381
On Mon, Mar 1, 2010 at 8:45 PM, Jacob Kaplan-Moss wrote: > Hey folks -- > > Can someone point me to some information on what's going on with PEP > 381 (PyPI mirroring)? There's a bunch of XXX'd material, and it > doesn't appear that pypi.python.org implements the statistics or > providing parts. > > I'd be willing -- happy, actually -- to fill in the missing pieces, > but only if I'm not stepping on anyone's toes. I'd also need some help > adding code to pypi.python.org if that's a necessary part -- I'm not > very good at finding my way around that codebase. Hey Jacob, I have started to implement the server parts (some are already available at pypi but not activated) and Martin worked on the client part on his side to provide a library for mirrors. I need to finish editing the PEP text but any help is welcome of course on any part. As Terry suggested you can send a mail at Catalog, I'll catch up on the thread once its started, to list possible tasks. Regards, Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python and Windows 2000
I don't recall whether we have already decided about continued support for Windows 2000. If not, I'd like to propose that we phase out that support: the Windows 2.7 installer should display a warning; 3.2 will stop supporting Windows 2000. Opinions? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
Ron Adam wrote: What if ... a bytecode-only mode is triggered by "__main__" loading from a bytecode file, otherwise the .py files are needed and are checked to make sure the bytecode files are current. That would preclude having a bytecode-only library that could be used by a sourceful program. Such a situation might arise if you have an application with a scripting interface that is used by importing stuff from the application's internal libraries. -- Greg ___ Python-Dev mailing list [email protected] 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 and Windows 2000
On Mon, Mar 1, 2010 at 1:40 PM, "Martin v. Löwis" wrote: > I don't recall whether we have already decided about continued support > for Windows 2000. > > If not, I'd like to propose that we phase out that support: the Windows > 2.7 installer should display a warning; 3.2 will stop supporting Windows > 2000. > > Opinions? +2000 -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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 and Windows 2000
On Mar 1, 2010, at 4:53 PM, Guido van Rossum wrote: > On Mon, Mar 1, 2010 at 1:40 PM, "Martin v. Löwis" wrote: >> I don't recall whether we have already decided about continued support >> for Windows 2000. >> >> If not, I'd like to propose that we phase out that support: the Windows >> 2.7 installer should display a warning; 3.2 will stop supporting Windows >> 2000. >> >> Opinions? > > +2000 I guess i'll finally have to retire my ten year old MSDN cd's and my favorite version of Windows -- the last one I ever used. S ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Packaging JIT-less versions of Python
Hey packaging guys, We recently committed a change to Unladen Swallow [1] that moves all the JIT infrastructure into a Python extension module. The theory [2] behind this patch was that this would make it easier for downstream packagers to ship a JIT-less Python package, with the JIT compiler available via an optional add-on package. Some questions for you, so we're not shooting blind here: - Have you guys thought about how a JIT-enabled Python 3 installation would be packaged by your respective distros? - Would you prefer the default python3.x package to have a JIT, or would you omit the JIT by default? - How would you prefer to build the JIT-less package (current options: via a ./configure flag; or by deleting _llvmjit.so from the JIT-enabled package)? - Would the two packages be able to exist side-by-side, or would they be mutually exclusive? My strong preference would be to have the JIT included by default so that it receives as much testing as possible. Thanks, Collin Winter [1] - http://code.google.com/p/unladen-swallow/source/detail?r=1110 [2] - http://code.google.com/p/unladen-swallow/issues/detail?id=136 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
On Feb 28, 2010, at 10:40 PM, Antoine Pitrou wrote: >File extensions exist for a reason, even if you find that "kooky" and >have strong ideas about the psychology of text editors. > >Having some binary files named "foobar.py" would certainly annoy a lot >of people, including me. I completely agree. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
On Feb 28, 2010, at 02:51 PM, Greg Ewing wrote: >A solution might be to look for the presence of the >cache directory, and only look for a .pyc in the source >directory if there is no cache directory. Testing for >the cache directory would only have to be done once >per package and the result remembered, so it would >add very little overhead. I think the other thing that bothers me about continuing to support pyc-only imports, is that people will then want tools to create them. Right now, it's probably just as easy as byte-compiling everything, then finding the .py files and removing them. After PEP 3147 is implemented, and the default, you'll have to byte-compile the files, then find the pycs in the __pycache__ directory, move them up a level and rename them. Then of course remove the .py files. It's not insurmountable of course, I think if we support pyc-only imports, people are rightly going to want us to write and support the tool to create those imports. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
On Feb 28, 2010, at 11:07 PM, Nick Coghlan wrote: >While the PEP is right in saying that a bytecode-only import hook could >be added, I believe it would actually be a little tricky to write one >that didn't severely degrade the performance of either normal imports or >bytecode-only imports. Keeping it in the core import, but turning it off >by default seems much less likely to have unintended performance >consequences when it is switched back on. Except that even users of bytecode-only imports probably don't want or care about that for *every* package directory. So really, all-or-nothing hits them too. One option to help with that is to have a flag or marker in a package's __init__.py that signals pyc-only imports for that package directory. It's getting complicated again. ;) >Another option is to remove bytecode-only support from the default >filesystem importer, but keep it for zipimport (since the stat call >savings don't apply in the latter case). I'd be okay with this, but even here I'd argue that it would be fine to require the source files by default. The primary use case I've seen mentioned for pyc-only imports is to make it more difficult for users to accidentally shoot themselves in the foot. I think the very presence of a zip file for importing is enough without the extra step of removing the source. But that's just me. :) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __file__
Thanks everybody for providing great input on this aspect of the PEP. I've updated the open issues section to include a list of the possible resolutions for bytecode-only imports. Unless anybody has more ideas, it might just be time to get a BDFL pronouncement. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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 and Windows 2000
On Mon, Mar 1, 2010 at 13:40, "Martin v. Löwis" wrote: > I don't recall whether we have already decided about continued support > for Windows 2000. > > If not, I'd like to propose that we phase out that support: the Windows > 2.7 installer should display a warning; 3.2 will stop supporting Windows > 2000. > > Opinions? > Considering MS is retiring support for Win2K in July ( http://support.microsoft.com/lifecycle/?p1=3071) I think we can be faster than them in dropping it. =) +1 from me. > > Regards, > Martin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] 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 3188: Implementation Questions
On Sat, Feb 27, 2010 at 11:20 AM, Thomas Heller wrote: > See issue 887237: > > http://bugs.python.org/issue887237 > Thanks for the link Thomas. Since there is already interest in adding arithmetic to ctypes, perhaps that is an option. One question that raises in my mind, though, is should only 'long double' unpack to a ctype in that case? Or should all items unpack to ctypes now? It seems to me that you would want everything to unpack to types from the same family (e.g. Python builtins or ctypes). This seems conceptually cleaner and the interoperability between types in the same "family" are (or can be in the case of modifying ctypes) more clearly defined. Thanks, -- Meador ___ Python-Dev mailing list [email protected] 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 and Windows 2000
Martin v. Löwis: > I don't recall whether we have already decided about continued support > for Windows 2000. > > If not, I'd like to propose that we phase out that support: the Windows > 2.7 installer should display a warning; 3.2 will stop supporting Windows > 2000. Is there any reason for this? I can understand dropping Windows 9x due to the lack of Unicode support but is there anything missing from Windows 2000 that makes supporting it difficult? Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Packaging JIT-less versions of Python
On Mon, 2010-03-01 at 15:35 -0800, Collin Winter wrote: > Hey packaging guys, > > We recently committed a change to Unladen Swallow [1] that moves all > the JIT infrastructure into a Python extension module. The theory [2] > behind this patch was that this would make it easier for downstream > packagers to ship a JIT-less Python package, with the JIT compiler > available via an optional add-on package. > > Some questions for you, so we're not shooting blind here: > - Have you guys thought about how a JIT-enabled Python 3 installation > would be packaged by your respective distros? I suspect that there may be architecture-specific issues both in getting LLVM to work, and in getting the Python JIT code running (e.g. I've no idea how well it works on, say, s390). The answers may vary between CPU architecture (e.g. "on by default for i386 and x86_64, off by default on ppc", or whatever). > - Would you prefer the default python3.x package to have a JIT, or > would you omit the JIT by default? I'd be inclined to turn it on by default in Fedora's "rawhide" development branch as soon as it's meaningful to test it (with a suitable warning on our mailing list); we like to try this kind of thing! If no major issues are found, I'd leave it turned on. I'd expect to run into "fun" CPU-arch-specific bugs, though. Multicore 64-bit big-endian springs to mind. I can't speak for what I'd do for RHEL at this time. It's likely to be affected by how experience in Fedora goes, but goes through more formal QA, and on more "enterprisey" hardware (e.g. s390). > - How would you prefer to build the JIT-less package (current options: > via a ./configure flag; or by deleting _llvmjit.so from the > JIT-enabled package)? > - Would the two packages be able to exist side-by-side, or would they > be mutually exclusive? I have a particular interest in ABI compatibility: if turning JIT on and off is going to change the ABI of extension modules, that would be a major pain, as I hope that we will have dozens of C extension modules available via RPM for our Python 3 stack by the time of the "great unladen merger". So I'm keen for the ability to toggle the JIT code in the face of bugs and have it not affect ABI. "-Xjit" will do this at runtime (once that's renamed), but I think it would be useful to be able to toggle the JIT on/off default during the build, so that I can fix a broken architecture for non-technical users, but have individual testers opt back in with -Xjit whilst tracking down a major bug. In either case, I don't want to have to recompile 30 extension modules to try with/without JIT; that would introduce too much change during bug-hunts, and be no fun at all. (In the blue-sky nirvana future, I'd love to be able to ship ahead-of-time compiled versions of the stdlib, pre-optimized based on realworld workloads. Back in my reality, though, I have bugs to fix before I can work on _that_ patch :( ) > My strong preference would be to have the JIT included by default so > that it receives as much testing as possible. Sounds reasonable. Hope the above made sense and is useful. Dave > > Thanks, > Collin Winter > > [1] - http://code.google.com/p/unladen-swallow/source/detail?r=1110 > [2] - http://code.google.com/p/unladen-swallow/issues/detail?id=136 ___ Python-Dev mailing list [email protected] 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 and Windows 2000
>> If not, I'd like to propose that we phase out that support: the Windows >> 2.7 installer should display a warning; 3.2 will stop supporting Windows >> 2000. > >Is there any reason for this? I can understand dropping Windows 9x > due to the lack of Unicode support but is there anything missing from > Windows 2000 that makes supporting it difficult? See http://bugs.python.org/issue6926 The SDK currently hides symbolic constants from us that people are asking for. In addition, we could simplify the code in dl_nt.c around GetCurrentActCtx and friends, by linking to these functions directly. Regards, Martni ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
