Re: [Python-Dev] Buildbot failures
On Sat, Oct 22, 2011 at 14:30, Andrea Crotti andrea.crott...@gmail.com wrote: On 10/21/2011 10:08 PM, Antoine Pitrou wrote: Hello, There are currently a bunch of various buildbot failures on all 3 branches. I would remind committers to regularly take a look at the buildbots, so that these failures get solved reasonably fast. Regards Antoine. In my previous workplace if someone broke a build committing something wrong he/she had to bring cake for everyone next meeting. The cake is not really feasible I guess, but isn't it possible to notify the developer that broke the build? You just have to keep track and bring all of the cakes that you owe to PyCon. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Fix #13327. Remove the need for an explicit None as the second argument to
On Sun, Nov 6, 2011 at 13:46, Benjamin Peterson benja...@python.org wrote:
2011/11/6 brian.curtin python-check...@python.org:
-
- if (!PyArg_ParseTuple(args, OO:utime,
+ PyObject* arg = NULL;
You could set arg = Py_None here.
+
+ if (!PyArg_ParseTuple(args, O|O:utime,
PyUnicode_FSConverter, opath, arg))
return NULL;
path = PyBytes_AsString(opath);
- if (arg == Py_None) {
+ if (!arg || (arg == Py_None)) {
And then not have to change this.
Ah, good point. I'm going to be making this same change to the other
functions in utime family, so I'll look at updating this one and
change the others accordingly.
___
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] cpython: Remove the old style [...] to denote optional args and show the defaults.
On Tue, Nov 8, 2011 at 14:47, Georg Brandl g.bra...@gmx.net wrote: Am 08.11.2011 21:30, schrieb brian.curtin: http://hg.python.org/cpython/rev/60ae7979fec8 changeset: 73463:60ae7979fec8 user: Brian Curtin br...@python.org date: Tue Nov 08 14:30:02 2011 -0600 summary: Remove the old style [...] to denote optional args and show the defaults. files: Doc/library/os.rst | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Doc/library/os.rst b/Doc/library/os.rst --- a/Doc/library/os.rst +++ b/Doc/library/os.rst @@ -872,7 +872,7 @@ .. versionadded:: 3.3 -.. function:: futimesat(dirfd, path[, (atime, mtime)]) +.. function:: futimesat(dirfd, path, (atime, mtime)=None) Like :func:`utime` but if *path* is relative, it is taken as relative to *dirfd*. If *path* is relative and *dirfd* is the special value :data:`AT_FDCWD`, then *path* Hmm, while the [] are old style, they are still correct when the function doesn't support kwargs. Please revert. (Also, the syntax ``(atime, mtime)=None`` would not be valid Python and at is best confusing.) Georg Backed out. http://hg.python.org/cpython/rev/2636df45b630 ___ 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 405 (proposed): Python 2.8 Release Schedule
On Wed, Nov 9, 2011 at 10:14, Barry Warsaw ba...@python.org wrote: I think we should have an official pronouncement about Python 2.8, and PEPs are as official as it gets 'round here. Thus I propose the following. If there are no objections wink, I'll commit this taking the next available number. Cheers, -Barry PEP: 405 Title: Python 2.8 Release Schedule Version: $Revision$ Last-Modified: $Date$ Author: Barry Warsaw ba...@python.org Status: Final Type: Informational Content-Type: text/x-rst Created: 2011-11-09 Python-Version: 2.8 Abstract This document describes the development and release schedule for Python 2.8. Release Schedule The current schedule is: - 2.8 final Never Official pronouncement == There will never be an official Python 2.8 release. Upgrade path The official upgrade path from Python 2.7 is to Python 3. Copyright = This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: +1. post it 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
Re: [Python-Dev] Is Python insider blog dead?
On Wed, Nov 16, 2011 at 05:40, Jesús Cea j...@jcea.es wrote: Python insider blog was a great idea, trying to open and expose python-dev to the world. A great and necessary idea. But the last post was in August. I wonder if the project is dead... Would be sad :-( http://blog.python.org/ Not dead, there was just a period where I got a little too busy with real life, plus development seemed to slow down for a while. I have a few drafts working (like a post on all of the recent PEP activity) and a few more in my head, but I'd like for it to not be a one-man show :) I've been planning to do another push to get people from around here to write about their big commits, what's going on in the areas of code they work on, interesting bugs they've fixed, etc. Now that you mentioned this, I'll get going quicker and send out details in the next day or so. ___ 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] blog.python.org - help wanted - topics, authors, etc.
As Jesus mentioned earlier today, it has been a while since http://blog.python.org/ was been updated, and even before that it wasn't updated all that often. I'd like to try and get others involved so we can get a more steady flow going and highlight more of the work everyone is doing. The blog aims to keep people up-to-date on what's going on in the development of Python without having to follow every word of this mailing list, the bug tracker, IRC, etc. There are a number of topics that I think would be great for the blog, including but not limited to: * Surveys - Raymond likes to poll people on twitter and has done a bunch of surveys over IRC, usually relating to ideas on APIs. I'd love to put some of these up on the blog and cast a wider net. * New features - Introducing a new module, such as Victor's faulthandler, makes for a great post. As we get closer to 3.3, everyone will be stuffing the commit stream with new features and introducing interesting ones on here would be great. * PEPs - As we all know, PEP discussions can sometimes result in weeks long debates with hundreds of 500 word responses. Summarizing a discussion down to a blog post would probably be helpful for a lot of people. I know I can't follow all of these PEPs all the time, but I'd like to know what's going on. * Problems you're solving - Antoine did a nice post about his changes to remove polling from a number of areas in the code and why he did them. More explanations like this would be great. We run the blog out of a Mercurial repository on BitBucket and do the writing in reStructuredText, then publish via Blogger. There's also a great team of volunteer translators that can get your post out there in 10 languages (see the blog sidebar for the full list). We can also accept guest posts with zero process: you just write and we'll handle the back-end stuff and get your work published. I don't want to make people go through all kinds of hoops if they just want to make a one-time post about something they want to share. If you have any topics - specific or general - that you'd like to see covered, respond here and we'll add them on the tracker. If you're interested in writing, contact me and I'll get you up and running. ___ 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] [PATCH] Adding braces to __future__
On Fri, Dec 9, 2011 at 14:26, Cedric Sodhi man...@gmx.net wrote: IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN DISCUSSED BEFORE, REPLY THAT IT'S SIMPLY NOT GO'NNA HAPPEN, THAT WHO DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE OR SOMETHING SIMILAR, JUST DON'T. Otherwise, read on. I know very well that this topic has been discussed before. On forums. Mailing lists. IRC. Blogs. From person to person, even. And I know equally well, from all those years experiencing argument-turned-debates on the internet, how a (minor|major) fraction of participants make up for their inability to lead a proper debate by speaking the loudest of all, so that eventually quantity triumphs over quality and logic. That ahead; I hope you can try not to fall in that category. Let instead reason prevail over sentimentalism, mislead purism, elitism, and all other sorts of isms which hinder advancement in the greater context. Python has surprised once already: The changes from 2 to 3 were not downwards compatible because the core developers realized there is more to a sustainable language than constantly patching it up until it comes apart like the roman empire. Let's keep that spirit for a second and let us discuss braces, again, with the clear goal of improving the language. End of disclaimer? End of disclaimer! Whitespace-Blocking (WSB) as opposed to Delimiter-Blocking (DB) has reasons. What are those reasons? Well, primarily, it forces the programmer to maintain well readable code. Then, some might argue, it is quicker to type. Two reasons, but of what importance are they? And are they actually reasons? You may guessed it from the questions themselves that I'm about to question that. I don't intend to connote brazen implications, so let me spell out what I just implied: I think anyone who thinks that exclusive WSB is a good alternative or even preferable to DB is actually deluding themselves for some personal version of one of those isms mentioned above. Let's examine these alleged advantages objectively one for one. But before that, just to calm troubled waters a little, allow me bring forward the conclusion: Absolutely no intentions to remowe WSB from Python. Although one might have gotten that impression from the early paragraphs, no intentions to break downwards compatibility, either. What Python needs is an alternative to WSB and can stay Python by still offering WSB to all those who happen to like it. Readable code, is it really an advantage? Two linebreaks, just for the suspense, then: Of course it is. Forcing the programmer to write readable code, is that an advantage? No suspense, the answer is Of course not. Python may have started off as the casual scripting language for casual people. People, who may not even have known programming. And perhaps it has made sense to force -- or shall we say motivate, since you can still produce perfectly obfuscated code with Python -- them to write readably. But Python has matured and so has its clientele. Python does not become a better language, neither for beginners nor for experienced programmers who also frequently use Python these days, by patronizing them and restricting them in their freedom. Readable code? Yes. Forcing people to write readable code by artificial means? No. Practice is evidence for the mischief of this policy: Does the FOSS community suffer from a notorious lack of proper indention or readability of code? Of course we don't. I'm not a native speaker, but dict.cc tells me that what we call mit Kanonen auf Spatzen schießen (firing cannons at sparrows) is called breaking a fly on the wheel in English. I may lack the analogy for the fly on the wheel, which, if I'm not mistaken, used to be a device for torture in the Middle Ages, but I can tell you that the cannon ball which might have struck the sparrows, coincidently caused havoc in the hinterlands. For the wide-spread and professional language Python is today, the idea of forcing people to indent is misguided. These days, it may address a neglible minority of absolute beginners who barely started programming and would not listen to the simple advice of indenting properly, but on the other hand it hurts/annoys/deters a great community of typical programmers for whom DB has long become a de facto standard. For them, it's not a mere inconsistency without, for them, any apparent reason. It's more than the inconvenience not being able to follow ones long time practices, using the scripts one wrote for delimiters, the shortcuts that are usually offered by editor, etc. It also brings about a whole class of new problems which may be anticipated and prevent, yet bear a great potential for new, even hard-to-find bugs (just in case anyone would respond that we had eventually successfully redeemed the mismatched parenthesis problem - at what cost?!). Not just difficult to find, near to
Re: [Python-Dev] Hash collision security issue (now public)
On Wed, Dec 28, 2011 at 19:51, Alex Gaynor alex.gay...@gmail.com wrote: A few thoughts on this: a) This is not a new issue, I'm curious what the new interest is in it. Well they (the presenters of the report) had to be accepted to that conference for *something*, otherwise we wouldn't know they exist. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #12715: Add an optional symlinks argument to shutil functions (copyfile,
On Thu, Dec 29, 2011 at 11:55, antoine.pitrou python-check...@python.org wrote: http://hg.python.org/cpython/rev/cf57ef65bcd0 changeset: 74194:cf57ef65bcd0 user: Antoine Pitrou solip...@pitrou.net date: Thu Dec 29 18:54:15 2011 +0100 summary: Issue #12715: Add an optional symlinks argument to shutil functions (copyfile, copymode, copystat, copy, copy2). When that parameter is true, symlinks aren't dereferenced and the operation instead acts on the symlink itself (or creates one, if relevant). Patch by Hynek Schlawack. files: Doc/library/shutil.rst | 46 - Lib/shutil.py | 101 +--- Lib/test/test_shutil.py | 219 Misc/NEWS | 5 + 4 files changed, 333 insertions(+), 38 deletions(-) diff --git a/Doc/library/shutil.rst b/Doc/library/shutil.rst --- a/Doc/library/shutil.rst +++ b/Doc/library/shutil.rst @@ -45,7 +45,7 @@ be copied. -.. function:: copyfile(src, dst) +.. function:: copyfile(src, dst[, symlinks=False]) Copy the contents (no metadata) of the file named *src* to a file named *dst*. *dst* must be the complete target file name; look at :func:`copy` for a copy that @@ -56,37 +56,56 @@ such as character or block devices and pipes cannot be copied with this function. *src* and *dst* are path names given as strings. + If *symlinks* is true and *src* is a symbolic link, a new symbolic link will + be created instead of copying the file *src* points to. + .. versionchanged:: 3.3 :exc:`IOError` used to be raised instead of :exc:`OSError`. + Added *symlinks* argument. Can we expect that readers on Windows know how os.symlink works, or should the stipulations of os.symlink usage also be laid out or at least linked to from there? Basically, almost everyone is going to get an OSError if they call this on Windows. You have to be on Windows Vista or beyond *and* the calling process has to have the proper privileges (typically gained through elevation - Run as Administrator). ___ 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] cpython: Issue #12715: Add an optional symlinks argument to shutil functions (copyfile,
On Fri, Dec 30, 2011 at 13:39, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 30 Dec 2011 13:29:36 -0600 Brian Curtin br...@python.org wrote: Can we expect that readers on Windows know how os.symlink works, or should the stipulations of os.symlink usage also be laid out or at least linked to from there? I assume it won't make a difference in real life, since symlinks are quite rare under Windows. Basically, almost everyone is going to get an OSError if they call this on Windows. You have to be on Windows Vista or beyond *and* the calling process has to have the proper privileges (typically gained through elevation - Run as Administrator). I still haven't managed to use symlinks under Windows 7, myself. The recipes I've tried didn't work. This might be a place where an image in the documentation would be helpful. I don't think we do that anywhere else, but maybe I could add it to the (sorely out of date and in need of a rebuild) Windows FAQ? What you need to do on Win7 is go to Start All Programs Accessories Command Prompt, but right click on it instead of left click. Choose Run as Administrator, then it'll make you choose yes or no to elevate privileges. At that point, deep in the heart of everyone's favorite operating system, it should acquire the SeCreateSymbolicLink user privilege. After that, os.symlink should work 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] Code reviews
On Mon, Jan 2, 2012 at 12:26, francis franci...@email.de wrote: On 01/02/2012 06:35 PM, Georg Brandl wrote: On 01/02/2012 03:41 PM, Antoine Pitrou wrote: On Mon, 2 Jan 2012 14:44:49 +1000 Nick Coghlanncogh...@gmail.com wrote: He keeps leaving them out, I occasionally tell him they should always be included (most recently this came up when we gave conflicting advice to a patch contributor). Oh, by the way, this is also why I avoid arguing too much about style in code reviews. There are two bad things which can happen: - your advice conflicts with advice given by another reviewer (perhaps on another issue) - the contributor feels drowned under tiresome requests for style fixes (please indent continuation lines this way) Both are potentially demotivating. A contributor can have his/her own style if it doesn't adversely affect code quality. Exactly. Especially for reviews of patches from non-core people, we should exercise a lot of restraint: as the committers, I think we can be expected to bite the sour bullet and apply our uniform style (such as it is). It is tiresome, if not downright disappointing, to get reviews that are basically nothing wrong, but please submit again with one more empty line between the classes, and definitely not the way to attract more contributors. Hi to all member of this list, I'm not a Python-Dev (only some very small patches over core-mentorship list. Just my 2cents here). I would try to relax this conflicts with a script that does the reformatting itself. If that reformatting where part of the process itself do you thing that that would be an issue anymore? I don't think this is a problem to the point that it needs to be fixed via automation. The code I write is the code I build and test, so I'd rather not have some script that goes in and modifies it to some accepted format, then have to go through the build/test dance again. ___ 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 7 clarification request: braces
On Wed, Jan 4, 2012 at 00:30, Stephen J. Turnbull step...@xemacs.org wrote: Benjamin Peterson writes: My goodness, I was trying to make a ridiculous-sounding proposition. In this kind of discussion, that's in the same class as be careful what you wish for -- because you might just get it. I wish we could move onto better discussions than brace placement/existence at this point. *crosses fingers* ___ 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 as a Metro-style App
On Sat, Jan 7, 2012 at 16:07, mar...@v.loewis.de wrote: A then-related question is whether Python 3.3 should be compiled with Visual Studio 11. I'd still be in favor of that, provided Microsoft manages to release that soon enough. I'm guessing the change would have to be done before the first beta? It would have to be released awfully soon, and I haven't heard an estimated release date as of yet. I currently have the default branch mostly ported to VS 2010 save for a number of failed tests, FWIW. ___ 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 as a Metro-style App
On Sat, Jan 7, 2012 at 18:04, Paul Moore p.f.mo...@gmail.com wrote: On 7 January 2012 22:56, Eli Bendersky eli...@gmail.com wrote: A then-related question is whether Python 3.3 should be compiled with Visual Studio 11. I'd still be in favor of that, provided Microsoft manages to release that soon enough. Martin, I assume you mean the Express version of Visual Studio 11 here, right? I would assume that Express should work, but the python.org distributed binaries will use the full version (IIUC, the official distribution uses some optimisations not present in Express - Profile Guided Optimisation, I believe). The bigger issue is how Express doesn't (officially) support x64 builds, unless that's changing in VS11. Perhaps this is better for another topic, but is anyone using the PGO stuff? I know we have PGInstrument and PGUpdate build configurations but I've never seen them mentioned anywhere. ___ 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] Hash collision security issue (now public)
On Sun, Jan 8, 2012 at 16:33, Jim Jewett jimjjew...@gmail.com wrote: In http://mail.python.org/pipermail/python-dev/2012-January/115368.html Stefan Behnel wrote: Can you please configure your mail client to not create new threads like this? As if this topic wasn't already hard enough to follow, it now exists across handfuls of threads with the same title. ___ 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] Script(s) for building Python on Windows
On Mon, Jan 16, 2012 at 14:00, Jason R. Coombs jar...@jaraco.com wrote: The second thing I notice is the scripts assume Visual Studio 2008. And while I recognize that Python is specifically built against Visual Studio 2008 for the official releases and that Visual Studio 2008 may be the only officially-supported build environment, later releases, such as Visual Studio 2010 are also adequate for testing purposes. I’ve been developing Python against Visual Studio 2010 for quite a while and it seems to be more than adequate. And while it’s not the responsibility of the scripts to accommodate such environments, if the scripts could allow for such environments, that would be nice. 2010 is adequate for limited use but the test suite doesn't pass, so I would be hesitant to add support and/or documentation for building with it until we actually support it the same as or in place of 2008. ___ 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] Script(s) for building Python on Windows
On Mon, Jan 16, 2012 at 18:01, Jason R. Coombs My goal in adding the upgrade code was to provide a one-step upgrade for developers with only VS 10 installed. That's what vs-upgrade in jaraco.develop does. Upgrading to 2010 requires some code changes in addition to the conversion, so the process might not be as ripe for automation as the previous versions. For one, a lot of constants in errno had to be updated, then a few places that set certain errnos had to be updated. ___ 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] Switching to Visual Studio 2010
On Tue, Jan 17, 2012 at 14:43, Martin v. Löwis mar...@v.loewis.de wrote: It seems a number of people are interested that the Python trunk switches to Visual Studio 2010 *now*. I've been hesitant to agree to such a change, as I still hope that Python can skip over VS 2010 (a.k.a. VS 10), and go straight to VS 11. However, I just learned that VS 11 supposed ready VS 10 project files just fine, with no need of conversion. So I'd be willing to agree to converting the Python trunk now. It will surely cause all kinds of issues, as any switching of Visual Studio releases has caused in the past. Since a number of people have already started with such a project, I'd like to ask for a volunteer who will lead this project. You get the honor to commit the changes, and you will be in charge if something breaks, hopefully finding out solutions in a timely manner (not necessarily implementing the solutions yourself). Any volunteers? I previously completed the port at my old company (but could not release it), and I have a good bit of it completed for us at http://hg.python.org/sandbox/vs2010port/. That repo is a little bit behind 'default' but updating it shouldn't pose any problems. ___ 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] Switching to Visual Studio 2010
On Tue, Jan 17, 2012 at 15:01, Martin v. Löwis mar...@v.loewis.de wrote: I previously completed the port at my old company (but could not release it), and I have a good bit of it completed for us at http://hg.python.org/sandbox/vs2010port/. That repo is a little bit behind 'default' but updating it shouldn't pose any problems. So: do you agree that we switch? Do you volunteer to drive the change? I do, and I'll volunteer. ___ 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 407: New release cycle and introducing long-term support versions
On Thu, Jan 19, 2012 at 17:54, Martin v. Löwis mar...@v.loewis.de wrote: Ok, so let me add then that I'm worried about the additional work-load. I'm particularly worried about the coordination of vacation across the three people that work on a release. It might well not be possible to make any release for a period of two months, which, in a six-months release cycle with two alphas and a beta, might mean that we (the release people) would need to adjust our vacation plans with the release schedule, or else step down (unless you would release the normal feature releases as source-only releases). FWIW, it might well be that I can't be available for the 3.3 final release (I haven't finalized my vacation schedule yet for August). In the interest of not having Windows releases depend on one person, and having gone through building the installer myself (which I know is but one of the duties), I'm available to help should you need it. ___ 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] Switching to Visual Studio 2010
On Tue, Jan 17, 2012 at 15:11, Brian Curtin br...@python.org wrote: On Tue, Jan 17, 2012 at 15:01, Martin v. Löwis mar...@v.loewis.de wrote: I previously completed the port at my old company (but could not release it), and I have a good bit of it completed for us at http://hg.python.org/sandbox/vs2010port/. That repo is a little bit behind 'default' but updating it shouldn't pose any problems. So: do you agree that we switch? Do you volunteer to drive the change? I do, and I'll volunteer. Is this considered a new feature that has to be in by the first beta? I'm hoping to have it completed much sooner than that so we can get mileage on it, but is there a cutoff for changing the compiler? ___ 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] Switching to Visual Studio 2010
On Sun, Jan 29, 2012 at 14:23, Trent Nelson tr...@snakebite.org wrote: Brian, what are your plans? Are you going to continue working in hg.python.org/sandbox/vs2010port then merge everything over when ready? I have some time available to work on this for the next three weeks or so and would like to help out. Yep, I'm working out of that repo, and any help you can provide would be great. I need to go back over Martin's checklist to find out what I've actually done in terms of moving old stuff around and whatnot, but the basic gist is that it builds and passes most of the test suite save for 5-6 modules IIRC. ___ 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] Switching to Visual Studio 2010
On Wed, Feb 1, 2012 at 15:37, Catalin Iacob iacobcata...@gmail.com wrote: On Tue, Jan 17, 2012 at 9:43 PM, Martin v. Löwis mar...@v.loewis.de wrote: ... P.S. Here is my personal list of requirements and non-requirements: ... - must generate binaries that run on Windows XP I recently read about Firefox switching to VS2010 and therefore needing to drop support for Windows 2000, XP RTM (no service pack) and XP SP1. Indeed, [1] confirms that the VS2010 runtime (it's not clear if the C one, the C++ one or both) needs XP SP2 or higher. Just thought I'd share this so that an informed decision can be made, in my opinion it would be ok for Python 3.3 to drop everything prior to XP SP2. Maybe not very relevant, but [2] has some mention of statistics for Firefox usage on systems prior to XP SP2. [1] http://connect.microsoft.com/VisualStudio/feedback/details/526821/executables-built-with-visual-c-2010-do-not-run-on-windows-xp-prior-to-sp2 [2] http://weblogs.mozillazine.org/asa/archives/2012/01/end_of_firefox_win2k.html We already started moving forward with dropping Windows 2000 prior to this coming up. http://mail.python.org/pipermail/python-dev/2011-May/59.html was the discussion (which links an older discussion) and PEP-11 (http://www.python.org/dev/peps/pep-0011/) was updated accordingly. ___ 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] Switching to Visual Studio 2010
On Wed, Feb 1, 2012 at 15:41, Brian Curtin br...@python.org wrote: On Wed, Feb 1, 2012 at 15:37, Catalin Iacob iacobcata...@gmail.com wrote: On Tue, Jan 17, 2012 at 9:43 PM, Martin v. Löwis mar...@v.loewis.de wrote: ... P.S. Here is my personal list of requirements and non-requirements: ... - must generate binaries that run on Windows XP I recently read about Firefox switching to VS2010 and therefore needing to drop support for Windows 2000, XP RTM (no service pack) and XP SP1. Indeed, [1] confirms that the VS2010 runtime (it's not clear if the C one, the C++ one or both) needs XP SP2 or higher. Just thought I'd share this so that an informed decision can be made, in my opinion it would be ok for Python 3.3 to drop everything prior to XP SP2. Maybe not very relevant, but [2] has some mention of statistics for Firefox usage on systems prior to XP SP2. [1] http://connect.microsoft.com/VisualStudio/feedback/details/526821/executables-built-with-visual-c-2010-do-not-run-on-windows-xp-prior-to-sp2 [2] http://weblogs.mozillazine.org/asa/archives/2012/01/end_of_firefox_win2k.html We already started moving forward with dropping Windows 2000 prior to this coming up. http://mail.python.org/pipermail/python-dev/2011-May/59.html was the discussion (which links an older discussion) and PEP-11 (http://www.python.org/dev/peps/pep-0011/) was updated accordingly. Sorry, hit send too soon... Anyway, I can't imagine many of our users (and their users) are still using pre-SP2. It was released in 2004 and was superseded by SP3 and two entire OS releases. I don't know of a reliable way of figuring out whether or not pre-SP2 is a measurable demographic for us, but I can't imagine it's enough to make us hold up the move for another ~2 years. ___ 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] folding cElementTree behind ElementTree in 3.3
On Tue, Feb 7, 2012 at 22:15, Nick Coghlan ncogh...@gmail.com wrote: Folding the two implementations together in the standard library would mean officially declaring that xml.etree is now an independently maintained fork of Fredrik's version rather than just a snapshot in time of a particular version (which is what it has been historically). Is ElementTree even still maintained externally? I seem to remember Florent going through headaches to get changes into this area, and I can't find an external repository for this code. ___ 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] best place for an atomic file API
On Wed, Feb 15, 2012 at 19:19, Ben Finney ben+pyt...@benfinney.id.au wrote: Charles-François Natali neolo...@free.fr writes: Issue #8604 aims at adding an atomic file API to make it easier to create/update files atomically, using rename() on POSIX systems and MoveFileEx() on Windows (which are now available through os.replace()). It would also use fsync() on POSIX to make sure data is committed to disk. These make it quite OS-specific. That'll happen when solving problems on different OSes. Do you propose a more platform agnostic solution? ___ 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] Status of PEP 397 - Python launcher for Windows
On Fri, Feb 17, 2012 at 23:24, Mark Hammond skippy.hamm...@gmail.com wrote: I'm wondering what thoughts are on PEP 397, the Python launcher for Windows. I've been using the implementation for a number of months now and I find it incredibly useful. To my mind, the specific steps would be: * Arrange for it to be installed with the next release of 3.2 and all future versions - I'm happy to try and help with that, but will probably need some help from Martin. I've been doing some installer work lately and would be willing to help out if I can. Thoughts or comments? Will you be at PyCon, specifically at the language summit? I proposed a side-track to discuss this PEP, and I say side-track since a great majority of the group are not Windows users, so I don't think it's a topic to bring before the entire group. ___ 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] Windows build - fixing compile warnings before VS2010
While some effort has gone on to get the 32-bit build to compile without warnings (thanks for that!), 64-bit still has numerous warnings. Before I push forward on more of the VS2010 port, I'd like to have a clean 2008 build all around so we can more easily track what may have changed. In completing that effort, I'm using a guideline Martin set out in #9566 [0], and please let me know if there are any others to follow. I kind of doubt anyone is against this, but if you are, please speak up before I start pushing changes. While I have your attention, I'd like to throw two other things out there to follow up the above effort: 1. Is anyone opposed to moving up to Level 4 warnings? ...take a deep breath... 2. Is anyone opposed to enabling warnings as errors? [0] http://bugs.python.org/issue9566#msg113574 ___ 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] Windows build - fixing compile warnings before VS2010
On Tue, Feb 21, 2012 at 23:45, mar...@v.loewis.de wrote: Zitat von Brian Curtin br...@python.org: While some effort has gone on to get the 32-bit build to compile without warnings (thanks for that!), 64-bit still has numerous warnings. Before I push forward on more of the VS2010 port, I'd like to have a clean 2008 build all around so we can more easily track what may have changed. Does that *really* have to be a prerequisite for porting to VS 2010? If yes, then my hopes that we can move to VS 2010 before 3.3 are falling... Is it a prerequisite? No. I guess with this question all I'm asking is Can I fix a lot of these warnings without someone wanting to undo them for the sake of cleaner merges or neat hg history? I'd prefer not to take 315 warnings into a compiler change, come out with 550, and not know what potentially went wrong. In a previous company, we changed from 2008 to 2010 by upping the warning level, fixing all warnings, then enabling warnings-as-errors (I'll address this later) - the port to 2010 went nicely and we experienced a very smooth transition. Much more smoothly than 2005 to 2008. I just cut out around 100 warnings last night in 45 minutes, so I don't plan on having this take several months or anything. If I get stuck, I'll just give it up. While I have your attention, I'd like to throw two other things out there to follow up the above effort: 1. Is anyone opposed to moving up to Level 4 warnings? Not sure what this means. What kind of warnings would this get us? MS says This option should be used only to provide lint level warnings and is not recommended as your usual warning level setting. Usually, following MS recommendations is a good thing to do on Windows. But then, the documentation goes on saying For a new project, it may be best to use /W4 in all compilations. This will ensure the fewest possible hard-to-find code defects. The last sentence (but applied to old projects) says it all. Like I mentioned above, my last company jacked everything up to the highest levels and stuck with it, and I think we wrote nicer code. That's really all I can say. No metrics, no strong support, no debate. You could just say no and I'll probably accept it. ...take a deep breath... 2. Is anyone opposed to enabling warnings as errors? The immediate consequence would be that the Windows buildbots break when somebody makes a checkin on Unix, and they cannot easily figure out how to rewrite the code to make the compiler happy. So I guess I'm -1. I didn't think about that, so yeah, I'm probably -1 here as well. ___ 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] Windows build - fixing compile warnings before VS2010
On Wed, Feb 22, 2012 at 10:04, shibturn shibt...@gmail.com wrote:
On 22/02/2012 3:32am, Brian Curtin wrote:
1. Is anyone opposed to moving up to Level 4 warnings?
At that level I think it complains about common things like the do {...}
while (0) idiom, and the unreferenced self parameter of builtin functions.
Presumably you would have to disable those specific warnings and any other
overly annoying ones?
What we did was fix what was reasonable, then disable warnings which
were unreasonable. If that's reasonable, that's how I would do it.
(just to say it one more time: reasonable)
___
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] http://pythonmentors.com/
On Wed, Feb 22, 2012 at 18:21, Éric Araujo mer...@netwok.org wrote: Le 11/02/2012 12:00, Eli Bendersky a écrit : Well, I think the situation is pretty good now. If one goes to python.org and is interested in contributing, clicking on the Core Development link is a sensible step, right? Maybe, depending on your knowledge of jargon. How about rewording that link to “Contributing”? If you want to contribute to development, I think you'll know that a link about development is relevant. If you want to contribute money, a contribute link about development means you have to try again to give away your money. ___ 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] http://pythonmentors.com/
On Thu, Feb 23, 2012 at 01:15, Stephen J. Turnbull step...@xemacs.org wrote: Brian Curtin writes: If you want to contribute to development, I think you'll know that a link about development is relevant. For values of you in experienced programmers, yes. But translators and tech writers don't consider what they do to be development. I don't know what this is saying, but I'll guess it's some suggestion that we should still name the link Contributing. Keep in mind that the current Core Development link on the front page goes directly to http://docs.python.org/devguide/ -- getting this page in people's hands earlier is a Good Thing. However, this is not a correct link from something named Contributing. It would have to say Contributing Code, but then it leaves out docs and translations and our resident spelling bee contestants. Paint the bike shed any way you want except the plain Contributing color, please. ___ 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] Status regarding Old vs. Advanced String Formating
On Feb 24, 2012 6:26 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 24/02/2012 21:37, Martin v. Löwis wrote:
I was of the thought that Old String Formatting |%s % foo| was to be
phased out by Advanced String Formatting |{}.format(foo)|.
This is actually not the case, and never was. Some people would indeed
like to see that happen, and others are strongly opposed.
As a consequence, both APIs for formatting will coexist for a long time
to come (ten years at least); no deprecation is planned.
Regards,
Martin
quote
Quoting the docs http://docs.python.org/py3k/library/stdtypes.html
4.6.2. Old String Formatting Operations
Note
The formatting operations described here are obsolete and may go away in
future versions of Python. Use the new String Formatting in new code.
/quote
I think this is daft because all of the code has to be supported for the
ten years that MVL has suggested. I suggest a plan that says something
like:-
Until Python 3.5 both methods of string formatting will be supported.
In Python 3.6 the the old formating style will be deprecated.
In Python 3.7 the old style is dead.
I'm fully aware that it isn't likely to be that easy, I'm simply trying
to spark ideas from the core developers and users who are in a far better
situation to judge this situation than I am.
-infinity. We can't do that as outlined earlier in the thread.
___
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 414 - Unicode Literals for Python 3
On Mon, Feb 27, 2012 at 17:15, Ethan Furman et...@stoneleaf.us wrote: This is probably a dumb question, but why can't we add u'' back to 3.2? It seems an incredibly minor change, and we are not in security-only fix stage, are we? We don't add features to bug-fix releases. ___ 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] Porting Stories (was PEP 414 - Unicode Literals for Python 3)
On Tue, Feb 28, 2012 at 09:04, Barry Warsaw ba...@python.org wrote: We really need to stop saying that porting to Python 3 is hard, or should be delayed. It's not in the vast majority of cases. Yes, there are warts, and we should continue to improve Python 3 so it gets easier, but by no means is it impossible for most code to be working very nicely on Python 3 today. I've been singing and dancing about the ease of porting for a while now, but it's mostly thanks to the fact that I never had to do any Unicode tomfoolery. Now with this PEP, the game gets easier for a lot more people. Does anyone have a good porting experience they'd like to share, which I could maybe use as a PR effort for us? Barry, I know you wrote some pretty solid coverage of your DBus port. Anyone else? Personal projects or work stuff (assuming its ok to share). blog.python.org has been asleep for a while and a good porting testimonial might be a way to jumpstart it, or I can get it on the python.org front page. If you have anything to share on that front, please contact me directly. ___ 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] Spreading the Python 3 religion (was Re: PEP 414 - Unicode Literals for Python 3)
On Tue, Feb 28, 2012 at 11:51, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Brett Cannon brett at python.org writes: Changes to http://docs.python.org/howto/pyporting.html are welcome. I tried to make sure it exposed all possibilities with tips on how to support as far back as Python 2.5. Right, will take a look. FYI a Google search for python 3 porting guide shows the Wiki PortingToPy3K page, then Brian Curtin's Python 3 Porting Guide, then Lennart Regebro's porting book website, and then the howto referred to above. Possibly the Wiki page and Brian's guide need to link to the howto, as I presume that's the canonical go-to guide - they don't seem to do so currently. Funny that you mention this: just a few minutes ago someone mentioned on twitter that they found and liked the guide I wrote, then I mentioned the howto/porting page since Brett's last message reminded me of it, and I mentioned that I should update and link to howto/porting. In the words of Guido, I will make it so. ___ 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] Backporting PEP 414
On Tue, Feb 28, 2012 at 14:27, Ethan Furman et...@stoneleaf.us wrote: Here's what I know: We don't add features to bug-fix releases. u'' is considered a feature. By not backporting to 3.1 and 3.2 we are not easing the migration pains from 2.x. Let's say it's 2013 and 3.3 has been out for a few months and you want to port your library to Python 3. Why would you worry about 3.1 or 3.2? You certainly see why we're not worried about 3.0. ___ 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] Job! Python Engineer position
On Mon, Mar 12, 2012 at 15:40, Watts, Wendy wwa...@vtrit.com wrote: Hello, my name is Wendy; I am a IT recruiter for vtrIT which is a division of Volt Workforce Technical Solutions located in San Francisco. I have an urgent Senior and Junior Python Engineer positions open for a client located in CA. I am reaching out to you in finding out your status of new opportunity, and if we can speak verbal? Please do not post jobs to this list. j...@python.org is a better location: http://www.python.org/community/jobs/ ___ 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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives
On Mon, Mar 12, 2012 at 19:23, Andrey Petrov sha...@gmail.com wrote:
What such a snippet might look like:
Batteries are included with Python but sometimes they are old and
leaky—this is one of those cases. Please have a look in PyPI for more modern
alternatives provided by the Python community.
What does leaky mean here? Someone's going to see that, think it has
memory leaks, then rant on the internet about how we ship crap and
just document it as so.
Part 2:
I propose we add a new category of package identifiers such as Topic ::
Standard Library Alternative :: {stdlib_package_name} which authors of
libraries can tag themselves under. The documentation warning snippet will
provide a link to the appropriate PyPI query to list packages claiming to be
alternatives to the stdlib package in question.
Automating it to something on PyPI is the not the right answer. People
will use it incorrectly, either in that they'll add it to packages for
which it isn't accurate, and people just flat out won't use it or know
about it. It won't be accurate this way, and anything that we're
documenting needs to be vetted.
It's not often that a great alternative comes up, so I don't see the
manual burden being too great.
___
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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives
On Mon, Mar 12, 2012 at 21:14, Andrey Petrov sha...@gmail.com wrote:
On Mon, Mar 12, 2012 at 8:58 PM, Brian Curtin br...@python.org wrote:
On Mon, Mar 12, 2012 at 19:23, Andrey Petrov sha...@gmail.com wrote:
What such a snippet might look like:
Batteries are included with Python but sometimes they are old and
leaky—this is one of those cases. Please have a look in PyPI for more modern
alternatives provided by the Python community.
What does leaky mean here? Someone's going to see that, think it has
memory leaks, then rant on the internet about how we ship crap and
just document it as so.
I agree Brian and David, the choice of leaky in the wording is poor.
It was supposed to be maintaining the batteries metaphor but it's
clearly ambiguous.
Perhaps something along the lines of...
Batteries are included with Python but for stability and backwards
compatibility, some of the standard library is not always as modern as
alternatives provided by the Python community—this is one of those
cases. Please have a look at PyPI for more cutting-edge alternatives.
Sorry for another color choice on the bikeshed, but I would drop the
word or references to batteries. *We* know what batteries included
means, but there are undoubtedly people who won't get it. It's just
code - let's call it code.
Part 2:
I propose we add a new category of package identifiers such as Topic ::
Standard Library Alternative :: {stdlib_package_name} which authors of
libraries can tag themselves under. The documentation warning snippet will
provide a link to the appropriate PyPI query to list packages claiming to be
alternatives to the stdlib package in question.
Automating it to something on PyPI is the not the right answer. People
will use it incorrectly, either in that they'll add it to packages for
which it isn't accurate, and people just flat out won't use it or know
about it. It won't be accurate this way, and anything that we're
documenting needs to be vetted.
It's not often that a great alternative comes up, so I don't see the
manual burden being too great.
There are a dozen or more urllib/httplib/pycurl competitors on PyPI,
and new ones spring up all the time. I'm not sure how we would go
about objectively blessing the best official option at any given
moment, or how frequently we would have to do this.
The same way we choose to accept libraries into the standard library.
New ones spring up all the time - mature, proven, and widely used ones
do not. If someone thinks libfoo is ready, they suggest it. If we
haven't heard of it, the conversation ends. If we have people who know
it, maybe we have them look deeper and figure out if it's something we
can put our stamp on just like we might with the recent talk of
experimental package inclusion.
With self-identifying, we could sort by some sort metric (monthly
downloads? magical score?) and create a somewhat-actionable list.
Downloads don't mean the code is good. Voting is gamed. I really don't
think there's a good automated solution to tell us what the
high-quality replacement projects are.
___
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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives
On Tue, Mar 13, 2012 at 14:13, Kenneth Reitz m...@kennethreitz.com wrote: I think the cheesehop trove classifiers would be the ideal way to agnostically link to a page of packages related to the standard package in question. No need for sort order. Randomize the order for all I care. We still need to ensure we're suggesting quality projects. It doesn't make sense for us to suggest alternatives that we wouldn't want to use ourselves by just polling some list that anyone can get on. This is documentation that receives hundreds of thousands of views a month*. We need to be picky about what goes in it. The beauty of this solution is that packages that aren't maintained won't add the appropriate classifier to their package, and therefore not show up in the list. Just because it's maintained doesn't mean it's not garbage. I think we really need to start every project off with a 0 and make them prove that they're a 10. Just being active means nothing. * http://www.python.org/webstats/usage_201202.html#TOPURLS - I don't know what page Documentation means since it doesn't have a specific link, but whatever page that is got hit 960K times in February. ___ 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 install layout and the PATH on win32
On Tue, Mar 13, 2012 at 14:43, VanL van.lindb...@gmail.com wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows, with
a side order of making the PATH work better.
Short version:
1) The layout for the python root directory for all platforms should be as
follows:
stdlib = {base/userbase}/lib/python{py_version_short}
platstdlib = {base/userbase}/lib/python{py_version_short}
purelib = {base/userbase}/lib/python{py_version_short}/site-packages
platlib = {base/userbase}/lib/python{py_version_short}/site-packages
include = {base/userbase}/include/python{py_version_short}
scripts = {base/userbase}/bin
data = {base/userbase}
I'm familiar with the scripts/bin change. I take it the rest of that
stuff matches *nix? Text later on seems to support this, so I think
I'm on board with it.
2) On Windows, the python executable (python.exe) will be in the bin
directory. That way the installer can optionally add just that directory to
the PATH to pick up all python-related executables (like pip, easy_install,
etc).
I'm updating my installer patch to do exactly this. After talking with
Dino from Microsoft's Python Tools team, we're also going to add an
additional registry key for them to find that bin/ path.
I have talked with a number of people at PyCon, including Tarek and MvL.
Nobody objected, and several thought it was a good idea.
Martin and I spoke on Friday and at least the bin/ folder and Path
stuff are acceptable and I'm working on the code for those.
To add just a little more complication, the python binary is placed within
the binaries directory when a virtualenv is created, leading to an
inconsistency between regular python installs and virtualenvs.
If that virtualenv PEP is also accepted for 3.3, I think we can take
care of inconsistencies there (at least moving forward).
___
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] 2012 Language Summit Report
As with last year, I've put together a summary of the Python Language Summit which took place last week at PyCon 2012. This was compiled from my notes as well as those of Eric Snow and Senthil Kumaran, and I think we got decent coverage of what was said throughout the day. http://blog.python.org/2012/03/2012-language-summit-report.html If you have questions or comments about discussions which occurred there, please create a new thread for your topic. Feel free to contact me directly if I've left anything out or misprinted anything. ___ 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] 2012 Language Summit Report
On Wed, Mar 14, 2012 at 13:52, Georg Brandl g.bra...@gmx.net wrote: Thanks for the comprehensive report (I'm still reading). May I request for the future that you also paste a copy in the email to the group, for purposes of archiving and ease of discussing? (Just like we also post PEPs to python-dev for discussion even when they are already online.) Certainly -- good idea. I have a few updates and corrections to make this evening, then I'll get a copy of it posted. ___ 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] 2012 Language Summit Report (updated, included here)
it (update: Nick will be the PEP czar). PEP 397 Inclusion = Without much of a Windows representation at the summit, discussion was fairly quick, but it was pretty much agreed that PEP `397`_ was something we should accept. Brian Curtin spoke in favor of the PEP, as well as mentioning ongoing work on the Windows installer to optionally add the executable's directory to the Path. After discussion outside of the summit, it was additionally agreed upon that the launcher should be installed via the 3.3 Windows installer, while it can also live as a standalone installer for those not taking 3.3. Additionally, there needs to be some work done on the PEP to remove much of the low-level detail that is coupled too tightly with the implementation, e.g., explaining of the location of the ``py.ini`` file. speed.python.org After generous hardware donations, the http://speed.python.org site has gone live and is currently running PyPy benchmarks. We need to make a decision on what benchmarks can be used as well as what benchmarks *should* be used when it comes to creating a Python 3 suite. As we get implementations on Python 3 we'll want to scale back 2.7 testing and push forward with 3.x. The project suffers not from a technological problem but from a personnel problem, which was thought to be another area that funding could be used for. However, even if money is on the table, we still need to find someone with the time, the know-how, and the drive to complete the task. Ideally the starting task would be to get PyPy and CPython implementations running and comparing. After that, there are a number of infrastructure tasks in line. PEP 411 Inclusion = PEP `411`_ proposes the inclusion of provisional packages into the standard library. The recently discussed ``regex`` and ``ipaddr`` modules were used as examples of libraries to include under this PEP. As for how this inclusion should be implemented and denoted to users was the major discussion point. It was first suggested that documentation notes don't work -- we can't rely only on documentation to be the single notification point, especially for this type of code inclusion. Other thoughts were some type of flag on the library to specify its experimental status. Another thought was to emit a warning on import of a provisional library, but it's another thing that we'd likely want to silence by default in order to not affect user code in the hopes that developers are running their test suite with warnings enabled. However, as with other times we've gone down this path, we run the risk of developers just disabling warnings all together if they become annoying. As has been suggested on python-dev, importing a provisional library from a special package, e.g., ``from __experimental__ import foo``, was pretty strongly discouraged. If the library gains a consistent API, it penalizes users once it moves from provisional status to being officially accepted. Aliasing just exacerbates the problem. The PEP boils down to being about process, and we need to be sure that libraries being included use the ability to change APIs very carefully. We also need to make people, especially the library author, aware of the need to be responsive to feedback and open to change as the code reaches a wider audience. Looking back, Jesse Noller suggested ``multiprocessing`` would have been a good candidate for something like this PEP is suggesting. Around this time, it was suggested that Michael Foord's `mock`_ could gain some provisional inclusion within ``unittest``, perhaps as ``unittest.mock``. Instead, given ``mock``'s stable API and wide use among us, along with the need for a mocking library within our own test suite, it was agreed to just accept it directly into the standard library without any provisional status. While on the topic of ``regex``'s role within the PEP came an idea from Thomas Wouters that ``regex`` be introduced into the standard library, bypassing any provisional status. From there, the previously known ``re`` module could be moved to the ``sre`` name, and there didn't appear to be any dissenting opinion there. It should also be noted to users of provisional libraries that the library maintainers would need to exercise extreme care and be very conservative in changing of the APIs. The last thing we want to do is introduce a good library but as a moving target to its users. Keyword Arguments on all builtin functions == As recently came up on the tracker, it was suggested that wider use of keyword arguments in our APIs would likely be a good thing. Gregory P. Smith suggested that we leave single-argument APIs alone, which was agreed upon. However, the overall change got some push back as change for change's sake. In order to support this, the ``PyArg_ParseTuple`` function would need to do more work, and it's already known to be somewhat slow. Alternatively, ``PyArg_Parse
Re: [Python-Dev] Python install layout and the PATH on win32
On Fri, Mar 16, 2012 at 19:53, Mark Hammond skippy.hamm...@gmail.com wrote: For the sake of brain-storming, how about this: * All executables and scripts go into the root of the Python install. This directory is largely empty now - it is mainly a container for other directories. This would solve the problem of needing 2 directories on the PATH and mean existing tools which locate the executable would work fine. How are existing tools locating the executable which would break with a change to bin? As I posted on the tracker, the way which pops in my mind would be to look for C:\\Python%d%d % (x, y) but that's already pretty broken. The people I talked to at PyCon about this were Dino from Microsoft and he nudged the guy next to him to ask the same question (I seem to remember this guy worked for an IDE) -- both of them just wanted to be sure they can still find python.exe's location via the registry, which will be fine. I think we'll add a key to go along with InstallPath - BinaryPath probably makes sense. * If cross-platform consistency was desired, then we could consider making other platforms match this. However, if there are issues which might prevent this happening for other platforms (eg, the risk of breaking other 3rd party tools, conventions on the platform ,etc) then it might be worth conceding these considerations apply equally to the Windows installs and we just live with this platform difference. I don't think we're going to defeat the Unix army with their fleets of distro packagers and torch wielding purists. If anyone's going to move, my money's on Windows. ___ 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] inspect.py change for pygame
On Sun, Mar 18, 2012 at 23:13, ncdave4life ncdave4l...@gmail.com wrote: I noticed that pydoc doesn't work for pygame under python 3.2.1 for Win32: NotImplementedError: scrap module not available (ImportError: No module named scrap) I made a small patch to inspect.py to solve the problem (I just added a try/expect around the failing statement in ismethoddescriptor). Here's the diff: http://www.burtonsys.com/python32/inspect.diff http://www.burtonsys.com/python32/inspect.diff With that patch, pydoc works with pygame, and reports just a few issues: *scrap* = pygame.MissingModule object *sndarray* = pygame.MissingModule object *surfarray* = pygame.MissingModule object Sorry, I'm a newbie to python-dev, so please forgive my ignorance, but what do I need to do get this fix (or something similar) into a future release? Patches to fix Python should be posted to http://bugs.python.org/. From there they'll be classified, reviewed, and if all is well, committed. It's much easier for patches to be tracked on there instead of email. ___ 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 install layout and the PATH on win32
On Tue, Mar 20, 2012 at 10:52, Martin v. Löwis mar...@v.loewis.de wrote: In hearing from a couple people who teach python to beginners, this is a substantial hurdle - the first thing they need to do is to edit their environment to add these directories to the PATH. This is something I never understood. On Windows, it's custom to launch programs from the start menu, and Python is easy enough to find on the start menu (e.g. by typing Python). Why do people want to launch it by opening a shell window, then typing python? I've never thought about doing it otherwise. If I want to run the C:\Users\brian\example\sample.py script, I'd open a CMD and move to the example directory and execute the sample script. The class of about 60 people I taught a few years back at a previous employer all did the same thing without me specifying. Everyone was used to working in the command line for other tasks, from using other languages to running our products, so it was natural to them to run it that way. In any case, I have given up my resistance to the feature request for automatic path fiddling several years ago, and was since waiting for a contribution of a patch that makes it happen. I'm working on the changes we discussed at PyCon. http://bugs.python.org/issue3561 has an version of the patch doing it the old way - I hope to have the new way figured out soon. ___ 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 install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
On Thu, Mar 22, 2012 at 12:59, Paul Moore p.f.mo...@gmail.com wrote: Note - that is not Regularizing the layout. You have not made any changes to OS/2 (which matches Windows at the moment). I think that would be a wasted effort with OS/2 entering unsupported mode in 3.3, and OS/2 specific code being removed in 3.4. ___ 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 install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
On Thu, Mar 22, 2012 at 13:57, VanL van.lindb...@gmail.com wrote: Honestly, I didn't expect that much resistance. None of the people I talked to in person even cared, or if they did, they thought that consistency was a benefit. But now that virtualenvs are going in in 3.3, I see this as the last good chance to change this. I was one of these people, first finding out just about the Scripts/bin change, and my thought was JFDI. The rest of it seems fine to me - I say let's go for it. Personally, my main concerns are around procedure and policy. The more the discussion goes on, the more I feel that there should be a PEP to capture the details of the debate clearly. Too much is getting lost in the noise. And I think you should provide a clear statement of why this issue is important enough to justify violating the backward compatibility policies. As Mark said (I think it was Mark...) if this had been proposed for 3.0, it would have been fine. Now we're at 3.2 with 3.3 close to release, and it just seems too late to be worth the risk. One plus point about your posting this separately. It's made me think through the issue in a bit more detail, and I'm now a solid -1 on the proposal. I have been trying at various PyCons and in various conversations to move this for years. No one cares. The current urgency is driven by pyvenv - changes now will be much, much easier than changes later. Again, I am happy to write a PEP. If I were to summarize (on this issue only): 1. The current backwards compatibility hit is minimal; I would be happy to contact and provide patches to the four packages I have found (and anyone else who wants one). Backwards compatibility in the future will probably be harder to deal with. 2. There are advantages to cross-platform consistency and to virtualenv-based development. I believe that these will grow in the future. 3. Most people won't care. To the extent that people notice, I think they will appreciate the consistency. The virtualenv point, to me, is a strong one. I think we have an opportunity right now to make an adjustment, otherwise we're locked in again. ___ 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 install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)
2012/3/22 VanL van.lindb...@gmail.com: Open Issues: If we do put python.exe on PATH (whether it's in bin or not), we have to debate how to handle people having multiple versions of python on their machine. In a post-PEP 397 world, no Python is the machine default - .py files are associated with py.exe, not python.exe, so we have to consider the following 3 commands being run from a shell prompt: 1. myprog.py 2. py myprog.py 3. python myprog.py 1 and 2 will always do the same thing. However, 3 could easily do something completely different, if the Python in the #! line differs from the one found on PATH. To me, this implies that it's better for (3) to need explicit user action (setting PATH) if it's to do anything other than give an error. But maybe that's just me. I've been hit too often by confusion caused by *not* remembering this fact. I'm not sure how widely used #1 is. I can't remember coming across any bug reports or posts around the web where the example command line just uses the Python chosen by the file association. I would suspect it's especially rare in the current time when many people are running a lot of versions of Python. Right now I have 2.6, 2.7, 3.1, 3.2, and 3.3, all installed in some different order, and I couldn't tell you which of those I installed the latest bugfix release for. That last one wins the race when it comes to file associations, and I've never paid attention to the installer option. #3 *will* require explicit user action - the Path setting is off by default. For as much as it's an advanced feature, it's really helpful to beginners. If you just want to type in python and have it work, the Path option is great. That's not to say the launcher isn't *also* a good thing. If you're a first timer and install Python 3.3 and want to run a tutorial - add Python to the path, type python, and you're on your way. If you're an advanced user and you want to write and run code on Python 3.3, do the same. If you're even more advanced and are doing multi-version work, the launcher is a helpful alternative. One possible response here is that the moving of the python.exe binary and the setting of the PATH would be tied to an unchecked-by-default installer option, making an explicit user choice needed to invoke the new functionality. I ended up typing out the above while missing this paragraph...but, bingo. Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have all expressed that they have existing tools that would break and would need to be adjusted to match the new location of the python.exe, because that location is assumed to be at the root of the python install. Isn't the proposed BinaryDir registry key helpful here? It's not like we're telling people to fend for themselves -- we'll tell you where it's at. A related issue is that this portion of the proposal has met with some resistance, but not much support here on Python-dev. The reason for that is selection bias: Those who are on Python-dev are much more likely to have tools that do advanced things with Python, such as introspect on the location of the binary, and are also much more likely to be comfortable with things like editing the PATH on windows. In contrast, the people that have trouble with this issue are those that are newest to Python and programming generally - those for whom editing the PATH is a challenge and whom are likely to be confused by the distinction between python.exe and a python program - and why, even after they add python to the path, the python program is not directly executable. I still don't really get how this portion of the proposal, the python.exe move to bin, is holding people up. If you're using the launcher, the change is invisible. If you're using a setup where bin is on the Path, the change is invisible. File associations? Invisible. If you're typing out the full path, you have to type bin in the middle -- this kind of sucks but I think we'll live. I get that tools could be affected. I had two IDE makers at PyCon immediately throw up red flags to this change. I think one of them was about to charge the stage during my talk. When it was mentioned that we could point them to the proper location, they breathed a sigh of relief and said cool, do it. If a registry key pointing you to python.exe (rather, the directory) right now in Python 3.3 works, why doesn't another one pointing you to python.exe in Python = 3.3 work? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)
On Thu, Mar 22, 2012 at 18:26, Ethan Furman et...@stoneleaf.us wrote: Given the cost of the change, and the advent of the PEP-397 Launcher, I also vote -1. Can you provide some justification other than a number? It's a pretty cheap change and the launcher solves somewhat of a different problem. ___ 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] Rename time.steady(strict=True) to time.monotonic()?
On Mar 23, 2012 6:25 PM, Victor Stinner victor.stin...@gmail.com wrote: Hi, time.steady(strict=True) looks to be confusing for most people, some of them don't understand the purpose of the flag and others don't like a flag changing the behaviour of the function. I propose to replace time.steady(strict=True) by time.monotonic(). That would avoid the need of an ugly NotImplementedError: if the OS has no monotonic clock, time.monotonic() will just not exist. So we will have: - time.time(): realtime, can be adjusted by the system administrator (manually) or automatically by NTP - time.clock(): monotonic clock on Windows, CPU time on UNIX - time.monotonic(): monotonic clock, its speed may or may not be adjusted by NTP but it only goes forward, may raise an OSError - time.steady(): monotonic clock or the realtime clock, depending on what is available on the platform (use monotonic in priority). may be adjusted by NTP or the system administrator, may go backward. time.steady() is something like: try: return time.monotonic() except (NotImplementError, OSError): return time.time() time.time(), time.clock(), time.steady() are always available, whereas time.monotonic() will not be available on some platforms. Victor This seems like it should have been a PEP, or maybe should become a PEP. ___ 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] Rename time.steady(strict=True) to time.monotonic()?
On Fri, Mar 23, 2012 at 18:38, Yury Selivanov yselivanov...@gmail.com wrote: On 2012-03-23, at 7:28 PM, Brian Curtin wrote: This seems like it should have been a PEP, or maybe should become a PEP. Why? AFAIK Victor just proposes to add two new functions: monotonic() and steady(). We just previously had Drop time.monotonic() function, rename time.wallclock() to time.steady() checked in a few weeks ago, and now we're renaming a variation on time.steady to time.monotonic? What's the next move? I'm not paying close attention here but there's a lot of movement going on. Figuring out the API before we get too deep is probably a good idea. ___ 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 install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
On Sat, Mar 24, 2012 at 07:19, Nick Coghlan ncogh...@gmail.com wrote: On Sat, Mar 24, 2012 at 4:35 AM, PJ Eby p...@telecommunity.com wrote: Just dumping things in a directory adjacent to the corresponding scripts is the original virtualenv, and it still works just dandy -- most people just don't *know* this. (And again, if there are tools out there that *don't* support single-directory virtualenvs, the best answer is probably to fix them.) Not to mention that CPython gained native support for that layout in 2.6 via __main__.py files (although I stuffed up and forgot to add it to the What's New before the release). I'll chime in on the -1 side here as well. If you want *easy* cross-platform execution of __main__, use the -m switch. I love the -m option but what does it have to do with unifying the install layout? One is about executing __main__ and one is about a directory structure. Indeed, avoiding such cross-platform inconsistencies with regards to the location of stdlib modules was one of the major arguments in favour of adding the original incarnation of the switch way back in Python 2.4. Ok, so it is about directory structure, but about the standard library. Since part of this proposal is about Scripts vs. bin, how does -m help you there? ___ 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] Playing with a new theme for the docs, iteration 2
On Sun, Mar 25, 2012 at 14:50, Andrew Svetlov andrew.svet...@gmail.com wrote: I like to see new schema only for 3.3 as sign of shiny new release. Please don't do this. It will result in endless complaints. ___ 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] AUTO: Jon K Peck is out of the office (returning 03/30/2012)
On Sun, Mar 25, 2012 at 05:00, Jon K Peck p...@us.ibm.com wrote: I am out of the office until 03/30/2012. I will be out of the office through Friday, March 30. I expect to have some email access but may be delayed in responding. Note: This is an automated response to your message Python-Dev Digest, Vol 104, Issue 91 sent on 03/25/2012 1:19:50. This is the only notification you will receive while this person is away. Enjoy your vacation. ___ 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] Integrating the PEP 397 launcher
After talking with Martin and several others during the language summit and elsewhere around PyCon, PEP 397 should be accepted. I don't remember who, but some suggested it should just be a regular old feature instead of going through the PEP process. So...does this even need to continue the PEP process? Vinay - is the code you have on bitbucket ready to roll into CPython, thus into the installer? ___ 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] Integrating the PEP 397 launcher
On Thu, Mar 29, 2012 at 17:45, Benjamin Peterson benja...@python.org wrote: 2012/3/29 Brian Curtin br...@python.org: After talking with Martin and several others during the language summit and elsewhere around PyCon, PEP 397 should be accepted. I don't remember who, but some suggested it should just be a regular old feature instead of going through the PEP process. So...does this even need to continue the PEP process? If you have a PEP and it's accepted, what would be the difference? In the end? Nothing. It was a comment about this whole process not even needing to exist. ___ 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] Integrating the PEP 397 launcher
On Thu, Mar 29, 2012 at 18:08, Glenn Linderman v+pyt...@g.nevcal.com wrote: All it needs is official acceptance now, and integration into the release, no? If it wasn't clear, this is what I said in the first post. ___ 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] Integrating the PEP 397 launcher
On Thu, Mar 29, 2012 at 22:48, mar...@v.loewis.de wrote: Now that we do have the PEP, I think that should be done properly. I thought you offered to rewrite it. There are definitely areas that I would like to work on, especially pulling implementation details out and replacing with, as you say, end-user prose. For example, some part of a doc tells you to call some function with a specific parameter to figure out where py.ini should be found - it needs to be replaced with an example directory. So: I can offer to rewrite the PEP to give a full specification of the feature. It might be that I still need some help to provide end-user prose in the PEP if people would want to see that as well. I would be much better at proposing the end-user stuff than the specification. ___ 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] Issue13210 : Support Visual Studio 2010
2012/3/31 Kristján Valur Jónsson krist...@ccpgames.com: Hi, Does anyone object if I submit my patches sxs.patch and errnomodule.patch? These allow python to work correctly when built with vs2010. There is also the PCBuild10.patch, but that can wait. I'm sure a number of people are regularly building python using vs2010 using their own modified solutions, but having the sources in a constant state of patching is a nuiscance so I think we ought to at least make the source code work with it, regardless of having a proper solution for it. Go ahead. As listed on the issue, there is a repo where building from VS2010 works but the port is not complete as not all tests are passing. I will complete it. ___ 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] .{git,bzr}ignore in cpython HG repo
On Fri, Mar 30, 2012 at 10:00, Matěj Cepl mc...@redhat.com wrote:
Why does HG cpython repo contains .{bzr,git}ignore at all?
IMHO, all .*ignore files should be strictly repository dependent and they
should not be mixed together.
For what reason? Are the git or bzr files causing issues on HG?
___
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] .{git,bzr}ignore in cpython HG repo
On Sun, Apr 1, 2012 at 17:31, Matěj Cepl mc...@redhat.com wrote: On 1.4.2012 23:46, Brian Curtin wrote: For what reason? Are the git or bzr files causing issues on HG? No, but wrong .gitignore causes issues with git repo obtained via hg-fast-import. If it is meant as an intentional sabotage of using git (and bzr) for cpython, then that's the only explanation I can understand, otherwise it doesn't make sense to me why these files are in HG repository at all. Then you won't understand. Sometimes things get out of date when they aren't used or maintained. You're welcome to fix the problem if you're a Git user, as suggested earlier. ___ 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] Preparation for VS2010 - MSDN for Windows build slaves, core devs
Hi all, If you are a running a build slave or otherwise have an MSDN account for development work, please check that your MSDN subscription is still in effect. If the subscription expired, please let me know in private what your subscriber ID is along with the email address you use for the account. Eventually we're switching to VS2010 so each slave will need to have that version of the compiler installed. Thanks ___ 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] Remove of w9xopen
On Tue, Apr 3, 2012 at 14:59, Andrew Svetlov andrew.svet...@gmail.com wrote: I filed the issue http://bugs.python.org/issue14470 for removing w9xopen from subprocess as python 3.3 has declaration about finishing support of Windows 2000 and Win9x family. But, as I see, VC project for building w9xopen is still present. Should we remove it as well? Please leave it in for the time being. Feel free to assign the issue to me and I'll take care of it once we've officially transitioned to VS2010. ___ 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] Upgrading tcl/tk deps
Can someone let me in on the process to upgrade tcl and tk on svn.python.org? For the VS2010 port it looks like I need to upgrade since the 8.5.9 versions do not work. They use link options that choke on 2010. Taking 8.5.11, which is the current release, seems to work out alright so far. It seems as easy as downloading the tarball and checking that in. Am I missing any official process here? ___ 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] Upgrading tcl/tk deps
On Mon, Apr 9, 2012 at 18:41, Terry Reedy tjre...@udel.edu wrote: In particular, it should include a recent fix so that French keyboards work with tk/tkinter and hence Idle better than now. There has been more than one complaint about this. Do you know when this was fixed or have any information about it? Tcl and Tk 8.5.11 were released Nov 4, 2011. If it was fixed after that I can look into patching our copy of whatever projects are affected. ___ 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] Upgrading tcl/tk deps
On Mon, Apr 9, 2012 at 20:53, Terry Reedy tjre...@udel.edu wrote: On 4/9/2012 7:53 PM, Brian Curtin wrote: On Mon, Apr 9, 2012 at 18:41, Terry Reedytjre...@udel.edu wrote: In particular, it should include a recent fix so that French keyboards work with tk/tkinter and hence Idle better than now. There has been more than one complaint about this. Do you know when this was fixed or have any information about it? Tcl and Tk 8.5.11 were released Nov 4, 2011. If it was fixed after that I can look into patching our copy of whatever projects are affected. The patch is specifically for tkMacOS, 29/1/12 http://core.tcl.tk/tk/info/9844fe10b9 so it apparently does not affect Windows or what we include with Windows build. But it was a show stopper for some French Mac users, including one professor who wanted to use Python for an undergraduate course. On Mar 4, Ned Daily wrote on idle-sig list: Update: The fix has now been released in the latest ActiveState Tcl 8.5 for Mac OS X release (8.5.11.1) available here: http://www.activestate.com/activetcl/downloads It appears to fix the French keyboard tilde problem and other similar problems with composite characters, like Option-U + vowel to form umlauted vowels in the U.S. input method. Many thanks to Adrian Robert, Kevin Walzer, and the ActiveState team for addressing this nasty problem. If you install ActiveState Tcl 8.5.x, it will automatically be used by the python.org 2.7.x, 3.2.x, and 3.3.x 64-bit/32-bit Pythons for OS X 10.6 and 10.7. It will *not* be used by the Apple-supplied system Pythons or by 32-bit-only python.org Pythons. More details here: http://www.python.org/download/mac/tcltk/ === So the latest A.S. Windows release should be fine as the base for our Windows release. Terry The Windows build works with 8.5.11 so I imagine we would just use that. If anyone wants to pull it all out and make it use some third-party installer that's up to them. I can try applying the relevant patches to the 8.5.11 we have, but I don't really have the time or knowledge to test them. I don't know anything about tcl/tk and don't know a whole lot about Macs. ___ 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] A couple of PEP 418 comments
On Fri, Apr 13, 2012 at 11:29, Victor Stinner I will move the precision of monotonic clock of Windows 9x info into this table. I would just remove it entirely. It's not relevant since it's not supported. ___ 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] cpython: Fix #10854. Make use of the new path and name attributes on ImportError
On Mon, Apr 16, 2012 at 09:52, Brett Cannon br...@python.org wrote: On Mon, Apr 16, 2012 at 07:19, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 16 Apr 2012 07:10:31 +0200 brian.curtin python-check...@python.org wrote: PyErr_SetFromImportErrorWithNameAndPath Apparently this new function isn't documented anywhere. I forgot to write the docs for it when I committed Brian's code. Brian, do you mind writing the docs for the two functions? I'll take care of it today. ___ 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] cpython: Fix #10854. Make use of the new path and name attributes on ImportError
On Mon, Apr 16, 2012 at 09:54, Brian Curtin br...@python.org wrote: On Mon, Apr 16, 2012 at 09:52, Brett Cannon br...@python.org wrote: On Mon, Apr 16, 2012 at 07:19, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 16 Apr 2012 07:10:31 +0200 brian.curtin python-check...@python.org wrote: PyErr_SetFromImportErrorWithNameAndPath Apparently this new function isn't documented anywhere. I forgot to write the docs for it when I committed Brian's code. Brian, do you mind writing the docs for the two functions? I'll take care of it today. Done. http://hg.python.org/cpython/rev/5cc8b717b38c ___ 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] cpython: Add documentation for the new PyErr_SetFromImport* functions
On Mon, Apr 16, 2012 at 18:02, Georg Brandl g.bra...@gmx.net wrote: On 16.04.2012 22:14, brian.curtin wrote: http://hg.python.org/cpython/rev/5cc8b717b38c changeset: 76363:5cc8b717b38c user: Brian Curtinbr...@python.org date: Mon Apr 16 15:14:36 2012 -0500 summary: Add documentation for the new PyErr_SetFromImport* functions files: Doc/c-api/exceptions.rst | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/Doc/c-api/exceptions.rst b/Doc/c-api/exceptions.rst --- a/Doc/c-api/exceptions.rst +++ b/Doc/c-api/exceptions.rst @@ -229,6 +229,24 @@ Similar to :c:func:`PyErr_SetFromWindowsErrWithFilename`, with an additional parameter specifying the exception type to be raised. Availability: Windows. +.. c:function:: PyObject* PyErr_SetExcWithArgsKwargs(PyObject *exc, PyObject *args, PyObject *kwargs) + + This is a convenience function to set an *exc* with the given *args* and + *kwargs* values. If *args* is ``NULL``, an empty :func:`tuple` will be + created when *exc* is created via :c:func:`PyObject_Call`. + +.. c:function:: PyObject* PyErr_SetFromImportErrorWithName(PyObject *msg, PyObject *name) + + This is a convenience function to raise :exc:`ImportError`. *msg* will be + set as the exception's message string, and *name* will be set as the + :exc:`ImportError`'s ``name`` attribute. + +.. c:function:: PyObject* PyErr_SetFromImportErrorWithNameAndPath(PyObject *msg, PyObject *name, PyObject *path) + + This is a convenience function to raise :exc:`ImportError`. *msg* will be + set as the exception's message string. Both *name* and *path* will be set + as the :exc:`ImportError`'s respective ``name`` and ``path`` attributes. + versionadded please. http://hg.python.org/cpython/rev/d79aa61ec96d ___ 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] __hash__ documentation
On Wed, Apr 18, 2012 at 13:07, Ethan Furman et...@stoneleaf.us wrote: http://bugs.python.org/issue14617 Patch attached to issue. Can I request that you not immediately post issues to python-dev? Those who follow the bug tracker will see the issue and act accordingly. (unless I missed some explicit request that this be posted here, in which case I apologize) ___ 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] Cython for cPickle?
On Thu, Apr 19, 2012 at 05:38, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Apr 19, 2012 at 6:55 PM, Stefan Behnel stefan...@behnel.de wrote: What do you think? I think the possible use of Cython for standard library extension modules is potentially worth looking into for the 3.4 timeframe (c.f. the recent multiple checkins sorting out the refcounts for the new ImportError helper function). I'd rather just rtfm as was suggested and get it right than switch everything around to Cython. ___ 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] Cython for cPickle?
On Thu, Apr 19, 2012 at 16:08, Stefan Behnel While code generation alleviates the burden of tedious languages, it's also infinitely more complex, makes debugging very difficult and adds to prerequisite knowledge, among other drawbacks. You can use gdb for source level debugging of Cython code and cProfile to profile it. Try that with C-API code. I know I'm in the minority of committers being on Windows, but we do receive a good amount of reports and contributions from Windows users who dive into the C code. The outside contributors actually gave the strongest indication that we needed to move to VS2010. Visual Studio by itself makes debugging unbelievably easy, and with the Python Tools for VS plugin it even allows Visual Studio's built-in profiler to work. I know Windows is not on most people's maps, but if we have to scrap the debugger, that's another learning curve attachment to evaluate. ___ 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] Cython for cPickle?
On Thu, Apr 19, 2012 at 17:21, Stefan Behnel stefan...@behnel.de wrote: Brian Curtin, 19.04.2012 23:19: On Thu, Apr 19, 2012 at 16:08, Stefan Behnel While code generation alleviates the burden of tedious languages, it's also infinitely more complex, makes debugging very difficult and adds to prerequisite knowledge, among other drawbacks. You can use gdb for source level debugging of Cython code and cProfile to profile it. Try that with C-API code. I know I'm in the minority of committers being on Windows, but we do receive a good amount of reports and contributions from Windows users who dive into the C code. Doesn't match my experience at all - different software target audiences, I guess. I'm don't know what this means. I work on CPython, which is the target audience at hand, and I come across reports and contributions from Windows users for C extensions. Visual Studio by itself makes debugging unbelievably easy, and with the Python Tools for VS plugin it even allows Visual Studio's built-in profiler to work. I know Windows is not on most people's maps, but if we have to scrap the debugger, that's another learning curve attachment to evaluate. What I meant was that there's pdb for debugging Python code (which doesn't know about the C code it executes) and gdb (or VS) for debugging C code, from which you can barely infer the Python code it executes. For Cython code, you can use gdb for both Cython and C, and within limits also for Python code. Here's a quick intro to see what I mean: http://docs.cython.org/src/userguide/debugging.html I know what you meant. What I meant is easy debugging on Windows goes away, now I have to setup and learn GDB on Windows. *I* can do that. Does the rest of the community want to have to do that as well? We should also take into consideration how something like this affects the third-party IDEs and their debugger support. ___ 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] cpython (2.7): #14538: HTMLParser can now parse correctly start tags that contain a bare /.
On Tue, Apr 24, 2012 at 14:34, Éric Araujo mer...@netwok.org wrote: Le 24/04/2012 15:02, Georg Brandl a écrit : On 24.04.2012 20:34, Benjamin Peterson wrote: 2012/4/24 Georg Brandlg.bra...@gmx.net: I think that's misleading: there's no way to correctly parse malformed HTML. There is in the since that you can follow the HTML5 algorithm, which can parse any junk you throw at it. Ah, good. Then I hope we are following the algorithm here (and are slowly coming to use it for htmllib in general). Yes, Ezio’s commits on html.parser/HTMLParser in the last months have been following the HTML5 spec. Ezio, RDM and I have had some discussion about that on some bug reports, IRC and private mail and reached the agreement to do the useful thing, that is follow HTML5 and not pretend that the stdlib parser is strict or validating. Ezio was thinking about a blog.python.org post to advertise this. Please do this, and I welcome anyone else who wants to write about their work on the blog to do so. Contact me for info. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Fix #3561. Add an option to place the Python installation into the Windows Path
On Wed, Apr 25, 2012 at 08:13, brian.curtin python-check...@python.org wrote: http://hg.python.org/cpython/rev/4e9f1017355f changeset: 76556:4e9f1017355f user: Brian Curtin br...@python.org date: Wed Apr 25 08:12:37 2012 -0500 summary: Fix #3561. Add an option to place the Python installation into the Windows Path environment variable. files: Misc/NEWS | 3 +++ Tools/msi/msi.py | 22 +++--- 2 files changed, 22 insertions(+), 3 deletions(-) http://bugs.python.org/issue14668 was created for updating the relevant documentation. I pushed without docs since it's unlikely they'll be done before the weekend's alpha 3 build, and I didn't want to have this feature wait an extra month before anyone sees it. Anyone who's installing an alpha build is probably advanced enough to know what it's doing in the meantime. ___ 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] outdated info on download pages for older versions
On Wed, May 2, 2012 at 12:06 PM, Ezio Melotti ezio.melo...@gmail.com wrote: On 02/05/2012 19.33, Michael Foord wrote: On 2 May 2012, at 16:55, Terry Reedy wrote: I would send the above to webmas...@python.org (should be at the bottom of pages). We develop CPython but do not directly manage the website. Not true. The download pages are administered by the release managers not the web team. For the record, the best way of contacting the web team (such as it is) is the pydotorg-www mailing list. There are precious few people (even fewer than there are in the web team...) responding to emails on the webmaster alias. :-) Michael I'm pretty sure that several core devs are able (and possibly willing) to help out with the website, but AFAIU they have to request commit right for a separate repo where the website lives or report issues via mail. Is there any practical reason why the repo for the website is not on hg with all the other repos (cpython/devguide/peps/etc.) except that no one ported it yet? I don't know if there's a practical reason, but given that the website will eventually be changing anyway, I think it's a waste of time to port it to hg. You'd also have to port the build chain to hg, since it rebuilds the site when svn is updated. Then by the time you're done, there's zero net gain and it all gets thrown away. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does trunk still support any compilers that *don't* allow declaring variables after code?
On Fri, May 4, 2012 at 10:08 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Wed, May 2, 2012 at 10:43 AM, Larry Hastings la...@hastings.org wrote: Do we officially support any C compilers that *don't* permit intermingled variable declarations and code? Do we *unofficially* support any? And if we do, what do we gain? This might be of interest: http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/?nope Specifically, apparently MSVC 2010 supports variable declarations in the middle of a block in C. Also, since full C99 support won't be coming to MSVC, perhaps Python should move to compiling in C++ mode? After seeing that same article yesterday and having the VS2010 port open, I tried this and it appears it won't work without significant code changes at least as far as I saw. I enabled /TP on the pythoncore project and got over 1363 errors. I don't have the time to figure it out right now, but I'll look more into it later. ___ 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] Preparation for VS2010 - MSDN for Windows build slaves, core devs
On Mon, Apr 2, 2012 at 9:12 PM, Brian Curtin br...@python.org wrote: Hi all, If you are a running a build slave or otherwise have an MSDN account for development work, please check that your MSDN subscription is still in effect. If the subscription expired, please let me know in private what your subscriber ID is along with the email address you use for the account. Eventually we're switching to VS2010 so each slave will need to have that version of the compiler installed. Thanks I heard back from our Microsoft contact that everyone who requested renewals should have begun processing around a week ago. Since it usually takes around a week, hopefully you've all received the renewal. If not, let me know and I'll get you taken care of. If build slave owners could let me know when their machine has VS2010 I'd appreciate it. I got the go-ahead to commit the port but want to wait until the build slaves are ready for it. ___ 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] Preparation for VS2010 - MSDN for Windows build slaves, core devs
On Sun, May 13, 2012 at 2:30 AM, mar...@v.loewis.de wrote: If build slave owners could let me know when their machine has VS2010 I'd appreciate it. I got the go-ahead to commit the port but want to wait until the build slaves are ready for it. Please don't wait, but let the build slaves break. This is getting urgent. Pushed the port in http://hg.python.org/cpython/rev/38d7d944370e ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] devguide: Add VS2010 link and text, then restructure a few things
On Wed, May 16, 2012 at 2:52 AM, Martin v. Löwis mar...@v.loewis.de wrote: +All versions previous to 3.3 use Microsoft Visual Studio 2008, available at +https://www.microsoft.com/visualstudio/en-us/products/2008-editions/express. This isn't actually the case. 2.4 and 2.5 used Visual Studio 2003, 2.0 to 2.3 used VC6, 1.4 and 1.5 used Visual C++ 1.5; versions before that were available only from Mark Hammond. I know *all* previous versions didn't use 2008 -- just all other versions we still support and that people seem to be working on or using. Anyway, I changed it from all to most in 0ac1d3863208. ___ 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] 64-bit Windows buildbots needed
On Wed, May 16, 2012 at 7:44 AM, Antoine Pitrou solip...@pitrou.net wrote: Hello all, We still need 64-bit Windows buildbots to test for regressions. Otherwise we might let regressions slip through, since few people seem to run the test suite under Windows at home. The machine that I used to run a Server 2008 x64 build slave is back to being a Windows machine after a dance with Ubuntu. I'm going to order more RAM and set it up to provide some 64-bit build slave, probably Windows 8. I will see about having it setup in the next few weeks. ___ 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] docs.python.org pointing to Python 3 by default?
On May 18, 2012 1:26 PM, Barry Warsaw ba...@python.org wrote: At what point should we cut over docs.python.org to point to the Python 3 documentation by default? Today sounds good to me. ___ 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 bug in distutils (Mingw32CCompiler)?
On Thu, May 24, 2012 at 7:03 AM, Sturla Molden stu...@molden.no wrote: Mingw32CCompiler in cygwincompiler.py emits the symbol -mno-cygwin. This is used to make Cygwin's gcc behave as mingw. As of gcc 4.6 it is not recognized by the mingw gcc compiler itself, and causes as crash. It should be removed because it is never needed for mingw (in any version), only for cross-compilation to mingw from other gcc versions. Instead, those who use CygwinCCompiler or Linux GCC to cross-compile to plain Win32 can set -mno-cygwin manually. It also means -mcygwin should be removed from the output of CygwinCCompiler. I think... Please report bugs to http://bugs.python.org so they don't get lost in email. The relevant people will be notified or assigned if a bug is entered. ___ 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] VS 11 Express is Metro only.
On Thu, May 24, 2012 at 5:21 PM, Terry Reedy tjre...@udel.edu wrote: The free Visual Studio 11 Express for Windows 8 (still in beta) will produce both 32 and 64 bit binaries and allow multiple languages but will only produce Metro apps. For desktop apps, either the paid Visual Studio versions or the free 2010 Express releases are required. https://www.microsoft.com/visualstudio/11/en-us/products/express bottom of page. Will this inhibit someday moving to Visual Studio 11 Professional or would VS2010 Express or VC++2010 Express still work for hacking on Python or making extensions that would work with any VS11-produced binary? I don't know. Maybe? Windows 8 and VS11 are still not released so who knows what will happen. ___ 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] cpython (3.2): Issue12510: Attempting to get invalid tooltip no longer closes Idle.
On Mon, May 28, 2012 at 8:44 PM, Terry Reedy tjre...@udel.edu wrote: + except: return None except Exception may be better here. Idle's Shell catches all exceptions. I think the attempt to provide an optional help (a function signature) should too. Can you explain what this means? You should probably not have a bare except - I'm not sure what IDLE has to do with it. ___ 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] cpython: Issue #14744: Fix compilation on Windows (part 2)
On Wed, May 30, 2012 at 10:46 AM, Kristján Valur Jónsson krist...@ccpgames.com wrote: -Original Message- From: R. David Murray [mailto:rdmur...@bitdance.com] The ValueError: Invalid format string was coming from a broken-on- windows test_calendar test I checked in. It is fixed now and the stable windows buildbots are green. --David Hm, there appear to be no x64 buildbots. Antoine asked about one several weeks ago. I have a Windows 8 x64 machine that I am planning on setting up once I have the time. I'll try to shift things around and get it back into the fleet. The machine used to be the 2008 x64 build slave we had last year. ___ 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] cpython: Issue #14744: Fix compilation on Windows (part 2)
On Wed, May 30, 2012 at 3:35 PM, Kristján Valur Jónsson krist...@ccpgames.com wrote: -Original Message- From: Brian Curtin [mailto:br...@python.org] Sent: 30. maí 2012 15:56 To: Kristján Valur Jónsson Cc: python-dev@python.org Subject: Re: [Python-Dev] cpython: Issue #14744: Fix compilation on Windows (part 2) appear to be no x64 buildbots. Antoine asked about one several weeks ago. I have a Windows 8 x64 machine that I am planning on setting up once I have the time. I'll try to shift things around and get it back into the fleet. The machine used to be the 2008 x64 build slave we had last year. I freely admit to not being a buildbot specialist, haven't touched those things for some years. Hence my perhaps silly question: Why do we need multiple windows machines, since they can cross compile and cross run left right and centre? Virtual PCs can be used to test compatibility with earlier versions. K I don't have the quality of hardware or the knowledge and time to set any of that up, so that's my excuse. I just turn my computer on and write code. When it doesn't work I reboot it. That's the extent of my system administration skills. ___ 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 11 change: Windows Support Lifecycle
On Fri, Jun 1, 2012 at 8:22 AM, mar...@v.loewis.de wrote: I have just codified our current policy on supporting Windows releases, namely that we only support some Windows version until Microsoft ends its extended support period. As a consequence, Windows XP will be supported until 08/04/2014, and Windows 7 until 14/01/2020 (unless Microsoft extends that date further). I have also added wording on Visual Studio support which may still require consensus. My proposed policy is this: 1. There is only one VS version supported for any feature release. Because of the different branches, multiple versions may be in use. 2. The version that we use for a new feature release must still have mainstream support (meaning it can still be purchased regularly). 3. We should strive to keep the number of VS versions used simultaneously small. VS 2008 has mainstream support until 09/04/2013, so we could have used it for 3.3 still, however, mainstream support ends within the likely lifetime of 3.3, so switching to VS 2010 was better. VS 2010 will have mainstream support until 14/07/2015, so we can likely use it for 3.4 as well, and only reconsider for 3.5 (at which point XP support will not be an issue anymore). VS 2012 is out for 3.4 as it doesn't support XP. This all sounds good to me. I think the rough timeline of our future releases lines up nicely, e.g., the VS version available around Python 3.5 won't support XP and neither would we. ___ 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] what is happening with the regex module going into Python 3.3?
On Fri, Jun 1, 2012 at 1:57 PM, Terry Reedy tjre...@udel.edu wrote: On 6/1/2012 1:27 PM, Brett Cannon wrote: About the only thing I can think of from the language summit that we discussed doing for Python 3.3 that has not come about is accepting the regex module and getting it into the stdlib. Is this still being worked towards? Since there is no PEP to define the details* of such an addition, I assume that no particular core developer focused on this. There have been a lot of other additions to take people's attention. Also, I do not remember seeing anything from Mathew Barnett about his views on the proposal. * Some details: Replacement of or addition to re. At the language summit it was proposed that this regex project would enter as re, and the current re moves to sre. Everyone seemed to agree. Relation to continued external project and 'ownership' of code. As with anything else, no more external. ___ 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] what is happening with the regex module going into Python 3.3?
On Fri, Jun 1, 2012 at 7:37 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Umpteen versions of regex have been available on pypi for years. Umpteen bugs against the original re module have been fixed. If regex can't now go into the standard library, what on earth can? Reviewing a 4000 line patch is probably the main roadblock here. ___ 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] what is happening with the regex module going into Python 3.3?
On Mon, Jun 4, 2012 at 7:31 PM, Steven D'Aprano st...@pearwood.info wrote: But changes to the stdlib (bug fixes or functional changes) are very likely to run at a slower pace to what third-party packages can afford. If you continue to develop regex outside of the stdlib, that could cause complications. Developing outside of the standard library isn't an option. You could always backport things to the external version like the unittest2 project, but standard library modules need to be grown and fixed first in the standard library. ___ 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] Using pdb with greenlet
On Tue, Jun 12, 2012 at 2:31 PM, Salman Malik salma...@live.com wrote: Hi All, I am sort of a newbie to Python ( have just started to use pdb). My problem is that I am debugging an application that uses greenlets and when I encounter something in code that spawns the coroutines or wait for an event, I lose control over the application (I mean that after that point I can no longer do 'n' or 's' on the code). Can anyone of you tell me how to tame greenlet with pdb, so that I can see step-by-step as to what event does a coroutine sees and how does it respond to it. Any help would be highly appreciated. Your question is better suited for python-list rather than python-dev. This list is for the development *of* Python, not *with* Python. ___ 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] backporting stdlib 2.7.x from pypy to cpython
On Jun 13, 2012 8:31 PM, Stephen J. Turnbull step...@xemacs.org wrote: Cameron Simpson writes: This approach has its own problems. Is the proposed list, like many lists, restricted to accept posts only from subscribers? If that is the case, when someone CCs the VM list, everyone honouring the CC in replies needs to be a VM list member if they are not to get annoying bounce messages. Mailman has a feature called sibling lists, which seems to include cross-checking membership on posts, although I'm not sure if it is tuned to exactly this purpose. In any cases, if the proposed list is not a discussion list, it can be configured not to send bounce messages just because somebody honored CC. For example, by keying on the Reference and In-Reply-To headers, and discarding the message if they are present (possible by ordinary configuration of the spam filters). For bonus points, bounce such messages when python-dev is not present among the visible addressees. (Might require a special Handler, but it wouldn't be a big deal to write it because it can be installed only for the new list.) +1 to this, but how to keep this etiquette maintained? A filter on the new list, implemented as above. It's pretty much trivial for those with the know-how. And (premised on my concern above), do people wanting to CC: the VM list for the heads-up purpose need to join it first? Probably not, but this is hardly burdensome; many people with the background to know when to CC: may want to subscribe anyway even if they are subscribed to python-dev, and traffic should be quite low. If even so that's a bother, they can set their subscription to no-mail. Conversely, some of this discussion mentions that people don't subscribe to python-dev; do they need to subscribe to chime in when the bat signal goes off? Maybe not: I believe it's possible to post to python-dev via Gmane if you're not subscribed. Even if they need to be subscribed, there is a wealth of options, including Gmane and the archives, for reading traffic without receiving it as mail (ie, by subscribing and then setting the no-mail flag). Hackish idea: suppose there were a special purpose mail forwarder, like a write-only mailing list? It would require special Mailman hackery, Not that special. Can someone create python-dev-meta? ___ 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] FWD: Windows 3.2.3 64 bit installers are actually 3.2
On Thu, Jun 14, 2012 at 4:12 PM, Aahz a...@pythoncraft.com wrote: Note: I'm no-mail on python-dev - Forwarded message from Sean Johnson seanjohnso...@gmail.com - Date: Thu, 14 Jun 2012 03:48:55 -0400 From: Sean Johnson seanjohnso...@gmail.com To: webmas...@python.org Subject: Windows 3.2.3 64 bit installers are actually 3.2 The installers on both this page: http://www.python.org/getit/releases/3.2.3/ and http://www.python.org/download/ For the x86-64 MSI Installer are both builds for version 3.2, not 3.2.3 (even though the filename says 3.2.3). I just tried for about 30 minutes to find out why the input() bug mentioned here: http://bugs.python.org/issue11272 was occuring in what I thought was the latest release - then I realized that my terminal windows stated version 3.2, not 3.2.3 after several uninstalls/installs. I think you're doing something wrong, either installing a different file than you just downloaded or not allowing it to overwrite an existing 3.2 installation. Both links have 3.2.3 labeled installers which I just downloaded, and both of them install 3.2.3 executables. ___ 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] 3.3 beta in one week
On Mon, Jun 18, 2012 at 2:17 AM, Martin v. Löwis mar...@v.loewis.de wrote: this is just a quick reminder that the feature freeze for 3.3 will start next weekend with the release of beta1. Since I won't be able to shift that date for short periods (the next possible date for me would be around July 16), I hope that everybody has planned ahead accordingly. Expect some rushing of PEP 397 then. FYI: Martin requested that I be the PEP czar for 397, so the rush kicks off...now :) ___ 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] PEP 397 - Last Comments
Martin approached me earlier and requested that I act as PEP czar for 397. I haven't been involved in the writing of the PEP and have been mostly observing from the outside, so I accepted and hope to get this wrapped up quickly and implemented in time for the beta. The PEP is pretty complete, but there are a few outstanding issues. On Mon, Jun 18, 2012 at 1:05 PM, Terry Reedy tjre...@udel.edu wrote: Independent installations will always only overwrite newer versions of the launcher with older versions. 'always only' is a bit awkward and the sentence looks backwards to me. I would expect only overwriting older versions with newer versions. Agreed, I would expect the same. I would think taking out the word only and then flipping newer and older in the sentence would correct it. On Mon, Jun 18, 2012 at 1:05 PM, Terry Reedy tjre...@udel.edu wrote: These seem contradictory: The 32-bit distribution of Python will not install a 32-bit version of the launcher on a 64-bit system. I presume this mean that it will install the 64-bit version and that there will always be only one version of the launcher on the system. On 64bit Windows with both 32bit and 64bit implementations of the same (major.minor) Python version installed, the 64bit version will always be preferred. This will be true for both 32bit and 64bit implementations of the launcher - a 32bit launcher will prefer to execute a 64bit Python installation of the specified version if available. This implies to me that the 32bit installation *will* install a 32bit launcher and that there could be both versions of the launcher installed. I took that as covering an independently-installed launcher. You could always install your own 32-bit launcher, and it'd prefer to launch a binary matching the machine type. So yes, there could be multiple launchers installed for different machine types, and I'm not sure why we'd want to (or how we could) prevent people from installing them. You could have a 64-bit launcher available system-wide in your Windows folder, then you could have a 32-bit launcher running out of C:\Users\Terry for some purposes. Martin - is that correct? === Outside of Terry's concerns, I find the updated PEP almost ready to go as-is. Many of the updates were in line with what Martin and I briefly talked about at PyCon, and I believe some of them came out of previous PEP discussions on here, so I see nothing unexpected at this point. My only additional comment would be to have the Configuration file implementation details supplemented with a readable example of where the py.ini file should be placed. On my machine that is C:\Users\brian\AppData\Local, rather than making people have to run that parameter through the listed function via pywin32. ___ 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
