Re: [Python-Dev] [python-committers] On track for Python 2.6.4 final this Sunday?
On Oct 13, 2009, at 12:57 PM, Barry Warsaw wrote: On Oct 13, 2009, at 11:16 AM, Tarek Ziadé wrote: I still need to do some more tests, I didn't have time to try the various projects under win32. It's planned to night. The tests are consisting of compiling and insatling a dozain of projects on linux and win32 (and bith when possible) Great thanks, let us know how it goes. If there's any question at all about the fixes that have gone in since rc1, we should spin an rc2. Just curious, how big a server does the linux portion of the test require memory-wise? Would, e.g. an Ubuntu 9.0x with 256MB do the job? I ask because those types of servers are available for short-run jobs for pennines per hour and I would be willing to work on the code to fire-up, load them with the test suite, do the run, and shut them down. I happen to have a bunch of code lying around for doing such things... S ___ 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] Interest in integrating C decimal module into Python?
Shouldn't this be on python-ideas? S On Oct 20, 2009, at 9:15 AM, Stefan Krah wrote: Hi, as some of you know, recently I've released an arbitrary precision C library for decimal arithmetic together with a Python module: http://www.bytereef.org/libmpdec.html http://www.bytereef.org/fastdec.html Both the library and the module have been tested extensively. Fastdec currently differs from decimal.py in a couple of ways that could be fixed. The license is AGPL, but if there is interest in integrating it into Python I'd release it under a Python-compatible license. There have been several approaches towards getting C decimal arithmetic into Python: http://bugs.python.org/issue2486 Fastdec follows Raymond Hettinger's suggestion to provide wrappers for an independent C implementation. Arguments in favour of fastdec are: * Complete implementation of Mike Cowlishaw's specification * C library can be tested independently * Redundant arithmetic module for tests against decimal.py * Faster than Java BigDecimal * Compares relatively well in speed against gmpy To be clear, I would not want to _replace_ decimal.py. Rather I'd like to see a cdecimal module alongside decimal.py. I know that ultimately there should be a PEP for module inclusions. The purpose of this post is to gauge interest. Specifically: 1. Are you generally in favour of a C decimal module in Python? 2. Would fastdec - after achieving full decimal.py compatibility - be a serious candidate? 3. Could I use this list to settle a couple of questions, or would perhaps a Python developer be willing to work with me to make it compatible? I'm asking this to avoid doing work that would not find acceptance afterwards. Thanks, Stefan Krah ___ 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/ssteinerx%40gmail.com ___ 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] Interest in integrating C decimal module into Python?
On Oct 20, 2009, at 9:43 AM, Stefan Krah wrote: sstein...@gmail.com wrote: Shouldn't this be on python-ideas? I found previous discussions about "Decimal in C" on python-dev, that's why used this list. python-ideas: This list is to contain discussion of speculative language ideas for Python for possible inclusion into the language. If an idea gains traction it can then be discussed and honed to the point of becoming a solid proposal to put to either python-dev or python-3000 as appropriate. I guess it's a fine line...and matter of opinion. No worries. S ___ 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] readonly __doc__
On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote: Well __doc__ isn't a normal attribute -- it doesn't follow inheritance rules. Maybe we could add a ticket to flag this in the docs. Is __doc__ not normal due to its general underscorishness, or is it not normal because it isn't? Any others that deserve special notice, while we're at it? Thanks, S ___ 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] readonly __doc__
On Oct 22, 2009, at 2:39 PM, Brett Cannon wrote: On Thu, Oct 22, 2009 at 11:18, sstein...@gmail.com > wrote: On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote: Well __doc__ isn't a normal attribute -- it doesn't follow inheritance rules. Maybe we could add a ticket to flag this in the docs. Sure, go for it. Filed: http://bugs.python.org/issue7186 Is __doc__ not normal due to its general underscorishness, or is it not normal because it isn't? I honestly don't follow that sentence. It means, is it special because it's a "special" i.e. __X__ type attribute or because of something special about __doc__ itself, independent of it being a "special attribute". But __doc__ is special because of its use; documenting how to use of an object. In this case when you call something like help() on an instance of an object it skips the instance's value for __doc__ and goes straight to the defining class and stops there as you don't care how a subclass says to use itself as that is not what you are working with. Any others that deserve special notice, while we're at it? Don't know. Ok, issue recorded. Thanks, S ___ 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] Possible language summit topic: buildbots
On Oct 25, 2009, at 5:47 AM, Martin v. Löwis wrote: These are actually two issues: a) where do we get buildbot hardware and operators? I've been trying to get some feedback about firing up buildbots on Cloud Servers for a while now and haven't had much luck. I'd love to find a way of having buildbots come to life, report to the mother ship, do the build, then go away 'till next time they're required. S ___ 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] Possible language summit topic: buildbots
On Oct 25, 2009, at 9:50 AM, exar...@twistedmatrix.com wrote: Actually setting one up in the first place might take a bit longer, since it involves installing the necessary software and making sure everything's set up right, but the actual slave configuration itself is one command: buildbot create-slavepassword> I have written a Fabric script for the distutils-buildbot project (on bitbucket, under Tarek) that puts everything necessary up onto an Ubuntu server, runs all the build steps, and fires up the buildbot. Obviously it will have to be modified to correctly configure other types of servers but the implementation should be fairly trivial for someone who could have done it by hand in the first place.Once it's done, it's in the script and may require an occasional tweak but not much more. The next step is to have the slaves themselves created in the cloud, fired up and then report to the mother ship that they're available. This last step is the one that doesn't seem to be supported by the current system. Thanks, S ___ 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] Possible language summit topic: buildbots
On Oct 25, 2009, at 10:05 AM, exar...@twistedmatrix.com wrote: First, there are now a multitude of cloud hosting providers which will operate a slave machine for you. BuildBot has even begun to support this deployment use-case by allowing you to start up and shut down vms on demand to save on costs. Amazon's EC2 service is supported out of the box in the latest release. I have been working to expand this support to Rackspace's Cloud Servers as well. S ___ 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] Possible language summit topic: buildbots
On Oct 25, 2009, at 2:32 PM, Martin v. Löwis wrote: I've been trying to get some feedback about firing up buildbots on Cloud Servers for a while now and haven't had much luck. I'd love to find a way of having buildbots come to life, report to the mother ship, do the build, then go away 'till next time they're required. I'm not quite sure whom you have been trying to get feedback from, and can't quite picture your proposed setup from above description. I posted a couple of messages on testing-in-python, and have sent around some queries to others that I know are using buildbot type setups with various tools/platforms, not necessarily Python. In any case, ISTM that your approach isn't compatible with how buildbot works today (not sure whether you are aware of that): a build slave needs to stay connected all the time, so that the build master can trigger a build when necessary. So if your setup requires the slaves to shut down after a build, I don't think this can possibly work. It can't possibly work within the way the Python buildbot structure currently works, as I understand it so far. What I'm implementing is less of a 'continuous integration' tool like you would use for something like Python itself, and more of a testing tool for things that have to be installed on multiple versions of Python, on multiple platforms. I don't need to know that it works on every checkin, just every once in a while I'd like to start from scratch and make sure everything still works on all supported versions of Python on all the platforms I test on and cloud servers are great for this since I'll usually only need them for an hour or so. S ___ 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] Possible language summit topic: buildbots
On Oct 25, 2009, at 3:35 PM, Martin v. Löwis wrote: I don't need to know that it works on every checkin For us, that is a fairly important requirement, though. Reports get more and more useless if they aren't instantaneous. Sometimes, people check something in just to see how the build slaves react. Understood -- that's why I mentioned it. This is a different use-case. It may still have some use for Python itself, but my idea is more for testing things like libraries where the developer may only work on or have one platform and may want to test installing on other platforms and Python versions during development and/or before release. S ___ 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] Possible language summit topic: buildbots
On Oct 25, 2009, at 5:43 PM, Martin v. Löwis wrote: Only turning on the slave occasionally makes it useless. For certain use cases; not mine. S ___ 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] Reworking the GIL
On Oct 26, 2009, at 10:09 AM, Kristján Valur Jónsson wrote: -Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Sturla Molden time.sleep should generate a priority request to re-acquire the GIL; and so should all other blocking standard library functions with a time- out. I don't agree. You have to be very careful with priority. time.sleep() does not promise to wake up in any timely manner, and neither do the timeout functions. Rather, the timeout is a way to prevent infinite wait. In my experience (from stackless python) using priority wakeup for IO can result in very erratic scheduling when there is much IO going on, every IO trumping another. You should stick to round robin except for very special and carefully analysed cases. All the IO tasks can also go in their own round robin so that CPU time is correctly shared among all waiting IO tasks. IOW, to make sure that all IO tasks get a fair share *in relation to all other IO tasks*. Tasks can be put into the IO round robin when they "pull the IO alarm" so to speak, so there's no need to decide before-hand which task goes in which round robin pool. I'm not familiar with this particular code in Python, but I've used this in other systems for years to make sure that IO tasks don't starve the rest of the system and that the most "insistent" IO task doesn't starve all the others. S ___ 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] Reworking the GIL
On Oct 26, 2009, at 6:45 PM, exar...@twistedmatrix.com wrote: Despite what I said above, however, I would also take a default position against adding any kind of more advanced scheduling system here. It would, perhaps, make sense to expose the APIs for controlling the platform scheduler, though. I would also like to have an exposed API and optional profiling (optional as in conditional compilation, not as in some sort of profiling 'flag' that slows down non-profiling runs) so that you can see what's going on well enough to use the API to tune a particular platform for a particular workload. S ___ 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] Retrieve an arbitrary element from a set withoutremoving it
On Oct 27, 2009, at 2:50 PM, Terry Reedy wrote more and more and more and more and more and more and more and more and more: This topic needs its own flippin' newsgroup. S ___ 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] Retrieve an arbitrary element from a set withoutremoving it
On Oct 27, 2009, at 11:02 PM, Terry Reedy wrote: sstein...@gmail.com wrote: This topic needs its own flippin' newsgroup. You could have said just that, appropriate or not, without dumping on anyone in particular. I was not trying to dump on you in particular, I picked a random message of the trillions that went by and happened to get you. I apologize if you felt dumped on. No offense intended to you in particular but this thread has gone on and on and on and on and on and on... S ___ 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] Refactoring installation schemes
On Oct 28, 2009, at 7:02 AM, Michael Foord wrote: M.-A. Lemburg wrote: Tarek Ziadé wrote: Hello, Since the addition of PEP 370, (per-user site packages), site.py and distutils/command/install.py are *both* providing the various installation directories for Python, depending on the system and the Python version. We have also started to discuss lately in various Mailing Lists the addition of new schemes for IronPython and Jython, meaning that we might add some more in both places. I would like to suggest a simplification by adding a dedicated module to manage these installation schemes in one single place in the stdlib. This new independant module would be used by site.py and distutils and would also make it easier for third party code to work with these schemes. Of course this new module would be rather simple and not add any new import statement to avoid any overhead when Python starts and loads site.py +1 This would help unpollute ~/ which is getting quite full of 'stuff.' S ___ 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] EC2 buildslaves
On Nov 2, 2009, at 6:30 AM, Antoine Pitrou wrote: twistedmatrix.com> writes: Starting with a mainstream distro doesn't seem like a bad idea. For example, there isn't currently a 32bit Ubuntu (any version) slave. That would be a nice gap to fill in, right? I've setup a buildslave on an EC2 Ubuntu Karmic instance here: http://www.python.org/dev/buildbot/all/buildslaves/pitrou-ubuntu If you could send me the script that you used to set it up, I could give it a shot on RackSpace where it's cheaper (and I have a temporary developer account). S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
Not that anyone has asked yet, but here's my opinion on two issues that have been raised on the python-dev mailing list lately: +1 on 2.7 release with as much 3.0 "easy-port goo" as is practicable without delaying the product beyond the tentative schedule. Sooner would, of course, be better but I'm sure PEP 373 was produced after due consideration of all pertinent factors. +1 on 2.7 being the last of the 2.x series. Enough already! I, personally, haven't even written my first line of 3.x code, nor have I had any good reason to. If I saw the actual end of the line at 2.7, I would actually start looking for 3.x versions of my favorite tools and would be much more inclined to help push them along ASAP. Right now, so much that I use on a daily basis doesn't even have a 3.x roadmap, much less any sort of working implementation, that I don't see switching to 3.x ever unless the 2.x line ends, and soon! Just my one vote. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 2, 2009, at 7:26 PM, James Y Knight wrote: It really sounds like you're saying that switching to 3.x isn't worth the cost to you, but you want to force people (including yourself) to do so anyways, because ...? Because that's the future of Python, where the developers who make real base language improvements are focusing their attention, and because the language would advance faster without this split attention. A better language, i.e. Python 3.x, will become better faster without dragging the 2.x series out any longer. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 2, 2009, at 11:28 PM, Barry Warsaw wrote: On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote: A better language, i.e. Python 3.x, will become better faster without dragging the 2.x series out any longer. If Python 2.7 becomes the last of the 2.x series, then I personally favor back porting as many features from Python 3 as possible. I still think doing so will help people migrate to Python 3 by getting their Python 2 code base as close to Python 3 as possible without biting the ultimate bullet. E.g. for me "from __future__ import absolute_import, unicode_literals" in Python 2.6 has helped quite a bit. I agree as long as: A> 2.7 comes out as soon as possible, even if it's missing helpful porting features. B> 2.7 will get ONLY new features that make it easier to port to 3.x, not every feature added to 3.x or all you've done is make "Python 2.7, the Python 3 Version." and core developer time will continue to be wasted on Python 2.7 instead of moving forward. I also think Guido's call for feature freeze makes a lot more sense when 2.7 is the EOL. Let's give people migrating to Python 3 a nice big stable target to hit. Improving the stdlib also gives people a big carrot to move. Agreed. And specifically NOT porting every shiny new toy from Python 3 back to 2.7 makes sure the carrots are only in the 3.x series. I think it's also necessary to give third party library and application authors as much help as possible to provide Python 3 compatible software. Putting together Python tools involves so many dependencies in a fairly deep stack that even one unconverted library can cause everything above it to stall on Python 2. And that's one of the reasons my explorations into Python 3 have been limited to pretty much nothing. I don't have time to do a bunch of work only to find out that the tool I absolutely have to have to finish a project doesn't have a Python 3 version or has been crippled to make a Python 3 version. BeautifulSoup, which I use every day, is one such product. Since the crappy old SMGL parser's gone, BeautifulSoup uses the one that's left in Python 3 and it makes BeautifulSoup completely useless for my daily work. That's not to say I can't fix that one particular project, but customers get cranky when their project is taking longer than expected and "Oh, I'm having to convert a lot of things to use Python 3" doesn't seem to improve their mood much. Thanks, S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 12:06 AM, Guido van Rossum wrote: On Mon, Nov 2, 2009 at 9:51 PM, sstein...@gmail.com > wrote: BeautifulSoup, which I use every day, is one such product. Since the crappy old SMGL parser's gone, BeautifulSoup uses the one that's left in Python 3 and it makes BeautifulSoup completely useless for my daily work. This sounds an area where some help might be useful. Perhaps the quickest solution would simply be to copy the old crappy "sgml" based html parser into a new version of BeautifulSoup. That is what we're discussing doing on the old-soup branch at http://github.com/adevore/old-beautiful-soup . I'm not exactly sure why the old SGML parser was dropped but it seems that porting it to Python 3 would be enough of an effort that it caused the Python library to drop it, and the current developer of the mainline of Beautiful Soup to decide to just use what was available in Python 3 natively. Though I imagine what it really needs is a "quirks mode" parser that is compatible with the HTML dialect accepted by, say, IE6. Maybe a summer of code project? I think it just relies on the old SGML parser's not blowing up on completely bogus HTML (like most of the web) and does the best it can with the 'chunks' that come back; nothing to do with quirks mode per se. As for a Summer of Code project, I have no idea what would be involved. I know there are lots of users for Beautiful soup; as far as I know it is the best scraper of HTML code, valid or not, that's out there and it's been around a long time and I see it in projects in the "html scraping" realm all the time. At any rate, it's just one example of where the developer has taken the easy route out with a 3.0 port and has produced a product that's "Python 3" but, instead of getting better with Python's new features, has actually become useless for the majority of use-cases where formerly it shined. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 1:07 AM, Martin v. Löwis wrote: Barry Warsaw wrote: On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote: A better language, i.e. Python 3.x, will become better faster without dragging the 2.x series out any longer. If Python 2.7 becomes the last of the 2.x series, then I personally favor back porting as many features from Python 3 as possible. And if *2.6* becomes the last of the 2.x series? Then I'd guess that that would annoy the crap out of everyone who's put so much effort into 2.7 and all of us who have been waiting for what I hope will finally be the "now ports way more easily to 3.0" version. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 4:55 AM, David Cournapeau wrote: On Tue, Nov 3, 2009 at 6:13 PM, Michael Foord > wrote: There is also little documentation on how to port a significant C codebase to py3k. Now there's a good Summer of Code project: to produce a pre-processor that will flag all C constructs that need to be modified in some way, with direct pointers to the relevant documentation, and "code suggestions" wherever practicable. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 4:58 AM, Raymond Hettinger wrote: P.S. I found it curious that one of the strongest proponents of killing 2.x also mentioned that he has never written a line of 3.x code. Since this discussion is a matter of great consequence, I would hope that advocates will only take informed positions -- this isn't really time for shooting from the hip and killing 2.x. Uh, that would be me. I'm only a proponent of making a decision. I *want* to have a better development language, library, and add-on tools. If 3.x is where future core development time is going to be focused, then I have faith that they will be able to make it the compelling path that it will become with Guido having put as much effort into it as he has. Or, maybe he's completely lost his mind as sometimes happens with "dictators for life" benevolent or other-wise. ;-) In any case, splitting time between 2.x and 3.x, with limited developer resources is going to lead to slower progress on both fronts. And, as you point out, if 3.x doesn't start getting the crap beat out of it in the real world sooner rather than later, we may find ourselves, collectively with a stale 2.x, an under battle-tested 3.x, and nowhere to go. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 2:20 AM, Sturla Molden wrote: I'd just like to mention that the scientific community is highly dependent on NumPy. As long as NumPy is not ported to Py3k, migration is out of the question. Porting NumPy is not a trivial issue. It might take a complete rewrite of the whole C base using Cython. NumPy's ABI is not even PEP 3118 compliant. Changing the ABI for Py3k might break extension code written for NumPy using C. And scientists tend to write CPU-bound routines in languages like C and Fortran, not Python, so that is a major issue as well. If we port NumPy to Py3k, everyone using NumPy will have to port their C code to the new ABI. There are lot of people stuck with Python 2.x for this reason. It does not just affect individual scientists, but also large projects like IBM and CERN's blue brain and NASA's space telecope. Then, perhaps, if 2.7 is known to be the last release of the 2.x line, some of those deep pockets can cough up some $$$ or developers to actually _do_ the port. A Python 3 version of NumPy might be enough of an improvement to bring *more* scientists and engineers onboard if the Python 3.x version shows what great productivity gains are to be had with Python 3.x over 2.x. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 12:38 PM, Guido van Rossum wrote: On Tue, Nov 3, 2009 at 9:35 AM, sstein...@gmail.com > wrote: On Nov 3, 2009, at 12:23 PM, Guido van Rossum wrote: On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight wrote: If that happens, it's not true that there's *nowhere* to go. A solution would be to discard 3.x as a failed experiment, take everything that is useful from it and port it to 2.x, and simply continue development from the last 2.x release. And from there, features can be deprecated and then removed a few releases later, as is the usual policy. Been there, done that, on a couple other projects. It's unfortunate when you have to throw out work you've done because it failed to gain traction over the thing you tried to replace, but sometimes that's life. I'm not ready for that yet. I think there's plenty of time before we have to agree to such a bleak view. In the mean time let's do something practical like help NumPy port to Py3k. Or, for example, Django... Wasn't Django ported to Py3k by MvL as a demo? The problem seems to be more to port the Django *community* to Py3k... I do remember seeing something about that somewhere but it sure isn't jumping into my workflow at the moment. If I can get a Python 3 version of Django, that's keeping up with trunk, I hereby declare that I will start using it on my current project as soon as the client takes the blowtorch off my toes for the current deliverable. And...I'll help keep it up to date with trunk as best I can and also help pull along all the modules I need (incidentally, including Beautiful Soup). I really _want_ Python 3 to be better, I hope actual use convinces me that it is... There, now I'm committed (or, maybe I should _be_ committed). Thanks, S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 12:43 PM, Martin v. Löwis wrote: I'm not ready for that yet. I think there's plenty of time before we have to agree to such a bleak view. In the mean time let's do something practical like help NumPy port to Py3k. Or, for example, Django... See http://wiki.python.org/moin/PortingDjangoTo3k Well, that's certainly a start. I guess the logical question is: Now what? S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 12:23 PM, Guido van Rossum wrote: On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight wrote: If that happens, it's not true that there's *nowhere* to go. A solution would be to discard 3.x as a failed experiment, take everything that is useful from it and port it to 2.x, and simply continue development from the last 2.x release. And from there, features can be deprecated and then removed a few releases later, as is the usual policy. Been there, done that, on a couple other projects. It's unfortunate when you have to throw out work you've done because it failed to gain traction over the thing you tried to replace, but sometimes that's life. I'm not ready for that yet. I think there's plenty of time before we have to agree to such a bleak view. In the mean time let's do something practical like help NumPy port to Py3k. Or, for example, Django... S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 12:28 PM, Arc Riley wrote: The main thing holding back the community are lazy and/or obstinate package maintainers. If they spent half the time they've put into complaining about Py3 into actually working to upgrade their code they'd be done now. That's an inflammatory, defamatory, unsubstantiated, hyperbolic, sweeping overgeneralization. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 12:35 PM, Antoine Pitrou wrote: Arc Riley gmail.com> writes: +1 on ending with 2.6.I'm the maintainer of 3rd party Python 3-only packages and have ported a few modules that we needed with some help from the 2to3 tool. It's really not a big deal - and Py3 really is a massive improvement. The main thing holding back the community are lazy and/or obstinate package maintainers. If they spent half the time they've put into complaining about Py3 into actually working to upgrade their code they'd be done now. One thing you could do is explain (do you have a blog?) how Py3 is a massive improvement for you as a developer and package maintainer. We core developers obviously agree that py3k is better than 2.x, but the same opinion coming from a third-party developer would carry a different weight. Maybe I haven't been looking, but has anyone collected the "Here's why 3.x is better and here's how it saved my bacon on project XYZ" stories? S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 7:42 PM, Ben Finney wrote: Antoine Pitrou writes: Paul Moore gmail.com> writes: TurboGears - Python 3 "currently unsupported", no timescale given TurboGears is Pylons-based, so I suppose the actual question is when Pylons gets ported. And there's the rub. I expect this general problem of “project FOO depends on library BAR, so there's no point thinking about migration of FOO until BAR is ready for Python 3” will prove to be quite common in widespread projects. There's no "will prove", it is. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 3, 2009, at 1:42 PM, Georg Brandl wrote: sstein...@gmail.com schrieb: On Nov 3, 2009, at 12:28 PM, Arc Riley wrote: The main thing holding back the community are lazy and/or obstinate package maintainers. If they spent half the time they've put into complaining about Py3 into actually working to upgrade their code they'd be done now. That's an inflammatory, defamatory, unsubstantiated, hyperbolic, sweeping overgeneralization. I know a few maintainers, and I have no problem seeing how Arc came to that conclusion. Yah, me neither, but the other two are still cool in my book ;-) S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 4, 2009, at 1:06 AM, Lennart Regebro wrote: 2009/11/3 sstein...@gmail.com : On Nov 2, 2009, at 7:26 PM, James Y Knight wrote: It really sounds like you're saying that switching to 3.x isn't worth the cost to you, but you want to force people (including yourself) to do so anyways, because ...? Because that's the future of Python Or not. Maybe it's a dead branch of Python? Maybe the 3.x line should just be put out of our misery, merged back to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels of deprecation until it just turns into 3.x on its own by running out of numbers. S ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Nov 4, 2009, at 1:39 PM, Carl Trachte wrote: On 11/4/09, sstein...@gmail.com wrote: Maybe the 3.x line should just be put out of our misery, merged back to 2.7, 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels of deprecation until it just turns into 3.x on its own by running out of numbers. As a user, I'm horrified. Granted, I'm not the most high powered user, but . . . my employer is already providing me with a 3.0 Python version on one of my work computers with the expectation that I'll be using it more and more. Sorry to butt in, but is this a joke? I thought all this was hashed out prior to inventing python 3.0. Yes, of course it was a joke. 2.7 won't "turn into" Python 3.x any more that Perl will turn into Ruby. Oh, wait, maybe that was a bad example. The point was, that Python 3.x does not seem to be something that can be "evolved" into and, all along, I have been suggesting that, if Python 3.x is the future, let's let 2.7 be the last of the 2.x series, backport whatever will make it easiest to make 2to3 do as much of the work as possible, and just decide that 2.7 is the end of the line. I shudder to think how much time has been spent hacking things around to make them compatible with the 2.x series while trying to move to 3.x. If 2.x is over, let it be over and let's all focus on moving into Python 3.x with no more time doing other than bug-fixes on 2.x versions of things. S ___ 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] People want CPAN :-)
On Nov 7, 2009, at 3:20 AM, Ben Finney wrote: Guido van Rossum writes: On Fri, Nov 6, 2009 at 2:52 PM, David Lyon wrote: I think buildbot-style test runs for PyPI packages would raise average package quality on PyPI. Please excuse the cross-post but I wanted to make sure that all these "CPAN for Python" discussions got this message and I've lost track of which list which part of what discussion had occurred on. We are currently extending our distutils/Distribute test system to include installation of a broad range of packages as part of the pre- release process for a future release of Distribute and as part of our "smoke" test for distutils/Distribute.Eventually, the goal is to integrate this with our buildbot system but that's a ways off. Our goal is to install a range of packages and, where practicable, actually run and record any errors with the packages' individual test suites. Right now, our "smoke" test only does Twisted and numpy. We've discussed how to collect test results from Twisted trial and we'll be working on similar things for other test runners (nose et al.). For Twisted, we're going to install and test both the current release version and an svn checkout from trunk. It would be an extension of that concept to install and test *all* packages from PyPI but would, obviously, take considerable horsepower (and time) to run such an exhaustive test (especially if we're talking about 2.4?, 2.5, 2.6, 2.7, and 3.1+. Right now I'm extending the configuration file for our smoke test to allow for various test runners (e.g. nose, twisted trial, etc.) so we can "smoke out" more installation problems and/or failed tests after installation. For the first pass, I'm just focusing on Twisted and trial, then numpy, then finding packages that support nose so that I can collect the data on what ran, what passed, and what didn't. I'm planning on collecting this all in a database and making some simple API so that it can be mined by very simple apps later. At the point where that infrastructure is in place, we could pretty easily mine the data to do all kinds of crazy things people have mentioned like: * A ranking system of test coverage * Complexity analysis * Test coverage * Run pylint, pyflakes, 2to3, whatever automated measurement tools over the code * Send test failure messages to maintainers (maybe with opt-in in the new meta-data). * Whatever! We're actively working on this right now; anyone who wants to lend a hand is welcome to contact me off-list and we can talk about what types of things we are needing and where we could use a hand. All in all, I think this could be a big leap forward for the Python distribution ecosystem whether or not we eventually write the PyPan I wished for as a new Perl refugee. Thanks, S ___ 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] People want CPAN :-)
On Nov 7, 2009, at 10:08 AM, Jesse Noller wrote: On Sat, Nov 7, 2009 at 9:30 AM, sstein...@gmail.com > wrote: On Nov 7, 2009, at 3:20 AM, Ben Finney wrote: Guido van Rossum writes: On Fri, Nov 6, 2009 at 2:52 PM, David Lyon > wrote: I think buildbot-style test runs for PyPI packages would raise average package quality on PyPI. Please excuse the cross-post but I wanted to make sure that all these "CPAN for Python" discussions got this message and I've lost track of which list which part of what discussion had occurred on. We are currently extending our distutils/Distribute test system to include installation of a broad range of packages as part of the pre- release process for a future release of Distribute and as part of our "smoke" test for distutils/Distribute.Eventually, the goal is to integrate this with our buildbot system but that's a ways off. Who is "we"? We is the people working on Distribute/distutils. S ___ 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] Proposing PEP 386 for addition
On Dec 10, 2009, at 3:44 AM, Malthe Borch wrote: > On 12/8/09 6:16 PM, Tarek Ziadé wrote: >> I believe that the current situation is as close to consensus as we >> will get on distutils-sig, and in the interests of avoiding months of >> further discussion which won't take things any further, I propose to >> allow final comments from python-dev and then look for a final >> decision. > > Great work, Tarek. I think you've managed to establish a good body of > knowledge on this and the proposal seems sound. > > That said, I think the terms ``LooseVersion`` and ``StrictVersion`` are less > than optimal. Really, what's meant is ``LexicalVersion`` and > ``ChronologicalVersion`` (or ``NumberedVersion``). It's not about strictness > or looseness. I agree about the impreciseness of these terms. I'm not sure what the correct terminology is... > Also, the word "rational" is not familiar to me in the context of versions; > is this term known outside of this proposal? I couldn't find any reference to > it. No, it's a made-up use. I'm not sure if there's some "standard" terminology for referring to versioning schemes... S ___ 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] Pronouncement on PEP 389: argparse?
On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote: > Michael Foord voidspace.org.uk> writes: >> >> I also use -v for verbose in a few scripts (including options to >> unittest when run with python -m). I've seen -V as a common abbreviation >> for --version (I've just used this with Mono for example). > > +1 for letting -v mean "--verbose". This is a really common wish. +1, -v == --verbose S ___ 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] Pronouncement on PEP 389: argparse?
On Dec 14, 2009, at 2:55 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang wrote: >> On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord >>> On 14/12/2009 19:04, Ian Bicking wrote: Another thing I just noticed is that argparse using -v for version where optparse does not (it only adds --version); most of my scripts that use -v to mean --verbose, causing problems. Since this is a poll question on the argparse site I assume this is an outstanding question >>> >>> I also use -v for verbose in a few scripts (including options to unittest >>> when run with python -m). I've seen -V as a common abbreviation for >>> --version (I've just used this with Mono for example). >> >> Many Unix commands accept these switches too . AFAICR there was an >> standard (well ...) set of command line options for Unix systems >> (can't find a link :-/ ) How about this one: http://www.shelldorado.com/goodcoding/cmdargs.html#flagnames S ___ 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] Pronouncement on PEP 389: argparse?
On Dec 14, 2009, at 2:55 PM, Steven Bethard wrote: > But yes, it's a poll right now on the argparse website > (http://code.google.com/p/argparse/) and if you feel strongly about > it, please add your vote there (rather than here). I don't even understand what the poll question is asking. S ___ 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] Pronouncement on PEP 389: argparse?
On Dec 14, 2009, at 3:35 PM, Antoine Pitrou wrote: > Steven Bethard gmail.com> writes: >> >> Please read the PEP if you haven't, particularly the "Why isn't the >> functionality just being added to optparse?" section. I don't believe >> it is sensible to re-implement all of optparse. What Ian Bicking is >> proposing, I believe, is simpler -- adding a few aliases here and >> there so that you don't have to rename so many things when you're >> upgrading from optparse to argparse. > > Although I am of the people who think working modules shouldn't be > deprecated, I > also don't think adding compatibility aliases is a good idea. They only make > the > APIs more bloated and maintenance more tedious. Let's keep the new APIs clean > of > any unnecessary baggage. Agreed. If you want to make an "adapter" to do things like convert 'int' to int, then call the new API then fine, but don't start crufting up a new API to make it 'easier' to convert. All crufting it up does is make it _less_ clear how to use the new API by bring along things that don't belong in it. S ___ 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] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Dec 27, 2009, at 8:02 PM, Tarek Ziadé wrote: > On Mon, Dec 28, 2009 at 1:48 AM, Antoine Pitrou wrote: >> Tarek Ziadé gmail.com> writes: >>> >>> This was ambiguous because it was unclear, as MvL stated, if "2.5" >>> was just "2.5.0" or included >>> versions like "2.5.1" or "2.5.2". >> >> How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5 >> itself? (ditto for "2.5.N" matching only 2.5.N for N >= 1) >> >> This "~=" operator looks murkier than it needs to be IMO. > > An implicit range operator is simpler indeed, and achieves the same goal. > > Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well. It seems to me that all this version range talk relates pretty directly to PEP 386. The Python version numbers themselves are the simplest type of "Normalized Version"s, and since comparisons of "NormalizedVersion"s are defined in PEP 386, and that's really all we're talking about here, shouldn't this really just follow and reference that document? Sure we might like some sugar to make expressing ranges simpler, but shouldn't the explicit meanings of any rules be stated in terms of Normalized Version comparisons? S ___ 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] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Dec 28, 2009, at 8:00 PM, Ben Finney wrote: > The dependency declarations are *not* Python language syntax, and there > is no need to consider Python language syntax in defining them. Agreed. We're also not going to be writing an operating system with them; just simple version range statement. I think that the range expression: 2.5:2.7 is easy to read, immediately understandable, and expresses everything that needs to be said. Yes, it needs to be stated that the ends are inclusive, but after that, it's pretty obvious what it means at a glance Steve ___ 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] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Dec 28, 2009, at 8:35 PM, Tarek Ziadé wrote: > On Tue, Dec 29, 2009 at 2:17 AM, sstein...@gmail.com > wrote: >> >> On Dec 28, 2009, at 8:00 PM, Ben Finney wrote: >> >>> The dependency declarations are *not* Python language syntax, and there >>> is no need to consider Python language syntax in defining them. >> >> Agreed. >> >> We're also not going to be writing an operating system with them; just >> simple version range statement. >> >> I think that the range expression: >> >>2.5:2.7 >> >> is easy to read, immediately understandable, and expresses everything that >> needs to be said. >> >> Yes, it needs to be stated that the ends are inclusive, but after that, it's >> pretty obvious what it means at a glance > > The syntax as it is already defined in the PEP can be used to define > what we need. The part that was unclear was about the meaning of > "2.5". e.g.: 2.5.0 or 2.5.x.. > > It became obvious in the thread that it means 2.5.x. (e.g. a range) so > there's no need to introduce any range operator, wether it's "~=" or a > new notation with ":". > > IOW, since the syntax already present in the PEP is sufficient for our > needs (besides ~=) , and as long as the precise definition of "version > string" is provided, I consider that further discussion about the > syntax itself is more or less bikeshedding. > > I am now rewriting the relevant section of the PEP with the examples > we discussed in this thread, but the operators should stay the same as > they were initially: "<", ">", "<=", ">=", "==" and "!=". Fine by me. My original contention was that we should be referencing that document as it already defined everything we needed and that any syntactic sugar be defined in those terms. The ":" syntactic sugar appeals to me but is, as you say, not necessary. S ___ 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] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Jan 3, 2010, at 7:21 PM, Martin v. Löwis wrote: >>> Requires-Dist: pywin32 (>1.0); sys.platform == 'win32' >> >> Requires-Dist: [Windows] pywin32 1.0+ >> >> That's simpler, shorter, and less ambiguous. Easier to >> parse for package managers. > > Don't you want the PEP to complete? Why this bike-shedding? Really Enough, already! S ___ 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] bug triage
On Jan 6, 2010, at 7:29 AM, Tarek Ziadé wrote: > On Wed, Jan 6, 2010 at 12:24 PM, Michael Foord > wrote: >> On 06/01/2010 11:19, Chris Withers wrote: >>> >>> Hi All, >>> >>> Is there a high volume of incoming bugs to the Python tracker? >>> If so, I'd like to help with triaging. I think I have all the necessary >>> access, what I'm missing is the knowledge of how to set myself up to get >>> notifications of new bugs... >>> >>> How do I do that? >>> >> >> Bug triaging is one of Python's "big needs" and anything you do to help on >> this score would be much appreciated. Particularly reviewing new and >> outstanding issues. > > Another useful triage I think, is to review the oldest bugs (some of > them are > 5 years) > and remove the ones that are not relevant anymore, or duplicate with > newer entries. I was actually thinking about that the other day when I saw that the average age of bugs on the Python tracker was at some hideously large 3 digit number. The 'success' statistic would be to bring that down below, say, 100. S ___ 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] PYTHON3PATH
On Jan 13, 2010, at 12:40 PM, Ralf Schmitt wrote: > "R. David Murray" writes: > >> Please review issue 2375 [1], which is an enhancement request to add a >> PYTHON3PATH environment variable. Because we have elected to have both >> a python and a python3 command, I think this is an issue worth thinking >> about carefully to make sure we are serving the Python user community >> and easing the transition to python3. It could be that "use virtualenv" >> is the best answer, but I feel we should think about it carefully to >> make sure that is really true. >> >> [1] http://bugs.python.org/issue2375 > > The first thing I got while trying to run a python3 prompt few days ago, > was an error. python3 tried to read my $PYTHONSTARTUP file, which used > print statements. people will have to run both python 2 and python 3 > code at the same time. Using different environment variables will make > this easier. Or, how about just removing the antiquated use of environment variables altogether from Python 3 and avoid the issue completely. Python 2 will continue to run as it has, and better solutions will emerge for Python 3 development. Beats the heck out of making a whole duplicate set for PYTHON3BLAHBLAH, yuck! S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
On Jan 14, 2010, at 9:08 AM, Vinay Sajip wrote: >> From: Jesse Noller > >> I'm generally +1 - but given I know that Django 1.2 is slated to >> implement something somewhat similar, I'm interested to hear how this >> proposal meshes with their plan(s).. > > Django 1.2 will most likely not implement logging - they're now in feature > freeze for big features. See Russ Magee's post: > > http://groups.google.com/group/django-developers/msg/4ef81a2160257221 > > They're waiting for a Python decision and (from Russ Magee's post) seem to be > in favour of the changes proposed in PEP 391. If we get these changes into > Python soon, then Django 1.3 may be able to make use of them in its logging > (which encompasses not just configuring Django logging in a settings.py, but > also using logging internally throughout Django where it makes sense to do > so). > > Assuming PEP 391 gets the nod, then after implementing the changes into > Python, I plan to work with the Django community to get improved logging > support in Django for 1.3. That puts a huge +1 on there for me. If we can get this approved and have Django's logging improved *and* avoid a whole pile of duplicate effort in Django that's a huge win. S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
On Jan 21, 2010, at 11:32 PM, Reid Kleckner wrote: > On Thu, Jan 21, 2010 at 5:07 PM, David Malcolm wrote: >> To what extent would it be possible to use (conditionally) use full >> ahead-of-time compilation as well as JIT? > > It would be possible to do this, but it doesn't have nearly the same > benefits as JIT compilation, as Alex mentioned. You could do a static > compilation of all code objects in a .pyc to LLVM IR and compile that > to a .so that you load at runtime, but it just eliminates the > interpreter overhead. That is significant, and I think someone should > try it, but I think there are far more wins to be had using feedback. Wouldn't it be cool if you could run your app (say, with a torture test data set), let the JIT do its magic, then say: "Yes, that's what I want, now save the JIT info as it was in that run and use it as the JIT profile every time you run the app but turn off any JIT profiling during those runs." Get rid of the compiler overhead (with .so trick from quoted message) , and the runtime overhead, but keep the JIT-ness that it already figured out was best. S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
On Jan 21, 2010, at 11:32 PM, Chris Bergstresser wrote: > On Thu, Jan 21, 2010 at 9:49 PM, Tres Seaver wrote: > Generally, that's not going to be the case. But the broader > point--that you've no longer got an especially good idea of what's > taking time to run in your program--is still very valid. I'm sure someone's given it a clever name that I don't know but it's kind of the profiling Heisenbug -- the information you need to optimize disappears when you turn on the JIT optimizer. S ___ 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] Another mercurial repo
On Feb 22, 2010, at 12:04 PM, Dirkjan Ochtman wrote: > On Sun, Feb 21, 2010 at 23:15, Tarek Ziadé wrote: >> Sounds good, thanks > > It's right here: ssh://h...@hg.python.org/repos/distutils2 The checkout URL for non-ssh read-only access is: http://hg.python.org/distutils2/ in case anyone else is searching for it. S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 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 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
