Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

On 5/21/2012 2:28 AM, Nick Coghlan wrote: On Mon, May 21, 2012 at 3:47 PM, Terry Reedy wrote: What might be useful is to have the 'Other versions' links on the left margin of *every* page, not just the front page, but have them link to the corresponding page of the other docs (if there is one

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

2012/5/20 Nick Coghlan : > On Mon, May 21, 2012 at 3:47 PM, Terry Reedy wrote: >> On 5/21/2012 12:28 AM, Nick Coghlan wrote: >>> >>> On Mon, May 21, 2012 at 11:23 AM, Guido van Rossum >>>  wrote: I suggest that we add a separate (virtual) subdomain, e.g. docs3.python.org. >> >> >> I

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

On Mon, May 21, 2012 at 3:47 PM, Terry Reedy wrote: > On 5/21/2012 12:28 AM, Nick Coghlan wrote: >> >> On Mon, May 21, 2012 at 11:23 AM, Guido van Rossum >>  wrote: >>> >>> I suggest that we add a separate (virtual) subdomain, e.g. >>> docs3.python.org. > > > I was about to post the exact same ide

Re: [Python-Dev] dir() in inspect.py ?

On 21 May 2012 03:36, Guido van Rossum wrote: > [...] > > I have to agree with Christian that inspect.py is full of hacks and > heuristics that would be fine in a module that's part of a user's app > or even in a library, but stand out as brittle or outright unreliable > in a stdlib module. Basic

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

On 5/21/2012 12:28 AM, Nick Coghlan wrote: On Mon, May 21, 2012 at 11:23 AM, Guido van Rossum wrote: I suggest that we add a separate (virtual) subdomain, e.g. docs3.python.org. I was about to post the exact same idea. docs.python.org/py3k is a bit obscure and buried and makes Python 3.x lo

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

I know plenty of people are keen to push the migration to Python 3 forward as quickly as possible, but this is *definitely* a case of "make haste slowly". We need to tread carefully or we're going to give existing users an even stronger feeling that we simply don't care about the impact the Python

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

On Mon, May 21, 2012 at 11:23 AM, Guido van Rossum wrote: > I suggest that we add a separate (virtual) subdomain, e.g. docs3.python.org. Rather than a new subdomain, I'd prefer to see a discreet "documentation version" CSS widget, similar to that used in the Django docs (see https://docs.djangopr

Re: [Python-Dev] [Python-checkins] cpython: Describe the default hash correctly, and mark a couple of CPython

It's true for the default comparison definition for user defined classes, which is what that paragraph describes. -- Sent from my phone, thus the relative brevity :) On May 21, 2012 2:32 AM, "Terry Reedy" wrote: > On 5/20/2012 4:31 AM, nick.coghlan wrote: > > + and ``x.__hash__()`` returns an

Re: [Python-Dev] dir() in inspect.py ?

On Sun, May 20, 2012 at 4:55 PM, Meador Inge wrote: > On Tue, May 15, 2012 at 3:13 PM, Christian Tismer > wrote: > >> Is the usage of dir() correct in this context or is the doc right? >> It would be nice to add a sentence of clarification if the use of >> dir() is in fact the correct way to imp

[Python-Dev] PEP 420 - dynamic path computation is missing rationale

I have just reviewed PEP 420 (namespace packages) and sent Eric my detailed feedback; most of it is minor or requesting for examples and I'm sure he'll fix it to my satisfaction. Generally speaking the PEP is a beacon if clarity. But I stumbled about one feature that bothers me in its specificatio

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

I suggest that we add a separate (virtual) subdomain, e.g. docs3.python.org. On Sun, May 20, 2012 at 4:27 PM, Raymond Hettinger wrote: > > On May 18, 2012, at 11:24 AM, Barry Warsaw wrote: > > At what point should we cut over docs.python.org to point to the Python 3 > documentation by default?  W

Re: [Python-Dev] dir() in inspect.py ?

On Tue, May 15, 2012 at 3:13 PM, Christian Tismer wrote: > Is the usage of dir() correct in this context or is the doc right? > It would be nice to add a sentence of clarification if the use of > dir() is in fact the correct way to implement inspect. There is already a note in the inspect.getmem

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

On May 18, 2012, at 11:24 AM, Barry Warsaw wrote: > At what point should we cut over docs.python.org to point to the Python 3 > documentation by default? Wouldn't this be an easy bit to flip in order to > promote Python 3 more better? My experience teaching and consulting suggests that this wou

Re: [Python-Dev] Backward compatibility of shutil.rmtree

Am 20.05.12 23:46, schrieb mar...@v.loewis.de: Two of them differ in the new version: os.fwalk() is used instead of os.listdir() and os.unlinkat() instead of os.remove(). >>> It would be os.flistdir instead of os.listdir, not os.fwalk, right? >> It’s actually os.fwalk. It has been implem

Re: [Python-Dev] Backward compatibility of shutil.rmtree

Zitat von Hynek Schlawack : Two of them differ in the new version: os.fwalk() is used instead of os.listdir() and os.unlinkat() instead of os.remove(). It would be os.flistdir instead of os.listdir, not os.fwalk, right? It’s actually os.fwalk. It has been implemented by Charles-François as a

Re: [Python-Dev] Backward compatibility of shutil.rmtree

>> Two of them differ in the new version: os.fwalk() is used instead of >> os.listdir() and os.unlinkat() instead of os.remove(). > It would be os.flistdir instead of os.listdir, not os.fwalk, right? It’s actually os.fwalk. It has been implemented by Charles-François as a dependency of the ticket

Re: [Python-Dev] PEP 3135 (new super()) __class__ references broken in 3.3

2012/5/20 Calvin Spealman : > On Sun, May 20, 2012 at 4:28 PM, Benjamin Peterson > wrote: >> 2012/5/20 Nick Coghlan : >>> PEP 3135 defines the new zero-argument form of super() as implicitly >>> equivalent to super(__class__, ), and up until 3.2 has >>> behaved accordingly: if you accessed __clas

Re: [Python-Dev] PEP 3135 (new super()) __class__ references broken in 3.3

On Sun, May 20, 2012 at 4:28 PM, Benjamin Peterson wrote: > 2012/5/20 Nick Coghlan : >> PEP 3135 defines the new zero-argument form of super() as implicitly >> equivalent to super(__class__, ), and up until 3.2 has >> behaved accordingly: if you accessed __class__ from inside a method, >> you woul

Re: [Python-Dev] PEP 3135 (new super()) __class__ references broken in 3.3

2012/5/20 Nick Coghlan : > PEP 3135 defines the new zero-argument form of super() as implicitly > equivalent to super(__class__, ), and up until 3.2 has > behaved accordingly: if you accessed __class__ from inside a method, > you would receive a reference to the lexically containing class. I don't

Re: [Python-Dev] Email6 status

On Tue, 01 May 2012 10:55:03 -0400, Barry Warsaw wrote: > On May 01, 2012, at 10:40 AM, R. David Murray wrote: > >I guess it's time to talk about my plans for this one :) > > Thanks for the update RDM. I really wish I had more time to contribute to > email6, but I'd still really like to see this

Re: [Python-Dev] [Python-checkins] cpython: Issue #14814: addition of the ipaddress module (stage 1 - code and tests)

On Sun, 20 May 2012 13:18:29 -0400 Terry Reedy wrote: > > + > > +""" > > +if version: > > if version is not None: ?? > Do you really want to silently ignore *every* null value, like '' or []? The goal is probably to have "midnight" mean "auto-detect the address family" ;-) cheers Antoi

Re: [Python-Dev] [Python-checkins] cpython: Issue #14814: addition of the ipaddress module (stage 1 - code and tests)

On 5/20/2012 7:02 AM, nick.coghlan wrote: +def ip_address(address, version=None): +"""Take an IP string/int and return an object of the correct type. + +Args: +address: A string or integer, the IP address. Either IPv4 or + IPv6 addresses may be supplied; integers less

Re: [Python-Dev] Backward compatibility of shutil.rmtree

Two of them differ in the new version: os.fwalk() is used instead of os.listdir() and os.unlinkat() instead of os.remove(). It would be os.flistdir instead of os.listdir, not os.fwalk, right? The way this interface is defined, it's IMO best to do "precise" reporting, i.e. pass the exact functio

Re: [Python-Dev] [Python-checkins] cpython: Describe the default hash correctly, and mark a couple of CPython

On 5/20/2012 4:31 AM, nick.coghlan wrote: + and ``x.__hash__()`` returns an appropriate value such that ``x == y`` + implies both that ``x is y`` and ``hash(x) == hash(y)``. I don't understand what you were trying to say with x == y implies x is y but I know you know that that is not true

Re: [Python-Dev] PEP 3135 (new super()) __class__ references broken in 3.3

On Sun, May 20, 2012 at 11:03 PM, Antoine Pitrou wrote: > On Sun, 20 May 2012 18:51:27 +1000 > Nick Coghlan wrote: >> PEP 3135 defines the new zero-argument form of super() as implicitly >> equivalent to super(__class__, ), and up until 3.2 has >> behaved accordingly: if you accessed __class__ fr

Re: [Python-Dev] PEP 3135 (new super()) __class__ references broken in 3.3

On Sun, 20 May 2012 18:51:27 +1000 Nick Coghlan wrote: > PEP 3135 defines the new zero-argument form of super() as implicitly > equivalent to super(__class__, ), and up until 3.2 has > behaved accordingly: if you accessed __class__ from inside a method, > you would receive a reference to the lexic

[Python-Dev] Backward compatibility of shutil.rmtree

Hi, as our shutil.rmtree() is vulnerable to symlink attacks (see ) I’ve implemented a safe version using os.fwalk() and os.unlinkat() for Python 3.3. Now we face a problem I’d like a broad opinion on: rmtree has a callback hook called `onerror` that that gets cal

Re: [Python-Dev] cpython: Describe the default hash correctly, and mark a couple of CPython

On Sun, May 20, 2012 at 9:04 PM, Charles-François Natali wrote: > Is documenting such implementation details really a good idea? > Apart from preventing further evolutions/improvements/fixes (like the > recent hash randomization), I don't see any benefit in exposing such > details. > FWIW, I clear

Re: [Python-Dev] cpython: Describe the default hash correctly, and mark a couple of CPython

Is documenting such implementation details really a good idea? Apart from preventing further evolutions/improvements/fixes (like the recent hash randomization), I don't see any benefit in exposing such details. FWIW, I clearly remember Josh Bloch warning against this type of documentation in one of

Re: [Python-Dev] cpython: Describe the default hash correctly, and mark a couple of CPython

On Sun, May 20, 2012 at 8:09 PM, Antoine Pitrou wrote: > On Sun, 20 May 2012 10:31:01 +0200 > nick.coghlan wrote: >> + >> +   .. impl-detail:: >> + >> +      CPython uses ``hash(id(x))`` as the default hash for class instances. > > This isn't true: > class C: pass > ... c = C() has

Re: [Python-Dev] cpython: Describe the default hash correctly, and mark a couple of CPython

On Sun, 20 May 2012 10:31:01 +0200 nick.coghlan wrote: > + > + .. impl-detail:: > + > + CPython uses ``hash(id(x))`` as the default hash for class instances. This isn't true: >>> class C: pass ... >>> c = C() >>> hash(c) 619973 >>> id(c) 9919568 >>> hash(id(c)) 9919568 id(...) always h

Re: [Python-Dev] Language reference updated for metaclasses

I think there is a small mistake in section "3.3.3.4. Creating the class object": "After the class object is created, any class decorators included in the *function* definition are invoked ..." That probaly should be "class definition". Daniel ___ Pytho

Re: [Python-Dev] PEP 3135 (new super()) __class__ references broken in 3.3

On Sun, May 20, 2012 at 6:51 PM, Nick Coghlan wrote: > What I plan to do: > 1. Revert the previous fix for #12370 > 2. Add tests for direct access to __class__ from methods > 3. Create a *new* fix for #12370 that only affects the class scope, > not the method bodies (this will be harder than the p

[Python-Dev] PEP 3135 (new super()) __class__ references broken in 3.3

PEP 3135 defines the new zero-argument form of super() as implicitly equivalent to super(__class__, ), and up until 3.2 has behaved accordingly: if you accessed __class__ from inside a method, you would receive a reference to the lexically containing class. In 3.3, that currently doesn't work: you

[Python-Dev] Language reference updated for metaclasses

When writing the docs for types.new_class(), I discovered that the description of the class creation process in the language reference was not only hard to follow, it was actually *incorrect* when it came to describing the algorithm for determining the correct metaclass. I rewrote the offending se