[Python-Dev] Language reference updated for metaclasses

2012-05-20 Thread Nick Coghlan 
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 section of the language reference to both
describe the correct algorithm, and hopefully also to be easier to
read. Once people have had a chance to review the changes in the 3.3
docs, I'll backport the update to 3.2.

Previous docs: 
http://docs.python.org/py3k/reference/datamodel.html#customizing-class-creation
Updated docs: 
http://docs.python.org/dev/reference/datamodel.html#customizing-class-creation

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread 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.

In 3.3, that currently doesn't work: you get NameError instead
(http://bugs.python.org/issue14857)

While the 3.2 behaviour wasn't documented in the language reference,
it's *definitely* documented in PEP 3135 (and my recent updates to the
3.3 version of the metaclass docs were written accordingly - that's
how I discovered the problem)

The error in the alpha releases appears to be a consequence of the
attempt to fix a problem where the special treatment of __class__
meant that you couldn't properly set the __class__ attribute of the
class itself in the class body (see
http://bugs.python.org/issue12370).

The fact that patch went in without causing a test failure means that
this aspect of PEP 3135 has no explicit tests - it was only tested
indirectly through the zero-argument super() construct.

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 previous fix which
affected the resolution of __class__ *everywhere* in the class body).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Nick Coghlan 
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 previous fix which
> affected the resolution of __class__ *everywhere* in the class body).

Correction - I only plan to *reopen* #12370. I agree it's a legitimate
problem with the PEP 3135 implementation, but at least it's not a
regression for something that previously worked in 3.2.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Daniel Urban 
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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Antoine Pitrou 
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 has the lower bits clear, so it was decided to shift it
to the right by a number of bits.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Nick Coghlan 
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()
 hash(c)
> 619973
 id(c)
> 9919568
 hash(id(c))
> 9919568
> id(...) always has the lower bits clear, so it was decided to shift it
> to the right by a number of bits.

Ah, you're right - I misread my own experiment. Regardless, the
hash(c) == id(c) that *was* there was also wrong. I'll just drop the
implementation detail entirely and leave the new wording on its own.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Charles-François Natali 
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 its presentations (and in his excellent
"Effective Java").

Cheers,

cf
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Nick Coghlan 
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 clearly remember Josh Bloch warning against this type of
> documentation in one of its presentations (and in his excellent
> "Effective Java").

We've been weeding a lot of them out over time (e.g. by deleting them
rather than updating them when they change). However, keeping them can
be useful for a couple of reasons:
- sometimes we're explicitly OK with people relying on certain CPython
behaviour (or genuinely want to help them understand that behaviour)
- sometimes it's useful as an additional hint to authors of other
implementations

Mostly (as in this case) they're just due to the past blurriness of
the distinction between Python-the-language and
CPython-the-reference-implementation, though.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Backward compatibility of shutil.rmtree

2012-05-20 Thread Hynek Schlawack 
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 called with amongst others the
function that caused the error (see
).

Two of them differ in the new version: os.fwalk() is used instead of
os.listdir() and os.unlinkat() instead of os.remove().

The safe version is used transparently if available, so this could
potentially break code. Also it would mean that rmtree would behave
differently on Linux & OS X for example.

I’ve been thinking to "fake" the function names, as they map pretty good
anyway. I.e. call onerror with os.listdir if os.fwalk failed and with
os.remove instead of os.unlinkat. That could also make sense if some
kind soul writes a safe rmtree for Windows or OS X so the function works
the same across all platforms. It's a bit ugly though, a cleaner way
would be to start using well defined symbols, but that would break code
for sure.

Opinions?

Cheers,
Hynek
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Antoine Pitrou 
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 lexically containing class.
> 
> In 3.3, that currently doesn't work: you get NameError instead
> (http://bugs.python.org/issue14857)
> 
> While the 3.2 behaviour wasn't documented in the language reference,
> it's *definitely* documented in PEP 3135 (and my recent updates to the
> 3.3 version of the metaclass docs were written accordingly - that's
> how I discovered the problem)

The question is, do we want to support it? What's the use case?

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Nick Coghlan 
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__ from inside a method,
>> you would receive a reference to the lexically containing class.
>>
>> In 3.3, that currently doesn't work: you get NameError instead
>> (http://bugs.python.org/issue14857)
>>
>> While the 3.2 behaviour wasn't documented in the language reference,
>> it's *definitely* documented in PEP 3135 (and my recent updates to the
>> 3.3 version of the metaclass docs were written accordingly - that's
>> how I discovered the problem)
>
> The question is, do we want to support it? What's the use case?

Being able to deconstruct zero-argument super into something simpler
(i.e. an implicit closure reference) makes it a *lot* more
understandable, and lets people create their own variations on that
theme rather than having it be completely opaque black magic (as it is
now in 3.3).

If __class__ had been covered by the test suite, then #12370 would
never have been fixed the way it was.

However, while it isn't mentioned in the language reference (well, not
until I added a mention of it yesterday), PEP 3135 itself *was*
updated to say "Every function will have a cell named __class__ that
contains the class object that the function is defined in". The
special variable is named as part of the specification section of the
PEP. This contrasts with PEP 3115 and the __build_class__ builtin,
where the latter isn't mentioned in the PEP at all - it's just a
CPython implementation artifact.

So this isn't a matter of "What's the use case for accessing __class__
directly?" - it's a matter of "We broke backwards compatibility for a
documented (albeit only in the originating PEP) feature and the test
suite didn't pick it up".

Now, it isn't just a matter of reverting the old patch, because we
need to bump the magic number for the bytecode again. But the fix for
#12370 *is* broken, because it didn't just affect the __class__
references at class scope - it also changed them all at method scope.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Terry Reedy 

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 ;=0.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Martin v. Löwis 

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 function that caused the failure.
I'd weaken the documentation to just specify that the error-causing
function is reported, indicating that the exact set of functions
may depend on the operating system and change across Python versions.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Terry Reedy 


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 than 2**32 will
+  be considered to be IPv4 by default.
+version: An Integer, 4 or 6. If set, don't try to automatically


integer, not Integer


+  determine what the IP address type is. important for things
+  like ip_address(1), which could be IPv4, '192.0.2.1',  or IPv6,
+  '2001:db8::1'.


I read this as saying that a version other than 4 or 6 should be an 
error, and not ignored as if not set. If version is set incorrectly, it 
is still set. I certainly would expect an error to be an error.



+
+Returns:
+An IPv4Address or IPv6Address object.
+
+Raises:
+ValueError: if the string passed isn't either a v4 or a v6
+  address.


Should say "if the *address*...", and I suggest adding "or if the 
version is not None, 4, or 6."

+
+"""
+if version:


if version is not None: ??
Do you really want to silently ignore *every* null value, like '' or []?



+if version == 4:
+return IPv4Address(address)
+elif version == 6:
+return IPv6Address(address)


else: raise ValueError() ??

...


+def ip_network(address, version=None, strict=True):
+"""Take an IP string/int and return an object of the correct type.
+
+Args:
+address: A string or integer, the IP network.  Either IPv4 or
+  IPv6 networks may be supplied; integers less than 2**32 will
+  be considered to be IPv4 by default.
+version: An Integer, if set, don't try to automatically
+  determine what the IP address type is. important for things
+  like ip_network(1), which could be IPv4, '192.0.2.1/32', or IPv6,
+  '2001:db8::1/128'.


Same comments


+def ip_interface(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 than 2**32 will
+  be considered to be IPv4 by default.
+version: An Integer, if set, don't try to automatically
+  determine what the IP address type is. important for things
+  like ip_network(1), which could be IPv4, '192.0.2.1/32', or IPv6,
+  '2001:db8::1/128'.


ditto


+Returns:
+An IPv4Network or IPv6Network object.


Interface, not Network


+def v4_int_to_packed(address):
+"""The binary representation of this address.


Since integers are typically implemented as strings of binary bits, a 
'binary representation' could mean a string of 0s and 1s.



+
+Args:
+address: An integer representation of an IPv4 IP address.
+
+Returns:
+The binary representation of this address.


The integer address packed as 4 bytes in network (big-endian) order.


+Raises:
+ValueError: If the integer is too large to be an IPv4 IP
+  address.


And if the address is too small (negative)? "If the integer is negative 
or ..." ?



+"""
+if address>  _BaseV4._ALL_ONES:


or address < 0?


+raise ValueError('Address too large for IPv4')
+return struct.pack('!I', address)


It is true that struct will raise struct.error: argument out of range 
for negative addresses, but it will also also do the same for too large 
addresses. So either let it propagate or catch it in both cases. For the 
latter (assuming the max is the max 4 byte int):


try:
return struct.pack('!I', address)
except struct.error:
raise ValueError("Address negative or too large for IPv4")


+
+def v6_int_to_packed(address):
+"""The binary representation of this address.


Similar comments, except packed into 16 bytes


+Args:
+address: An integer representation of an IPv4 IP address.
+
+Returns:
+The binary representation of this address.
+"""
+return struct.pack('!QQ', address>>  64, address&  (2**64 - 1))


Why no range check? Here you are letting struct.error propagate.


+
+def _find_address_range(addresses):
+"""Find a sequence of addresses.


An 'address' can in various places be a string, int, bytes, IPv4Address, 
or IPv6Address. For neophyte users, I think you should be clear each 
time you use 'address'. From the code, I conclude it here means the 
latter two.



+
+Args:
+addresses: a list of IPv4 or IPv6 addresses.


a list of IPv#Address objects.


+def _get_prefix_length(number1, number2, bits):
+"""Get the number of leading bits that are same for two numbers.
+
+Args:
+number1: an integer.
+number2: another integer.
+bits: the maximum number of bits to compare.
+
+Returns:
+The number of leading bits that

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

2012-05-20 Thread Antoine Pitrou 
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

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Email6 status

2012-05-20 Thread R. David Murray 
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 land in 3.3 if possible.
> 
> I suspect you're just not going to get much practical feedback on email6 until
> it's available in Python's stdlib.  I don't know how many Python 3 email
> consuming applications there are out there.  The one I'm intimately familiar
> with  still can't port to Python 3 because of its dependencies.

My thought exactly.

> >What I'd like to do is have the second patch introduce the new policies
> >as *provisional policies*.  That is, in the spirit but not the letter
> >of PEP 411, I'd like the new header API to be considered provisional
> >and subject to improvement in 3.4 based on what we learn by having it
> >actually out there in the field and getting tested.
> 
> That seems reasonable to me.  The documentation should be clear as to what's
> provisional and what's stable.  With that, and based on your level of
> confidence, I'd be in favor of getting email6 into Python 3.3.

OK, both patches are now up on the tracker.  The first patch, as
mentioned, does some internal refactoring that makes the policy
framework cleaner and adds hooks and a 'compat32' policy implementation
such that the current Python 3.2 behavior is preserved by default.

That's issue 14731: http://bugs.python.org/issue14731

The second patch adds a policy implementation (marked as provisional)
that adds the new header parsing and folding.  As of this patch only
'Date' type and 'Address' type headers are parsed as anything other than
Unstructured, but that's already worlds better than the compat32 policy.

That's issue 12586: http://bugs.python.org/issue12586

I would appreciate reviews of both patches, even cursory ones.  This
split up should make them as easy to review as such big patches can be:
the goal of 14731 is 100% backward compatibility, so a review can focus
on making sure that the tests match the Python 3.2 tests (with some
additions for bugs fixed).  125867 then adds a bunch of new code that
can be evaluated on its own merits.

Absent objection from patch reviewers, my plan is to apply these patches
before the next alpha (which is scheduled for May 26th, ie: next weekend).

--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Benjamin Peterson 
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 understand why PEP 3135 cares how it's implemented. It's silly
enough that you can get the class by "using" super (even just
referencing the name). Thus that you can get __class__ reeks of more
an implementation detail than a feature to me.

-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread 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 __class__ from inside a method,
>> you would receive a reference to the lexically containing class.
>
> I don't understand why PEP 3135 cares how it's implemented. It's silly
> enough that you can get the class by "using" super (even just
> referencing the name). Thus that you can get __class__ reeks of more
> an implementation detail than a feature to me.

It made sense at the time to discuss the issues together. It was often wanted
to reference the "current class" and super was simply the most common reason
for this and, as was the point of the PEP in the first place, given an even more
direct shortcut.

I never would have considered __class__ a simple implementation detail.

> --
> Regards,
> Benjamin
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Benjamin Peterson 
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 __class__ from inside a method,
>>> you would receive a reference to the lexically containing class.
>>
>> I don't understand why PEP 3135 cares how it's implemented. It's silly
>> enough that you can get the class by "using" super (even just
>> referencing the name). Thus that you can get __class__ reeks of more
>> an implementation detail than a feature to me.
>
> It made sense at the time to discuss the issues together. It was often wanted
> to reference the "current class" and super was simply the most common reason
> for this and, as was the point of the PEP in the first place, given an even 
> more
> direct shortcut.

Well, then, back to the old way it is.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread 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
dependency of the ticket because it seemed generally useful – therefore
I used it for the implementation.

(There has been also been the idea to re-implement the default rmdir
with os.walk to make them more similar; but that's a different story.)

> The way this interface is defined, it's IMO best to do "precise"
> reporting, i.e. pass the exact function that caused the failure.
> I'd weaken the documentation to just specify that the error-causing
> function is reported, indicating that the exact set of functions
> may depend on the operating system and change across Python versions.

So you suggest to not mention all the possible functions at all? That
seems useful to me, as the list will (hopefully) grow anyway and nailing
it down is getting less useful with every new implementation.

Regards,
Hynek
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread martin 


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
dependency of the ticket because it seemed generally useful – therefore
I used it for the implementation.


I think that's a mistake then, because of the limited error reporting.
With os.fwalk, you don't know exactly what it is that failed, but it
may be useful to know.

So I propose to duplicate the walking in rmtree.

I also wonder how exactly in your implementation directory handles
get closed, and how that correlates to attempts at removing the
directories.


(There has been also been the idea to re-implement the default rmdir
with os.walk to make them more similar; but that's a different story.)


-1 on that, for the reasons above.


So you suggest to not mention all the possible functions at all? That
seems useful to me, as the list will (hopefully) grow anyway and nailing
it down is getting less useful with every new implementation.


Exactly. Users would have to look at the code, but that will make them
aware that the code may change. For that reason, also, using fwalk is
a bad idea, since they then will need to trace their code reading into
fwalk.

Regards,
Martin



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Hynek Schlawack 
Am 20.05.12 23:46, schrieb [email protected]:

 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 because it seemed generally useful – therefore
>> I used it for the implementation.
> I think that's a mistake then, because of the limited error reporting.
> With os.fwalk, you don't know exactly what it is that failed, but it
> may be useful to know.

Well, as fwalk does only directory traversing, it means that something
went wrong while doing so. The exception should be more helpful at this
point, no?

> So I propose to duplicate the walking in rmtree.

I'm -1 on that one; the information gain doesn’t seem that big to me and
doing fwalk right isn't trivial (see
).

It’s easy to do a copy’n’paste now but the trade-off of having to
maintain both for a bit more of information from a high level function
doesn’t seem worth to me.

> I also wonder how exactly in your implementation directory handles
> get closed, and how that correlates to attempts at removing the
> directories.

Directory handles get closed inside of fwalk (try/finally) – but I think
it’s easier if you take a quick look yourself before I explain things to
you you didn’t want to know. :)

Regards,
Hynek


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Raymond Hettinger 

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 would be a bad move.
People are using Python2.7 and are going to docs.python.org for information.
This would only disrupt their experience.

It wouldn't "promote" anything, it would just make accessing the documentation
more awkward for the large majority of users who are still on Python 2.

When there is more uptake of Python 3, it would be reasonable move.
If it is done now, it will just create confusion and provide no benefit.


Raymond___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Meador Inge 
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.getmembers documentation
(http://docs.python.org/library/inspect.html#inspect.getmembers):

"""
Note

getmembers() does not return metaclass attributes when the argument is
a class (this behavior is inherited from the dir() function).
"""

In any case, open a tracker issue if you think the documentation needs
to be improved or that there might be a bug.

-- Meador
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Guido van Rossum 
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?  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 would be a bad
> move.
> People are using Python2.7 and are going to docs.python.org for information.
> This would only disrupt their experience.
>
> It wouldn't "promote" anything, it would just make accessing the
> documentation
> more awkward for the large majority of users who are still on Python 2.
>
> When there is more uptake of Python 3, it would be reasonable move.
> If it is done now, it will just create confusion and provide no benefit.
>
>
> Raymond
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Guido van Rossum 
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 specification and through its
lack of rationale. This is the section on Dynamic Path Computation:
(http://www.python.org/dev/peps/pep-0420/#dynamic-path-computation).
The specification bothers me because it requires in-place modification
of sys.path. Does this mean sys.path is no longer a plain list? I'm
sure it's going to break things left and right (or at least things
will be violating this requirement left and right); there has never
been a similar requirement (unlike, e.g., sys.modules, which is
relatively well-known for being cached in a C-level global variable).
Worse, this apparently affects __path__ variables of namespace
packages as well, which are now specified as an unspecified read-only
iterable. (I can only guess that there is a connection between these
two features -- the PEP doesn't mention one.) Again, I would be much
happier with just a list.

While I can imagine there being a use case for recomputing the various
paths, I am much less sure that it is worth attempting to specify that
this will happen *automatically* when sys.path is modified in a
certain way. I'd be much happier if these constraints were struck and
the recomputation had to be requested explicitly by calling some new
function in sys.

>From my POV, this is the only show-stopper for acceptance of PEP 420.
(That is, either a rock-solid rationale should be supplied, or the
constraints should be removed.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Guido van Rossum 
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 implement inspect.
>
> There is already a note in the inspect.getmembers documentation
> (http://docs.python.org/library/inspect.html#inspect.getmembers):
>
> """
> Note
>
> getmembers() does not return metaclass attributes when the argument is
> a class (this behavior is inherited from the dir() function).
> """
>
> In any case, open a tracker issue if you think the documentation needs
> to be improved or that there might be a bug.
>
> -- Meador

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. Basically, you can't trust that inspect.py will
work. I've seen various occasions (sorry, can't remember details)
where some function in it outright crashed when given a slightly
unusual (but not unreasonable) argument. It might be a nice project
for a new contributor to improve this situation.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Nick Coghlan 
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 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 ;=0.
>
> __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> ncoghlan%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Nick Coghlan 
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.djangoproject.com/en/1.4/) that indicated the
current displayed version and provided quick links to the 2.7 docs,
the stable 3.x docs and the development docs. The
versionadded/versionchanged notes in the 3.x series are not adequate
for 2.x development, as everything up to and including 3.0 is taken as
a given - the notes are used solely for changes within the 3.x series.

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 3 migration is having (or is going to
have) on them. *We* know that we care, but there's still plenty of
folks out there that don't realise how deeply rooted the problems are
in Python 2's text model and why the Python 3 backwards compatibility
break was needed to fix them. They don't get to see the debates that
happen on this list - they only get to see the end results of our
decisions. Switching the default docs.python.org version to the 3.x
series is a move that needs to be advertised *well* in advance as a
courtesy to our users, so that those that need to specifically
reference 2.7 have plenty of time to update their links.

Back when Python 3 was first released, we set a target for the
migration period of around 5 years. Since the io performance problems
in 3.0 meant that 3.1 was the first real production ready release of
3.x, that makes June 2014 the target date for when we would like the
following things to be true:
- all major third party libraries and frameworks support Python 3 (or
there are Python 3 forks or functional replacements)
- Python 3 is the default choice for most new Python projects
- most Python instruction uses Python 3, with Python 2 differences
described for those that need to work with legacy code
- (less likely, but possible) user-focused distros such as Ubuntu and
Fedora have changed their "python" symlink to refer to Python 3

That's still 2 years away, and should line up fairly nicely with the
release of Python 3.4 (assuming the current release cadence is
maintained for at least one more version). Key web and networking
frameworks such as Django [1], Pyramid [2] and Twisted [3] should also
be well supported on 3.x by that point.

In the meantime, I propose the following steps be taken in order to
prepare for the eventual migration:
- change the current unqualified URLs into redirects to the
corresponding direct 2.7 URLs
- add a "latest" subpath that is equivalent to the current "py3k" subpath
- add a Django-inspired version switching widget to the CSS & HTML for
the 2.7, 3.2 and trunk docs that offers the following options: 2.7,
3.2, latest (3.2), dev (3.3).

Cheers,
Nick.

[1] https://www.djangoproject.com/weblog/2012/mar/13/py3k/
[2] 
http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/whatsnew-1.3.html
[3] http://twistedmatrix.com/trac/milestone/Python-3.x

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread martin 

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 3 migration is having (or is going to
have) on them.


I don't think users will have *that* feeling. I got comments that users
were puzzled that we kept continuing development on 2.x when 3.x was
released, so users do recognize that the migration to 3.x is not abrupt.


*We* know that we care, but there's still plenty of
folks out there that don't realise how deeply rooted the problems are
in Python 2's text model and why the Python 3 backwards compatibility
break was needed to fix them.


I don't think users care much about philosophical or abstract engineering
differences between the versions when thinking about porting. I'd expect
that most of them agree, in the abstract, that they will have to port to
Python 3 eventually. Some, of course, wish to stay with Python 2 forever,
and wish that this Python 3 madness is simply abandoned.

That they don't port is often caused by missing dependencies. If all
dependencies are met, it's caused by simple lack of time and energy.


Back when Python 3 was first released, we set a target for the
migration period of around 5 years.


Maybe you set this target for yourself. I set "Python 3.2/3.3" as a
target. I think Guido set an even earlier target initially.

Regards,
Martin


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Terry Reedy 

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 
look a bit like a second-class citizen on the site. It has previously 
been our policy that each new production-ready release takes 'pride of 
place' at docs.python.org. Not doing so even with 3.3, *and doing 
nothing else*, could be taken as implying that we lack full confidence 
in the release.


On the other hand, I am sympathetic to Raymond's and Nick's points that 
switching might seem too much 'in their faces' for Py 2 users, 
especially those who do not have or use an offline help file as their 
everyday reference. I want Python 3 to get equal billing, but not to 
generate reaction against it.


I also suggest docs2.python.org as the permanent home for latest python 
2 docs for as long as it seems sensible (probably a decade at least). 
Make that operable now and suggest on the front page of docs.python.org 
that py2 users switch before 3.4.



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.djangoproject.com/en/1.4/) that indicated the
current displayed version and provided quick links to the 2.7 docs,
the stable 3.x docs and the development docs.


Each page of our docs say "Python 3.3.0a3 Documentation", or the 
equivalent, at the top. So we already have that covered. The drop-down 
version selection box on the django page seems to only apply to 
searches. Merely selecting a different version does not trigger anything.


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, and 
non-trivial I expect). For someone trying to write combined 2/3 code, or 
merely to learn the other version, I would think it useful to be able to 
jump to the corresponding page for the other version.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Stefano Taschini 
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. Basically, you can't trust that inspect.py will
> work. I've seen various occasions (sorry, can't remember details)
> where some function in it outright crashed when given a slightly
> unusual (but not unreasonable) argument. It might be a nice project
> for a new contributor to improve this situation.
> [...]
>

An example that crashes is

>>> def f(l, (x, y)):
...sup = max(u*x + v*y for u, v in l)
...return ((u, v) for u, v in l if u*x + v*y == sup)
>>> inspect.getargspec(f)


See http://bugs.python.org/issue14611 . I did submit a patch, a few weeks
ago.

Stefano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread 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 was about to post the exact same idea.

Please, no - proliferating subdomains can quickly get confusing and
hard to remember. It makes sense up to a point (e.g. separating out
the docs from everything else on python.org), but having multiple docs
subdomains is completely unnecessary when we already have directory
based versioning.

Namespaces are a great idea, let's do more of those :)

> docs.python.org/py3k is a bit obscure and buried and makes Python 3.x look a
> bit like a second-class citizen on the site. It has previously been our
> policy that each new production-ready release takes 'pride of place' at
> docs.python.org. Not doing so even with 3.3, *and doing nothing else*, could
> be taken as implying that we lack full confidence in the release.

Having "http://docs.python.org/latest"; refer to Python 3.x would
remove the "second class citizen" status, as well as providing a clear
indication right in the URL that docs.python.org contains more content
than just the latest version of the docs. The unqualified URLs could
then become redirects to "latest" after a suitable migration period
with a notification and a link to the 2.7 version specific docs on
each page.

For example, at the release of 3.3, each page of the default docs on
the website could be updated with a note like the following:

"The default documentation pages will be switching to the Python 3
series in February 2012, 6 months after the release of Python 3.3. The
permanent link for the 2.7 version of this page is: "

> On the other hand, I am sympathetic to Raymond's and Nick's points that
> switching might seem too much 'in their faces' for Py 2 users, especially
> those who do not have or use an offline help file as their everyday
> reference. I want Python 3 to get equal billing, but not to generate
> reaction against it.

Right, and switching the default docs without a suitable notice period
would be a great way to generate confusion. Migrating to a "latest"
URL has no such negative impact:
- the new URLs become available immediately for those that want to use them
- the old URLs can be converted to 301 redirects after a suitable warning period

> I also suggest docs2.python.org as the permanent home for latest python 2
> docs for as long as it seems sensible (probably a decade at least). Make
> that operable now and suggest on the front page of docs.python.org that py2
> users switch before 3.4.

I think "http://docs.python.org/2.7"; is fine as the long term home for
the final version of the Python 2 documentation (it also has the
virtue of already existing).

>> 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.djangoproject.com/en/1.4/) that indicated the
>> current displayed version and provided quick links to the 2.7 docs,
>> the stable 3.x docs and the development docs.
>
> Each page of our docs say "Python 3.3.0a3 Documentation", or the equivalent,
> at the top. So we already have that covered. The drop-down version selection
> box on the django page seems to only apply to searches. Merely selecting a
> different version does not trigger anything.
>
> 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, and non-trivial I
> expect). For someone trying to write combined 2/3 code, or merely to learn
> the other version, I would think it useful to be able to jump to the
> corresponding page for the other version.

That's what the Django widget does. I'm not talking about their search
form - I'm talking about the floating CSS box that appears in the
bottom right of each page and stays there as you scroll down. If you
click on it, the list of available documentation versions appears,
with direct links to the corresponding page in the other versions.

It has several attractive features:
- always present, even when you scroll down on a long page
- unobtrusive when you don't need it (only displays current version by
default, have to click it to get the list of all versions)
- direct links to the corresponding page in other versions

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Benjamin Peterson 
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 was about to post the exact same idea.
>
> Please, no - proliferating subdomains can quickly get confusing and
> hard to remember. It makes sense up to a point (e.g. separating out
> the docs from everything else on python.org), but having multiple docs
> subdomains is completely unnecessary when we already have directory
> based versioning.
>
> Namespaces are a great idea, let's do more of those :)

A subdomain isn't a namespace?


-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2012-05-20 Thread Terry Reedy 

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, and non-trivial I
expect). For someone trying to write combined 2/3 code, or merely to learn
the other version, I would think it useful to be able to jump to the
corresponding page for the other version.


That's what the Django widget does. I'm not talking about their search
form - I'm talking about the floating CSS box that appears in the
bottom right of each page and stays there as you scroll down. If you
click on it, the list of available documentation versions appears,
with direct links to the corresponding page in the other versions.

It has several attractive features:
- always present, even when you scroll down on a long page
- unobtrusive when you don't need it (only displays current version by
default, have to click it to get the list of all versions)
- direct links to the corresponding page in other versions


I see it now. Very nice. I hope our doc people can duplicate it.

--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com