Re: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers.

On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou wrote: > On Sun, 06 Feb 2011 02:10:15 +0100 > brett.cannon wrote: >> >>  To create your patch, you should generate a unified diff from your >> checkout's >>  top-level directory:: >> >> -    svn diff > patch.diff >> +    hg outgoing --path > patch.dif

Re: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers.

On Sun, Feb 6, 2011 at 12:36, Brendan Cully wrote: > On Sunday, 06 February 2011 at 12:13, Brett Cannon wrote: >> On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou wrote: >> > On Sun, 06 Feb 2011 02:10:15 +0100 >> > brett.cannon wrote: >> >> >> >>  

Re: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers.

On Tue, Feb 8, 2011 at 05:26, Antoine Pitrou wrote: > On Sun, 6 Feb 2011 12:13:08 -0800 > Brett Cannon wrote: >> > >> > We could perhaps present SVN-like "work in the working copy" workflow >> > (without local commits), and let seasoned hg users choos

Re: [Python-Dev] [Python-checkins] devguide: Try to explain the two most common approaches to hg workflow: feature

fixed On Tue, Feb 8, 2011 at 14:27, Terry Reedy wrote: > >> +While non-committers can use named branches without issue, as a core >> developer >> +you should limit their use to only those branches to be used to >> collaborate > > either /their/your/ > or /as a core developer you/core developers/

Re: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'.

On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou wrote: > On Wed, 09 Feb 2011 21:17:51 +0100 > brett.cannon wrote: >> >> >> -One should always work from a checkout of the CPython source code. While it >> may >> +One should always work from a working copy of the CPython source code. >> +While it may

Re: [Python-Dev] devguide: Fix a silly statement.

ition >> tag:         tip >> user:        Brett Cannon >> date:        Wed Feb 09 14:58:17 2011 -0800 >> summary: >>   Fix a silly statement. >> >> files: >>   setup.rst >> >> diff --git a/setup.rst b/setup.rst >> --- a/setup.rst >>

Re: [Python-Dev] 3.2.0

On Wed, Feb 16, 2011 at 09:34, Terry Reedy wrote: > I would like the next release called 3.2.0 rather than just 3.2. > > 'x.y' is known to be ambiguous and confusing. > > In most actual usages, I believe, it refers to the latest x.y.z release. On > the site, the 'x.y' docs are almost always the la

Re: [Python-Dev] Distutils2 next steps

On Mon, Feb 21, 2011 at 00:02, Tarek Ziadé wrote: > On Mon, Feb 21, 2011 at 8:48 AM, Georg Brandl wrote: >> On 21.02.2011 08:41, Tarek Ziadé wrote: >>> Hello >>> >>> Now that Python 3.2 is out, I am planning to do the following with >>> Distutils2: >>> >>> 1 - release a new alpha before Pycon fo

Re: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135

On Mon, Feb 21, 2011 at 04:52, Nick Coghlan wrote: > As the subject line asks, is there anything preventing the following > PEPs from being marked Final? > >  SA  389  argparse - New Command Line Parsing Module              Bethard >  SA  391  Dictionary-Based Configuration For Logging            

Re: [Python-Dev] Const-correctness in C-API Object Protocol

On Mon, Feb 21, 2011 at 15:34, David Claridge wrote: > Hi, > > I was wondering if there is some reason why C API functions like > PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments > rather than const char*s? If there is some reason these methods will > modify their string argumen

Re: [Python-Dev] %-formatting depracation

On Tue, Feb 22, 2011 at 10:43, Ethan Furman wrote: > Greetings! > > According to these release notes in Python 3.0, %-formatting will be going > away. > > > http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting > > > However, I was unable to find any

Re: [Python-Dev] Link to issue tracker

I won't add the link back, but I will try to change the global link on the website to point to the devguide. python.org/dev/ at this point exists purely to not break pre-existing links. On Wed, Feb 23, 2011 at 07:58, Antoine Pitrou wrote: > > Hello, > > I think it was a slight mistake to remove

Re: [Python-Dev] [Python-checkins] r88503 - in python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3

I assume you are having me do this because you still plan to cut separate releases. Is there a minimum Python version that needs to be supported? On Tue, Feb 22, 2011 at 18:23, Benjamin Peterson wrote: > 2011/2/22 brett.cannon : > > Author: brett.cannon > > Date: Tue Feb 22 20:12:43 2011 > > New

Re: [Python-Dev] Link to issue tracker

On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou wrote: > On Wed, 23 Feb 2011 10:30:54 -0800 > Brett Cannon wrote: > > I won't add the link back, but I will try to change the global link on > the > > website to point to the devguide. python.org/dev/ at this point exists &

Re: [Python-Dev] [Python-checkins] r88503 - in python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3

Does the benchmarking use the 2to3 script? I'm asking because package execution is not supported that far back. On Wed, Feb 23, 2011 at 11:38, Benjamin Peterson wrote: > 2011/2/23 Brett Cannon : > > I assume you are having me do this because you still plan to cut separate > >

Re: [Python-Dev] Link to issue tracker

On Wed, Feb 23, 2011 at 11:53, Antoine Pitrou wrote: > On Wed, 23 Feb 2011 11:21:58 -0800 > Brett Cannon wrote: > > On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou > wrote: > > > > > On Wed, 23 Feb 2011 10:30:54 -0800 > > > Brett Cannon wrote: > >

Re: [Python-Dev] Link to issue tracker

On Wed, Feb 23, 2011 at 11:52, "Martin v. Löwis" wrote: > Am 23.02.2011 19:30, schrieb Brett Cannon: > > I won't add the link back > > Why not? It's a useful link apparently. The "Developer's Guide" > link does not hint that it will be the

Re: [Python-Dev] Link to issue tracker

I just added a Quick Links section to the devguide at the very top which is short and to the point. I also committed to pydotorg for python.org/dev/ to redirect to docs.python.org/devguide/, so this whole discussion is dealt with IMO. On Wed, Feb 23, 2011 at 12:06, Brett Cannon wrote: > >

Re: [Python-Dev] Link to issue tracker

On Wed, Feb 23, 2011 at 12:38, James Y Knight wrote: > > On Feb 23, 2011, at 3:05 PM, Brett Cannon wrote: > > > > On Wed, Feb 23, 2011 at 11:52, "Martin v. Löwis" wrote: > >> Am 23.02.2011 19:30, schrieb Brett Cannon: >> > I won't add the lin

Re: [Python-Dev] Link to issue tracker

On Wed, Feb 23, 2011 at 12:51, "Martin v. Löwis" wrote: > > But python.org/dev/ is a dead page. I was > > trying to avoid adding a redirect for python.org/dev/ > > as I was afraid that it would lead to the > > website doing something silly like re

Re: [Python-Dev] Link to issue tracker

On Wed, Feb 23, 2011 at 15:40, "Martin v. Löwis" wrote: > > As for redirects: it's certainly possible to redirect ^/dev$ to > > /devguide, leaving /dev..* alone. I can set this up if you want me > to. > > > > > > Please. Or double-check what I put into pydotorg's redirect.txt will > > wor

Re: [Python-Dev] Link to issue tracker

On Wed, Feb 23, 2011 at 22:43, "Martin v. Löwis" wrote: > > What redirect.txt did you edit specifically? > > > > > > It was beta.python.org/build/redirects.txt > > , but I went ahead and > > reverted the change since your solution works. > > Ah. Tha

Re: [Python-Dev] Mercurial conversion repositories

On Thu, Feb 24, 2011 at 16:19, Antoine Pitrou wrote: > > Hello, > > Georg and I have been working on converting the SVN repository to > Mercurial. We can now present you a test repository (actually, two). > Thanks to the both of you for moving this forward! > > > CPython repository: http://hg.

Re: [Python-Dev] r88589 - python/branches/py3k/Lib/test/test_logging.py

And if it gets disabled again it should be a skipped test instead of a commented-out test to better keep track that it's turned off. On Fri, Feb 25, 2011 at 14:24, Antoine Pitrou wrote: > On Fri, 25 Feb 2011 18:02:43 +0100 (CET) > vinay.sajip wrote: > > Author: vinay.sajip > > Date: Fri Feb 25

Re: [Python-Dev] Mercurial conversion repositories

On Fri, Feb 25, 2011 at 13:46, Barry Warsaw wrote: > On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote: > > >What you are asking for is available in TortoiseHg which absolutely > >rocks (if you are not allergic to the idea of a graphical tool). > > Like shellfish, bee-strings, and Perl I'm afrai

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 10:08, Barry Warsaw wrote: > On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: > > >Le 25/02/2011 20:43, Barry Warsaw a écrit : > >> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: > >> [snip] > >>> Note that each of these branch clones will initially have your local

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 13:30, Barry Warsaw wrote: > On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote: > > >For other people's benefit, LoD == line of development (I think). > > Yes. It's just a word that isn't intimately tied to the implementation > detail

Re: [Python-Dev] devinabox: Add a Python script which will run the test suite in the most rigorous way

devinabox/rev/3e5a61adb41d >> > changeset: 8:3e5a61adb41d >> > user:Brett Cannon >> > date:Fri Feb 25 17:35:37 2011 -0800 >> > summary: >> > Add a Python script which will run the test suite in the most rigorous way possible. >> >

Re: [Python-Dev] Trimming "make quicktest"

On Wed, Mar 23, 2011 at 11:56, Antoine Pitrou wrote: > Le mercredi 23 mars 2011 à 18:51 +, Michael Foord a écrit : > > On 23/03/2011 18:42, Antoine Pitrou wrote: > > > On Wed, 23 Mar 2011 14:29:22 -0400 > > > David Bolen wrote: > > >> Nick Coghlan writes: > > >> > > >>> On Thu, Mar 24, 2011

Re: [Python-Dev] Policy for making changes to the AST

On Sat, Apr 2, 2011 at 23:55, "Martin v. Löwis" wrote: > > 1. Do nothing. This will break code that currently uses AST, but doesn't > add > > any complexity to cpython. > > I'm in favor of this approach as well. Notice that there is > ast.__version__ precisely so that applications can support mul

[Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

appen. == PEP: 399 Title: Pure Python/C Accelerator Module Compatibiilty Requirements Version: $Revision: 88219 $ Last-Modified: $Date: 2011-01-27 13:47:00 -0800 (Thu, 27 Jan 2011) $ Author: Brett Cannon Status: Draft Type: Informational Content-Type: text/x-rst Created: 04-Apr

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

On Tue, Apr 5, 2011 at 01:26, Stefan Behnel wrote: > Brett Cannon, 05.04.2011 01:46: > > At both the VM and language summits at PyCon this year, the issue of >> compatibility of the stdlib amongst the various VMs came up. Two issues >> came >> about in regards to modu

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

On Tue, Apr 5, 2011 at 05:01, Nick Coghlan wrote: > On Tue, Apr 5, 2011 at 9:46 AM, Brett Cannon wrote: > > try: > > c_heapq.heappop(Spam()) > > except TypeError: > > # "heap argument must be a list" > > pass > &g

Re: [Python-Dev] clarification: subset vs equality Re: [Python-checkins] peps: Draft of PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

On Tue, Apr 5, 2011 at 06:10, Jim Jewett wrote: > On 4/4/11, brett.cannon wrote: > > Draft of PEP 399: Pure Python/C Accelerator Module Compatibiilty > > Requirements > > > +Abstract > > + > > + > > +The Python standard library under CPython contains various instances > > +of modules i

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

On Tue, Apr 5, 2011 at 12:57, Raymond Hettinger wrote: > [Brett] > > This PEP requires that in these instances that both > > the Python and C code must be semantically identical > > Are you talking about the guaranteed semantics > promised by the docs or are you talking about > every possible imp

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

On Tue, Apr 5, 2011 at 05:01, Nick Coghlan wrote: > On Tue, Apr 5, 2011 at 9:46 AM, Brett Cannon wrote: > > try: > > c_heapq.heappop(Spam()) > > except TypeError: > > # "heap argument must be a list" > > pass > &g

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

On Wed, Apr 6, 2011 at 12:45, Raymond Hettinger wrote: > > On Apr 6, 2011, at 10:39 AM, Brett Cannon wrote: > > Since people are taking my "semantically identical" point too strongly > for what I mean (there is a reason I said "except in cases > > where imp

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

ain things more obvious. -- PEP: 399 Title: Pure Python/C Accelerator Module Compatibility Requirements Version: $Revision: 88219 $ Last-Modified: $Date: 2011-01-27 13:47:00 -0800 (Thu, 27 Jan 2011) $ Author: Brett Cannon Status: Draft Type: Informational Content-Ty

Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): merge from 3.2.

I think you have the wrong issue #; that one has to do with string exceptions. On Wed, Apr 13, 2011 at 22:21, senthil.kumaran wrote: > http://hg.python.org/cpython/rev/7563f10275a2 > changeset: 69350:7563f10275a2 > parent: 69344:1f767f834e67 > parent: 69349:37d1b749eebb > user:

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

In the grand python-dev tradition of "silence means acceptance", I consider this PEP finalized and implicitly accepted. On Tue, Apr 12, 2011 at 15:07, Brett Cannon wrote: > Here is the next draft of the PEP. I changed the semantics requirement to > state that 100% branch cove

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

On Sat, Apr 16, 2011 at 14:23, Stefan Krah wrote: > Brett Cannon wrote: > > In the grand python-dev tradition of "silence means acceptance", I > consider > > this PEP finalized and implicitly accepted. > > I did not really see an answer to these concerns: &g

Re: [Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements

I just want to say upfront that my personal life has just gotten very hectic as of late (green card stuff for my wife who is Canadian) and probably will not let up until June. So if I go a while without replying to points being made for quite a while, I apologize. Luckily there seem to be others he

Re: [Python-Dev] cpython: Remove some extraneous parentheses and swap the comparison order to

On Mon, Jun 6, 2011 at 23:57, Georg Brandl wrote: > On 06/07/11 05:20, brett.cannon wrote: > > http://hg.python.org/cpython/rev/fc282e375703 > > changeset: 70695:fc282e375703 > > user:Brett Cannon > > date:Mon Jun 06 20:20:36 2011 -0700 >

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

On Tue, Jun 28, 2011 at 06:28, Nick Coghlan wrote: > On Tue, Jun 28, 2011 at 10:56 PM, Michael Foord > wrote: > > I don't think "data attributes" is clear or precise. Is a property a data > > attribute (well it depends how it is implemented and what it does), is a > > staticmethod a data attribu

Re: [Python-Dev] Draft PEP: Deprecate codecs.StreamReader and codecs.StreamWriter

On Thu, Jul 7, 2011 at 11:43, Victor Stinner wrote: > Le 07/07/2011 19:33, Terry Reedy a écrit : > > On 7/7/2011 7:28 AM, Antoine Pitrou wrote: >> >> The main point of the PEP, IMO, is actually the deprecation itself. By >>> deprecating, we signal that something isn't actively maintained >>> any

Re: [Python-Dev] status of absolute_import w/ python 2.7

On Fri, Jul 8, 2011 at 06:51, Sylvain Thénault wrote: > Hi there, > > the documentation state that absolute_import feature is the default > behaviour with python 2.7, though it seems that it behave differently > with the __future__ import : > > $ cat package/__init__.py > > import subpackage > > $

[Python-Dev] Latest draft of PEP 399 (Pure Python/C Accelerator Module Compatibility Requirements)

re the "be API compatible" assumes this, but mentioning it doesn't hurt (and should help make Raymond less angry =). PEP: 399 Title: Pure Python/C Accelerator Module Compatibility Requirements Version: $Revision: 88219 $ Last-Modified: $Date: 2011-01-27 13:47:00 -0800 (Thu, 27

Re: [Python-Dev] Issue10271 - warnings.showwarning should allow any callable object - request commiter

Just so people know, I went ahead and fixed this for 3.3 (but not for 3.2 since it changes the API in a subtle way). On Sat, Jul 16, 2011 at 01:33, lekmalek wrote: > Hello all, > > Can any of you core devs have a look at > http://bugs.python.org/issue10271. It seems Brett is really busy right >

Re: [Python-Dev] New tests in stable versions

On Wed, Jul 20, 2011 at 11:48, Terry Reedy wrote: > On 7/20/2011 12:25 PM, Victor Stinner wrote: > >> Le 20/07/2011 17:58, Éric Araujo a écrit : >> >>> Do we have a policy of not adding new test files to stable branches? >>> >> New logging tests failed during some weeks. If we add new tests, we m

Re: [Python-Dev] Issue10271 - warnings.showwarning should allow any callable object - request commiter

On Wed, Jul 20, 2011 at 23:05, lekmalek wrote: > On Sun, 17 Jul 2011 19:19:59 -0700 > Brett Cannon wrote: > > > Just so people know, I went ahead and fixed this for 3.3 (but not for > > 3.2 since it changes the API in a subtle way). > Yeah, but that shouldn't brea

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

On Sat, Jul 23, 2011 at 20:35, Eli Bendersky wrote: > Some background: I'm working (on and off) on issue 11015 - documenting > the public functions in test.support > > Some of the functions in test.support (for example unlink, rmtree) > simply shadow existing & popular stdlib functions, with the

Re: [Python-Dev] [Python-checkins] cpython: Issue #11049: adding some tests to test.support

On Tue, Jul 26, 2011 at 17:41, Nick Coghlan wrote: > On Wed, Jul 27, 2011 at 12:10 AM, Éric Araujo wrote: > > Le 26/07/2011 15:30, Antoine Pitrou a écrit : > >> Actually, you want %a for non-ASCII messages to be escaped. > > > > Thanks for the reminder, I should use more %a instead of %r. In th

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

On Wed, Jul 27, 2011 at 06:36, R. David Murray wrote: > On Wed, 27 Jul 2011 16:14:40 +0300, Eli Bendersky > wrote: > > 1. In the documentation of test.support mention explicitly that it's code > > for CPython's internal use only, and these APIs aren't guaranteed to be > > stable. > > This was alr

Re: [Python-Dev] Convention on functions that shadow existing stdlib functions

On Wed, Jul 27, 2011 at 16:53, Steven D'Aprano wrote: > Eli Bendersky wrote: > > Sure, but I'm still leery of two functions with the same name doing acting >> slightly differently. >> > > > and then in a later post: > > > As I mentioned elsewhere, it's not good practice to have two functions >>

Re: [Python-Dev] HTMLParser and HTML5

On Thu, Jul 28, 2011 at 11:25, Matt wrote: > Hello all, > > I wanted to ask a few questions and start a discussion about HTML5 > support within the HTMLParser class(es). Over on issue 670664, an > inconsistency with the way browsers and the HTMLParser parse script > and style tags was discovered.

Re: [Python-Dev] [Python-checkins] cpython: Issue 12647: Add __bool__() method to the None object.

On Thu, Jul 28, 2011 at 09:55, raymond.hettinger wrote: > http://hg.python.org/cpython/rev/ccce01988603 > changeset: 71542:ccce01988603 > user:Raymond Hettinger > date:Thu Jul 28 09:55:13 2011 -0700 > summary: > Issue 12647: Add __bool__() method to the None object. > > files:

Re: [Python-Dev] HTMLParser and HTML5

On Fri, Jul 29, 2011 at 11:31, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/29/2011 07:22 AM, Joao S. O. Bueno wrote: > > > I disaagree. Having proper html parsing out of the box is part of > > the "batteries included" thing. And it is not a matter of "having > >

Re: [Python-Dev] HTMLParser and HTML5

On Fri, Jul 29, 2011 at 13:16, Glyph Lefkowitz wrote: > On Jul 29, 2011, at 3:00 PM, Matt wrote: > > I don't see any real reason to drop a decent piece of code (HTMLParser, > that is) in favor of a third party library when only relatively minor > updates are needed to bring it up to speed with the

Re: [Python-Dev] The docs, reloaded

On 5/20/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Georg> So, that's not really a concern of mine ;) > > You must realize that people will use the core tools to create documentation > for third party packages which aren't in the core. If you replace LaTeX > with something else I thi

[Python-Dev] whitespace normalization pre-commit hook is giving me grief

In my bcannon-objcap branch I am trying to check in a change that involves a soft symlink from Lib/controlled_importlib.py to ../importlib/controlled_importlib.py through ``ln -s ../controlled_importlib.py controlled_importlib.py`` while in the Lib directory. I have done this before in this branc

Re: [Python-Dev] whitespace normalization pre-commit hook is giving me grief

On 5/25/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > In my bcannon-objcap branch I am trying to check in a change that involves a > soft symlink from Lib/controlled_importlib.py to > ../importlib/controlled_importl

Re: [Python-Dev] whitespace normalization pre-commit hook is giving me grief

On 5/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote: Neal Norwitz schrieb: > On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote: >> In my bcannon-objcap branch I am trying to check in a change that involves a >> soft symlink from Lib/controlled_impo

Re: [Python-Dev] whitespace normalization pre-commit hook is giving me grief

On 5/26/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: On 5/26/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > > > On 5/25/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > > Neal Norwitz schrieb: > > > On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote: &

Re: [Python-Dev] whitespace normalization pre-commit hook is giving me grief

On 5/28/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: Brett Cannon schrieb: > Unfortunately the pre-commit hook > does not specify what line a change was made on so I have no clue where > it is failing (maybe this should be added?). It creates a reindent.Reindenter

[Python-Dev] removing use of mimetools, multifile, and rfc822

I just finished going through PEP 4 and adding DeprecationWarnings in 2.6for the various modules that were lacking the warning for some reason or another ... ... except for mimetools, multifile, and rfc822. All three modules are still used by some other module somewhere in the stdlib. The docs

[Python-Dev] failures in test_sqlite when entire test suite run

I have been getting failures from test_sqlite off the trunk when I run the entire test suite (as ``./python.exe Lib/test/regrtest.py``) with this error on OS X 10.4.9 and sqlite3 3.3.16: Traceback (most recent call last): File "/Users/drifty/Dev/python/2.x/pristine/Lib/sqlite3/test/regression.py

Re: [Python-Dev] failures in test_sqlite when entire test suite run

On 5/31/07, Brett Cannon <[EMAIL PROTECTED]> wrote: I have been getting failures from test_sqlite off the trunk when I run the entire test suite (as ``./python.exe Lib/test/regrtest.py``) with this error on OS X 10.4.9 and sqlite3 3.3.16: Traceback (most recent call last): File &

[Python-Dev] cleaning up the email addresses in the PEPs

I am working on some code in the sandbox to automatically generate PEP 0. This is also leading to code that checks all the PEPs follow some basic guidelines. One of those guidelines is an author having a single email address. The Owners index at the bottom of PEP 0 is going to be created from the

[Python-Dev] handling the granularity of possible Py3K warnings in 2.6

My rewrite of import is written for 2.6. But I am going to try to bootstrap it into 3.0. But I want to bootstrap into 2.6 if it works out well in 3.0. That means coding in 2.6 but constantly forward-porting to 3.0. In other words I am going to be a guinea pig of our transition plan. And being

Re: [Python-Dev] What's going on with the check-in emails?

On 6/27/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: > Hi, > > It seems there is a problem with check-in emails -- i.e., none have > been sent since r56057 (and the svn tree is at r56098 right now). > Does someone has a hint what's going on? > I am having issues as well. I just did a slew

Re: [Python-Dev] PEP 366 - Relative imports from main modules

On 7/5/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote: > >I see no big problems with this, except I wonder if in the end it > >wouldn't be better to *always* define __package_name__ instead of only > >when it's in main? And then perhaps rename it

Re: [Python-Dev] 2.5.2 schedule?

On 7/6/07, Jack Howarth <[EMAIL PROTECTED]> wrote: >I was wondering if there is a schedule for the > release of a python 2.5.2 update? I don't see anything > like that on the www.python.org web site. Thanks in > advance for any information. There is no schedule at the moment, no. It is up to

Re: [Python-Dev] Python 2.6 BaseException.message deprecation, really needed?

On 7/7/07, Gustavo Carneiro <[EMAIL PROTECTED]> wrote: > In PyGObject we want to use a 'message' attribute in an exception defined by > us. The name 'message' comes from a C API, therefore we would like to keep > it for easier mapping between C and Python APIs. Why does Python have to > deprecate

Re: [Python-Dev] Summary of Tracker Issues

On 7/7/07, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Steve Holden <[EMAIL PROTECTED]> wrote: > > Tracker wrote: > > > > > > ACTIVITY SUMMARY (07/01/07 - 07/08/07) > > > > > > > > > Tracker at http://bugs.python.org/ > > > > > > To view or respond to any of the issues listed below, sim

Re: [Python-Dev] PEP 366 - Relative imports from main modules

On 7/8/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > "Brett Cannon" <[EMAIL PROTECTED]> wrote: > >> On 7/5/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > >>> At 11:53 AM 7/5/2007 +0200, Guido van Rossum wrote: >

Re: [Python-Dev] PEP 366 - Relative imports from main modules

On 7/9/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > On 7/8/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > >> As with the current ``__name__`` attribute, setting ``__package__`` will > >> be the responsibility of the PEP 302 loader used

Re: [Python-Dev] Subversion branch merging

On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I'm tasked with performing a number of merge operations across > various Python branches. Can somebody please share a command > line that I should use to continue with the merge tracking that > has been used? Is that documented somewhere?

Re: [Python-Dev] Sorry About Summaries

On 7/18/07, Calvin Spealman <[EMAIL PROTECTED]> wrote: > I completely intend to finish the backlog of summaries, but I've > reached the point that I know it is futile to continue thinking I'll > be able to fit in the time for the summaries in an on-going and > reliable manner. When I took on the re

[Python-Dev] Please help verify SF data dump imported into (future) new tracker

We are getting very close to moving over to the new tracker (hopefully by the end of the month; no firm date yet, though, as we are still planning things out)! Part of the transition is taking a data dump provided by SourceForge and loading it into our Roundup instance. But we need to make some e

Re: [Python-Dev] [Python-3000] Python 3000 Sprint @ Google

On 8/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > It's official! The second annual Python Sprint @ Google is happening > again: August 22-25 (Wed-Sat). I can't attend this year (damn doctor's appt.), but I will try to be on Google Talk (username of bcannon) in case I can help out somehow r

Re: [Python-Dev] [Python-3000] Documentation switch imminent

On 8/14/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Now that the converted documentation is fairly bug-free, I want to > make the switch. > > I will replace the old Doc/ trees in the trunk and py3k branches > tomorrow, moving over the reST ones found at > svn+ssh://svn.python.org/doctools/Doc-{26

Re: [Python-Dev] [Python-3000] Documentation switch imminent

On 8/15/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: > > On 8/14/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > >> Now that the converted documentation is fairly bug-free, I want to > >> make the switch. > >> > >>

Re: [Python-Dev] [Python-3000] Documentation switch imminent

On 8/15/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Okay, I made the switch. I tagged the state of both Python branches > > before the switch as tags/py{26,3k}-before-rstdocs/. > > Update instructions: > > 1. svn diff Doc; any pending changes will need to be redone > 2. svn up; this will

[Python-Dev] Planning to switch to new tracker on August 23rd

Having squashed the final issues, we are now ready to switch over to the new tracker! The plan is to do it on the 23rd. But before I announce to the community I wanted to make sure there was not some specific objection by python-dev or python-3000. If there is please let me know by midday Monday

Re: [Python-Dev] Email addresses in PEPs?

On 8/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Ask the people involved if they're okay with "user at host dot com" > obfuscation. That's used in a few places already (e.g. PEP 0). > I believe email addresses are automatically obfuscated as part of the HTML generation process, but one of

[Python-Dev] How to interpret get_code from PEP 302?

PEP 302 ("New Import Hooks") has an optional extensions section so that tools like py2exe and py2app have an easier time. Part of the optional extensions is the method get_code that is to return the code object for the specified method (if the loader can handle it). But there is a lack in the def

Re: [Python-Dev] How to interpret get_code from PEP 302?

[Thanks to Guido, Paul, and Nick for replying; going to just reply to Paul since everyone said the same thing and it's his fault I didn't understand the wording. =)] On 8/21/07, Paul Moore <[EMAIL PROTECTED]> wrote: > On 21/08/07, Brett Cannon <[EMAIL PROTECTED]> wrote:

Re: [Python-Dev] New bug tracker is active now

On 8/23/07, Martin von Löwis <[EMAIL PROTECTED]> wrote: > We have completed the conversion to Roundup as the bug tracker > for Python; the new tracker is now life at > > http://bugs.python.org/ > > It has all reports from the SourceForge tracker, along with > all messages and files that had been

[Python-Dev] PEP 302 optional extensions only for loaders?

When you read PEP 302 and the section on the optional extensions, it mentions that they "are highly recommended for general purpose importers". But then the PEP says very shortly thereafter that "loader objects" are to have the extensions. So which is it, importers or loaders? The reason I ask i

Re: [Python-Dev] Final SF Python Patch/Bug Summary

Thanks for having done these, Kurt! -Brett On 8/23/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote: > New / Reopened Patches > __ > > minidom pretty xml output improvement (2007-08-19) >http://python.org/sf/1777134 opened by Teajay > > removeTest() method patch for uni

Re: [Python-Dev] Triage of old tracker bugs: Any use?

On 8/28/07, Sean Reifschneider <[EMAIL PROTECTED]> wrote: > I've taken the week off and I'm trying to do something useful for Python in > some of my time. I've basically been looking through the entries sorted by > priority and least recent activity. > > Some items I've been able to do something w

Re: [Python-Dev] the FakeSocket class in httplib.py -- remove it?

On 8/31/07, Bill Janssen <[EMAIL PROTECTED]> wrote: > I'm wondering if it would be OK to remove the FakeSocket class in > httplib? Actually, it's currently a function that returns one of its > arguments. It's not documented as part of the module, and not used > elsewhere in the rest of the librar

[Python-Dev] Google spreadsheet to collaborate on backporting Py3K stuff to 2.6

Neal, Anthony, Thomas W., and I have a spreadsheet that was started to keep track of what needs to be done in what needs to be done in 2.6 for Py3K transitioning: http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg . I am opening the spreadsheet up to everyone so that others can help ma

[Python-Dev] PEP 362: Signature objects

Neal Becker over on python-3000 said that the Boost people could use this. Figured it was time to present it officially to the list to see if I can get it added for 2.6/3.0. The implementation in the sandbox works in both 2.6 and 3.0 out of the box (no 2to3 necessary) so feel free to play with it

Re: [Python-Dev] PEP 362: Signature objects

On 9/7/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > > A Signature object has the following structure attributes: > > > * name : str > > Name of the function. This is not fully qualified because > > function objects for methods do not know the class they are > > contained within. This m

Re: [Python-Dev] Removing the GIL (Me, not you!)

On 9/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > It's the interpreter and thread state itself (pystate.h), for the thread > > state, also _PyThreadState_Current. Then there is the GC state, in > > particular "generations". There are various caches and counters also. > > > >

Re: [Python-Dev] urllib exception compatibility

On 9/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > How about making IOError, OSError and EnvironmentError all aliases for > the same thing? The distinction is really worthless historical > baggage. > +1 from me. Should OSError and IOError become aliases to EnvironmentError? I assume Windo

Re: [Python-Dev] Adding concat function to itertools

On 9/22/07, Bruce Frederiksen <[EMAIL PROTECTED]> wrote: > > I've added a new function to itertools called 'concat'. This function is > much like chain, but takes all of the iterables as a single argument. Thus > concat(some_iterables) is logically equivalent to chain(*some_iterables); > the dif

Re: [Python-Dev] urllib exception compatibility

On 9/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/28/07, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > > Greg Ewing writes: > > > Gregory P. Smith wrote: > > > > Is IOError is the right name to use? OSError is raised for things that > > > > are not IO such as subprocess, dlopen,

Re: [Python-Dev] OpenSSL httplib bug

On 9/30/07, Richie Ward <[EMAIL PROTECTED]> wrote: > I was using httplib to power my xml rpc script. > > I had problems when I wanted to use SSL and I got this error: > File "/usr/lib/python2.5/httplib.py", line 1109, in recv > return self._ssl.read(len) > socket.sslerror: (8, 'EOF occurred i

<    18   19   20   21   22   23   24   25   26   27   >