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

[Nick Coghlan]

On Mon, May 21, 2012 at 4:32 PM, Benjamin Peterson  wrote:
> 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?

A subdomain is only a namespace if you use it as one. The following
would be using docs.python.org as a namespace (and is what I think we
should move towards):

docs.python.org/latest
docs.python.org/dev
docs.python.org/3.2
docs.python.org/3.1
docs.python.org/2.7
docs.python.org/2.6
etc...

The following is *not* using it as a namespace:

docs.python.org # 2.7
docs3.python.org # 3.2

Cheers,
Nick.

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

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

[Hynek Schlawack]

>>> Namespaces are a great idea, let's do more of those :)
>> A subdomain isn't a namespace?
> A subdomain is only a namespace if you use it as one. The following
> would be using docs.python.org as a namespace (and is what I think we
> should move towards):
> 
> docs.python.org/latest
> docs.python.org/dev
> docs.python.org/3.2
> docs.python.org/3.1
> docs.python.org/2.7
> docs.python.org/2.6
> etc...

Bikesheddingly, I’d prefer “stable” over ”latest”. That would also
better convey the point that 3 is ready for production.

Otherwise +1; I find the current hybrid structure suboptimal.

Also -1 on docs3, that would suggest that it’s still something special
and 2 (= docs) is the real deal.

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

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

[Stephen J. Turnbull]

Nick Coghlan writes:

 > > A subdomain isn't a namespace?
 > 
 > A subdomain is only a namespace if you use it as one. The following
 > would be using docs.python.org as a namespace (and is what I think we
 > should move towards):

+1

 > The following is *not* using it as a namespace:
 > 
 > docs.python.org # 2.7
 > docs3.python.org # 3.2

No, but it *is* using "python.org" as a namespace.  I personally think
this is ugly and hard to use, but I'm hard-pressed to explain why. :-(
I hope you can do better (the above isn't going to convince anybody
who currently holds the opposite opinion).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

On 5/20/2012 9:33 PM, Guido van Rossum wrote:
> 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.

sys.path would still be a plain list. It's the namespace package's
__path__ that would be a special object. Every time __path__ is accessed
it checks to see if it's parent path has been modified. The parent path
for top level modules is sys.path. The __path__ object detects
modification by keeping a local copy of the parent, plus a reference to
the parent, and compares them.

> 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.)

I don't have a preference on whether the feature stays or goes, so I'll
let PJE give the use case. I've copied him here in case he doesn't read
python-dev.

Now that I think about it some more, the motivation is probably to ease
the migration from setuptools, which does provide this feature.

Eric.


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

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

[Paul Moore]

On 21 May 2012 08:35, Hynek Schlawack  wrote:
> Also -1 on docs3, that would suggest that it’s still something special
> and 2 (= docs) is the real deal.

Good point.
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steven D'Aprano]

On Mon, May 21, 2012 at 01:47:50AM -0400, 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.

+1


-- 
Steven

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

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

[Łukasz Langa]

Wiadomość napisana przez Nick Coghlan w dniu 21 maj 2012, o godz. 09:24:

> The following
> would be using docs.python.org as a namespace (and is what I think we
> should move towards):
> 
> docs.python.org/latest
> docs.python.org/dev
> docs.python.org/3.2
> docs.python.org/3.1
> docs.python.org/2.7
> docs.python.org/2.6

Love it. +1

I also like the Django-like "Documentation version" bubble. Makes navigating 
between versions simple regardless where you got the original link from. Blog 
posts and search engines often keep links to outdated versions.

-- 
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

http://lukasz.langa.pl/
+48 791 080 144

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

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

[Antoine Pitrou]

On Mon, 21 May 2012 14:28:06 +1000
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.
> 
> 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.

+1.
There will be some subtleties: for example, the 2.x docs for urllib2
will have to link to the 3.x docs for urllib.request.

Regards

Antoine.


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

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

[Georg Brandl]

On 05/21/2012 03:23 AM, Guido van Rossum wrote:
> I suggest that we add a separate (virtual) subdomain, e.g. docs3.python.org.

Here are the time machine keys: this subdomain has existed for a few years now 
:)

Georg

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

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

[Christian Tismer]

On 21.05.12 07:52, Stefano Taschini wrote:
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.


Nice finding, not related to dir() usage but very useful to know.
I looked over test_inspect.py a bit, which is quite big and has many
tests, although very little references to reported bugs, and this
opcode combination was obviously missing in the test cases.

Did not find your patch yet (no time), but hope you added an extra
testcase with explicit reference to the bug reported.

inspect is very nice and useful in many cases, but sometimes not. Instead
of using things like currentframe() I have a look and write my own version
because the convenience is too little compared to an extra import and
dependency. And although currentframe() is mentioned in test_inspect,
I cannot find any direct testcase for it that really calls this function.

Admittedly a trivial case, but it is one reason, besides dissed dir() usage,
that makes me think of 'suspect' ;-)

Instead, I'd love to use inspect as the basis to write reliable, portable
code, because its abstraction hides implementation details nicely.
I think we have reached when things like sys._getframe() are declared
as deprecated.

""" This is no longer recommended to use. Use inspect.currentframe 
instead """


cheers - chris

--
Christian Tismer :^)
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key ->  http://pgp.uni-mainz.de
work +49 173 24 18 776  mobile +49 173 24 18 776  fax n.a.
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

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

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

[Serhiy Storchaka]

On 18.05.12 21:30, Brian Curtin wrote:

On May 18, 2012 1:26 PM, "Barry Warsaw" mailto:ba...@python.org>> wrote:
 > At what point should we cut over docs.python.org
 to point to the Python 3
 > documentation by default?

Today sounds good to me.


Yesterday. ;-)  Issue14469.

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

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

[Georg Brandl]

On 05/21/2012 11:09 AM, Łukasz Langa wrote:
> Wiadomość napisana przez Nick Coghlan w dniu 21 maj 2012, o godz. 09:24:
> 
>> The following
>> would be using docs.python.org as a namespace (and is what I think we
>> should move towards):
>> 
>> docs.python.org/latest
>> docs.python.org/dev
>> docs.python.org/3.2
>> docs.python.org/3.1
>> docs.python.org/2.7
>> docs.python.org/2.6
> 
> Love it. +1

Apart from the "latest" one, all these URLs already work.

Of course, /2.7 is redirected to /, and /3.3 to /dev, etc.
If required, the direction of these redirects can be changed, so
that e.g. / goes to /2.7.

What about:

* Canonical:

docs.python.org/2/
docs.python.org/3/

for latest versions of 2.x and 3.x

docs.python.org/2.7/ etc.

for latest minor versions

docs.python.org/dev/

for latest dev version.

* Redirected:

docs.python.org/  -->  either /2/ or /3/ or a "disambiguation page"
docs.python.org/py3k/ -> /3/

There is also /release/X.Y.Z for individual released versions, which
I don't want to change.


I also like Martin's idea of offering more links between individual pages, not
only the front-pages.

Georg

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

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

[R. David Murray]

On Mon, 21 May 2012 11:41:29 +0200, Georg Brandl  wrote:
> On 05/21/2012 03:23 AM, Guido van Rossum wrote:
> > I suggest that we add a separate (virtual) subdomain, e.g. docs3.python.org.
> 
> Here are the time machine keys: this subdomain has existed for a few years 
> now :)

The fact that none of us knew about it may say something about its
effectiveness, though.

As long as it does exist, there ought to be a parallel docs2.python.org.

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

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

[Nick Coghlan]

On Mon, May 21, 2012 at 9:42 PM, Georg Brandl  wrote:
> Apart from the "latest" one, all these URLs already work.

Yeah, I was just extending the scheme I already knew existed :)

> Of course, /2.7 is redirected to /, and /3.3 to /dev, etc.
> If required, the direction of these redirects can be changed, so
> that e.g. / goes to /2.7.
>
> What about:
>
> * Canonical:
>
> docs.python.org/2/
> docs.python.org/3/
>
> for latest versions of 2.x and 3.x
>
> docs.python.org/2.7/ etc.
>
> for latest minor versions
>
> docs.python.org/dev/
>
> for latest dev version.
>
> * Redirected:
>
> docs.python.org/  -->  either /2/ or /3/ or a "disambiguation page"
> docs.python.org/py3k/ -> /3/

Works for me. It also means we're covered if Guido ever finds a reason
to create Python 4000 :)

> I also like Martin's idea of offering more links between individual pages, not
> only the front-pages.

Definite +1 on that. I personally like Django's version selector (for
reasons stated elsewhere in the thread), but anything that makes it
easier to hop between versions would be good.

Cheers,
Nick.

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

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

[Guido van Rossum]

On Sun, May 20, 2012 at 10: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.
>
> 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.

Right. I don't think new subdomains and the improvements that Nick
suggests are incompatible. docs2 and docs3 can just redirect to to
docs/. It's just that docs2 and docs3 make it easier to
type or link to the (super-major) version you care about. (docs2
should be an alias for 2.7; docs3 for the latest released 3.x
version.)

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

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

[Guido van Rossum]

On Mon, May 21, 2012 at 1:00 AM, Eric V. Smith  wrote:
> On 5/20/2012 9:33 PM, Guido van Rossum wrote:
>> 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.
>
> sys.path would still be a plain list. It's the namespace package's
> __path__ that would be a special object. Every time __path__ is accessed
> it checks to see if it's parent path has been modified. The parent path
> for top level modules is sys.path. The __path__ object detects
> modification by keeping a local copy of the parent, plus a reference to
> the parent, and compares them.

Ah, I see. But I disagree that this is a reasonable constraint on
sys.path. The magic __path__ object of a toplevel namespace module
should know it is a toplevel module, and explicitly refetch sys.path
rather than just keeping around a copy.

This leaves the magic __path__ objects for namespace modules, which I
could live with, as long as their repr was not the same as a list, and
assuming a good rationale is given. Although I'd still prefer plain
lists here as well; I'd like to be able to manually construct a
namespace package and force its directories to be a specific set of
directories that I happen to know about, regardless of whether they
are related to sys.path or not. And I'd like to know that my setup in
that case would not be disturbed by changes to sys.path.

>> 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.)
>
> I don't have a preference on whether the feature stays or goes, so I'll
> let PJE give the use case. I've copied him here in case he doesn't read
> python-dev.
>
> Now that I think about it some more, the motivation is probably to ease
> the migration from setuptools, which does provide this feature.

I'd like to hear more about this from Philip -- is that feature
actually widely used? What would a package have to do if the feature
didn't exist? I'd really much rather not have this feature, which
reeks of too  much magic to me. (An area where Philip and I often
disagree. :-)

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

[Python-Dev] ossaudiodev and linuxaudiodev not built on SLES11SP2 due to change in sys.platform

[Wempa, Kristofer]

I am currently working on porting our Linux tool chains to SuSe Enterprise 
Linux 11 service pack 2 (SLES11SP2).  During this process, we noticed an issue 
due to a change in the sys.platform string.  Previously, the string was 
"linux2" and it has now changed to "linux3".  This seems to be due to a change 
in the kernel version.  This causes the ossaudiodev and linuxaudiodev modules 
to be omitted from the build.  I found the relevant code in setup.py:

if platform == 'linux2':
# Linux-specific modules
exts.append( Extension('linuxaudiodev', ['linuxaudiodev.c']) )
else:
missing.append('linuxaudiodev')

if platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
'freebsd7', 'freebsd8'):
exts.append( Extension('ossaudiodev', ['ossaudiodev.c']) )
else:
missing.append('ossaudiodev')

Since neither of these account for "linux3", they are both omitted from the 
build.  I can simply modify the code to include "linux3" so that these modules 
are built on the new platform.  However, I wanted to check and see whether they 
are specifically being omitted for a reason or if the setup file just wasn't 
ported and tested against the new platform.  Any help would be appreciated.  
Thanks.

Kris




IMPORTANT: The information contained in this email and/or its attachments is 
confidential. If you are not the intended recipient, please notify the sender 
immediately by reply and immediately delete this message and all its 
attachments. Any review, use, reproduction, disclosure or dissemination of this 
message or any attachment by an unintended recipient is strictly prohibited. 
Neither this message nor any attachment is intended as or should be construed 
as an offer, solicitation or recommendation to buy or sell any security or 
other financial instrument. Neither the sender, his or her employer nor any of 
their respective affiliates makes any warranties as to the completeness or 
accuracy of any of the information contained herein or that this message or any 
of its attachments is free of viruses.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ossaudiodev and linuxaudiodev not built on SLES11SP2 due to change in sys.platform

[Wempa, Kristofer]

Sorry, I forgot to mention that this is for Python 2.6.8 and 2.7.3.


From: python-dev-bounces+kristofer.wempa=sig@python.org 
[mailto:python-dev-bounces+kristofer.wempa=sig@python.org] On Behalf Of 
Wempa, Kristofer
Sent: Monday, May 21, 2012 10:49 AM
To: python-dev@python.org
Subject: [Python-Dev] ossaudiodev and linuxaudiodev not built on SLES11SP2 due 
to change in sys.platform


I am currently working on porting our Linux tool chains to SuSe Enterprise 
Linux 11 service pack 2 (SLES11SP2).  During this process, we noticed an issue 
due to a change in the sys.platform string.  Previously, the string was 
"linux2" and it has now changed to "linux3".  This seems to be due to a change 
in the kernel version.  This causes the ossaudiodev and linuxaudiodev modules 
to be omitted from the build.  I found the relevant code in setup.py:

if platform == 'linux2':
# Linux-specific modules
exts.append( Extension('linuxaudiodev', ['linuxaudiodev.c']) )
else:
missing.append('linuxaudiodev')

if platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
'freebsd7', 'freebsd8'):
exts.append( Extension('ossaudiodev', ['ossaudiodev.c']) )
else:
missing.append('ossaudiodev')

Since neither of these account for "linux3", they are both omitted from the 
build.  I can simply modify the code to include "linux3" so that these modules 
are built on the new platform.  However, I wanted to check and see whether they 
are specifically being omitted for a reason or if the setup file just wasn't 
ported and tested against the new platform.  Any help would be appreciated.  
Thanks.

Kris




IMPORTANT: The information contained in this email and/or its attachments is 
confidential. If you are not the intended recipient, please notify the sender 
immediately by reply and immediately delete this message and all its 
attachments. Any review, use, reproduction, disclosure or dissemination of this 
message or any attachment by an unintended recipient is strictly prohibited. 
Neither this message nor any attachment is intended as or should be construed 
as an offer, solicitation or recommendation to buy or sell any security or 
other financial instrument. Neither the sender, his or her employer nor any of 
their respective affiliates makes any warranties as to the completeness or 
accuracy of any of the information contained herein or that this message or any 
of its attachments is free of viruses.



IMPORTANT: The information contained in this email and/or its attachments is 
confidential. If you are not the intended recipient, please notify the sender 
immediately by reply and immediately delete this message and all its 
attachments. Any review, use, reproduction, disclosure or dissemination of this 
message or any attachment by an unintended recipient is strictly prohibited. 
Neither this message nor any attachment is intended as or should be construed 
as an offer, solicitation or recommendation to buy or sell any security or 
other financial instrument. Neither the sender, his or her employer nor any of 
their respective affiliates makes any warranties as to the completeness or 
accuracy of any of the information contained herein or that this message or any 
of its attachments is free of viruses.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ossaudiodev and linuxaudiodev not built on SLES11SP2 due to change in sys.platform

[Christian Heimes]

Am 21.05.2012 16:53, schrieb Wempa, Kristofer:
> Sorry, I forgot to mention that this is for Python 2.6.8 and 2.7.3.

You must be mistaken, Python 2.7.3 has a fix for the issue. configure
checks for linux*:

  linux*) MACHDEP="linux2";;

On the other hand Python 2.6.8 has no such fix and thus sets linux3 on
Kernel 3.0 and newer. You have fix it yourself as described in my blog
http://lipyrary.blogspot.de/2011/09/python-and-linux-kernel-30-sysplatform.html

Christian

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

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

[David Malcolm]

On Fri, 2012-05-18 at 14:24 -0400, 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?

If we do, perhaps we should revisit http://bugs.python.org/issue10446

http://hg.python.org/cpython/rev/b41404a3f7d4/ changed pydoc in the py3k
branch to direct people to http://docs.python.org/X.Y/library/ rather
than to http://docs.python.org/library/

This was applied to the 3.2 and 3.1 branches, but hasn't been backported
to any of the 2.* - so if docs.python.org starts defaulting to python 3,
it makes sense to backport that change to 2.*


Hope this is helpful
Dave


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

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

[Georg Brandl]

On 05/21/2012 02:14 PM, R. David Murray wrote:
> On Mon, 21 May 2012 11:41:29 +0200, Georg Brandl  wrote:
>> On 05/21/2012 03:23 AM, Guido van Rossum wrote:
>> > I suggest that we add a separate (virtual) subdomain, e.g. 
>> > docs3.python.org.
>> 
>> Here are the time machine keys: this subdomain has existed for a few years 
>> now :)
> 
> The fact that none of us knew about it may say something about its
> effectiveness, though.

Sure.  I was never fond of it, but there was a discussion probably similar
to this one, and it was agreed to add that subdomain.

Georg

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

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

[Barry Warsaw]

On May 20, 2012, at 04:27 PM, Raymond Hettinger wrote:

>When there is more uptake of Python 3, it would be reasonable move.

How do we measure this, and what's the milestone for enough uptake to make
the switch?

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Reedy]

On 5/21/2012 3:35 AM, Hynek Schlawack wrote:


Also -1 on docs3, that would suggest that it’s still something special
and 2 (= docs) is the real deal.


Guido and I are proposing docs2 and docs3 each pointing to the latest 
docs for each series. That puts them on equal status.

docs.python.org, besides being a namespace for specific version docs
(/x.y, minus Nick's /latest) would be transitioned away from being a 
synonym for docs2. It could become a *neutral* index page listing docs2 
and docs3 for the 'latest' production version of each series and then 
each subdirectory.


--
Terry Jan Reedy


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

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

[Terry Reedy]

On 5/21/2012 3:24 AM, Nick Coghlan wrote:


docs.python.org/latest
docs.python.org/dev
docs.python.org/3.2
docs.python.org/3.1
docs.python.org/2.7
docs.python.org/2.6
etc...


This looks great except for 'latest', which is ambiguous and awkward.

Like Guido, I would have docs2 and docs3 link to the latest of each 
series. This gives both series equal billing. docs itself could then 
become a *neutral* index page. In retrospect, I wish we had done this a 
year ago.


This design would continue to work if and when we need docs4.python.org.

--
Terry Jan Reedy

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

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

[Antoine Pitrou]

On Mon, 21 May 2012 12:03:31 -0400
Terry Reedy  wrote:
> On 5/21/2012 3:24 AM, Nick Coghlan wrote:
> 
> > docs.python.org/latest
> > docs.python.org/dev
> > docs.python.org/3.2
> > docs.python.org/3.1
> > docs.python.org/2.7
> > docs.python.org/2.6
> > etc...
> 
> This looks great except for 'latest', which is ambiguous and awkward.
> 
> Like Guido, I would have docs2 and docs3 link to the latest of each 
> series. This gives both series equal billing. docs itself could then 
> become a *neutral* index page. In retrospect, I wish we had done this a 
> year ago.

I don't like docs2/docs3. First, they are clumsy to type and look
awkward. Second, it's not the right level of segregation; if you wanted
separate domains you'd really want docs.python2.org and
docs.python3.org.

So, in the end, I think the current scheme is ok and we only need to
add a "/stable" pointing to latest 3.x.

Regards

Antoine.


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

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

[Barry Warsaw]

On May 21, 2012, at 02:28 PM, Nick Coghlan wrote:

>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.

I'd be all for this, as long as I can still write
chrome/firefox/genericbrowser shortcuts to give me the latest Python 2 or
Python 3 library page.

>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.

Right.  I'm just keen on continuing to make progress.  I really do think we're
not far from a tipping point on Python 3, and I want to keep nudging us over
the edge.  Roller coasters are scary *and* fun. :)

>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:

If history is repeated, my guess is that will put us a few months into Python
3.5 development.  I think Python 3.3 is shaping up to be a fantastic release,
and once it's out we should start thinking about what we want to accomplish in
Python 3.4 to achieve the goal of Python 3 dominance.

>- all major third party libraries and frameworks support Python 3 (or
>there are Python 3 forks or functional replacements)

There's already great ongoing work on this.  It could use more help of course.
I've mentioned Ubuntu's efforts here before, but this is really more about the
greater Python universe, and getting Python 3 on the radar of more and more
projects.

>- Python 3 is the default choice for most new Python projects

When I talk to folks starting new Python projects, I always push for it to
begin in Python 3.  Of course, the state of their dependencies is always a
consideration, but this is becoming more feasible for more projects every day.

>- 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

I doubt Debian/Ubuntu will ever switch /usr/bin/python though PEP 394 will
probably have the final word.

>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.

Rough estimate, assuming 18 month cadences and an on-time release of 3.3,
puts 3.4 final in February of 2014.

>>> final33 = datetime.datetime(day=25, month=8, year=2012)
>>> final34 = final33 + datetime.timedelta(days=18 * 30)
>>> final34.isoformat()
'2014-02-16T00:00:00'

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Reedy]

On 5/21/2012 7:42 AM, Georg Brandl wrote:

On 05/21/2012 11:09 AM, Łukasz Langa wrote:

Wiadomość napisana przez Nick Coghlan w dniu 21 maj 2012, o godz. 09:24:


The following
would be using docs.python.org as a namespace (and is what I think we
should move towards):

docs.python.org/latest
docs.python.org/dev
docs.python.org/3.2
docs.python.org/3.1
docs.python.org/2.7
docs.python.org/2.6


Love it. +1


Apart from the "latest" one, all these URLs already work.

Of course, /2.7 is redirected to /, and /3.3 to /dev, etc.
If required, the direction of these redirects can be changed, so
that e.g. / goes to /2.7.

What about:

* Canonical:

docs.python.org/2/
docs.python.org/3/


If you prefer these to docs2, docs3, OK with me.
Whatever we do, we should encourage book/blog writers to use the 
canonical 'latest' links that will not go out of date. So there should 
definitely be one for each, with the same format. The exact format is 
less important.



for latest versions of 2.x and 3.x

docs.python.org/2.7/ etc.

for latest minor versions

docs.python.org/dev/

for latest dev version.

* Redirected:

docs.python.org/  -->   either /2/ or /3/ or a "disambiguation page"


While I am a strong partisan of Py 3, I do not want Py 2 users to feel 
'pushed', so I vote for a neutral index or 'disambiguation' page.


What I would do is set up the canonical pages now. Next, add a notice to 
the top of docs.python.org that it will become a neutral index page with 
the release of 3.3, so 'please change bookmarks to the new, permanent 
page for Py 2', whatever it is.



docs.python.org/py3k/ ->  /3/



There is also /release/X.Y.Z for individual released versions, which
I don't want to change.


I would leave those alone too.

--
Terry Jan Reedy


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

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

[R. David Murray]

On Mon, 21 May 2012 11:19:56 -0400, David Malcolm  wrote:
> On Fri, 2012-05-18 at 14:24 -0400, 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?
> 
> If we do, perhaps we should revisit http://bugs.python.org/issue10446
> 
> http://hg.python.org/cpython/rev/b41404a3f7d4/ changed pydoc in the py3k
> branch to direct people to http://docs.python.org/X.Y/library/ rather
> than to http://docs.python.org/library/
> 
> This was applied to the 3.2 and 3.1 branches, but hasn't been backported
> to any of the 2.* - so if docs.python.org starts defaulting to python 3,
> it makes sense to backport that change to 2.*

Note that I did apply the fix for 14434 to 2.7.  So yes, I think 10446
should be applied to 2.7 as well.

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

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

[Hynek Schlawack]

>> Also -1 on docs3, that would suggest that it’s still something special
>> and 2 (= docs) is the real deal.
> Guido and I are proposing docs2 and docs3 each pointing to the latest
> docs for each series. That puts them on equal status.
> docs.python.org, besides being a namespace for specific version docs
> (/x.y, minus Nick's /latest) would be transitioned away from being a
> synonym for docs2. It could become a *neutral* index page listing docs2
> and docs3 for the 'latest' production version of each series and then
> each subdirectory.

I find docs2/3 ugly as it reminds me of load balancing (like
www1.python.org) and it also doesn’t really make sense to me. I have no
problem to have these DNS records and redirect them to docs.python.org/2
or /3 but I wouldn’t like them to be the canonical URIs.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Close #13585: add contextlib.ExitStack to replace the ill-fated

[Georg Brandl]

Am 21.05.2012 14:54, schrieb nick.coghlan:
> http://hg.python.org/cpython/rev/8ef66c73b1e1
> changeset:   77095:8ef66c73b1e1
> user:Nick Coghlan 
> date:Mon May 21 22:54:43 2012 +1000
> summary:
>   Close #13585: add contextlib.ExitStack to replace the ill-fated 
> contextlib.nested API
> 
> files:
>   Doc/library/contextlib.rst  |  279 +++-
>   Doc/whatsnew/3.3.rst|   15 +
>   Lib/contextlib.py   |  126 ++-
>   Lib/test/test_contextlib.py |  123 ++
>   Misc/NEWS   |2 +
>   5 files changed, 539 insertions(+), 6 deletions(-)
> 
> 
> diff --git a/Doc/library/contextlib.rst b/Doc/library/contextlib.rst
> --- a/Doc/library/contextlib.rst
> +++ b/Doc/library/contextlib.rst
> @@ -12,8 +12,11 @@
>  statement. For more information see also :ref:`typecontextmanager` and
>  :ref:`context-managers`.
>  
> -Functions provided:
>  
> +Utilities
> +-
> +
> +Functions and classes provided:
>  
>  .. decorator:: contextmanager
>  
> @@ -168,6 +171,280 @@
> .. versionadded:: 3.2
>  
>  
> +.. class:: ExitStack()
> +
> +   A context manager that is designed to make it easy to programmatically
> +   combine other context managers and cleanup functions, especially those
> +   that are optional or otherwise driven by input data.
> +
> +   For example, a set of files may easily be handled in a single with
> +   statement as follows::
> +
> +  with ExitStack() as stack:
> +  files = [stack.enter_context(open(fname)) for fname in filenames]
> +  # All opened files will automatically be closed at the end of
> +  # the with statement, even if attempts to open files later
> +  # in the list throw an exception
> +
> +   Each instance maintains a stack of registered callbacks that are called in
> +   reverse order when the instance is closed (either explicitly or implicitly
> +   at the end of a ``with`` statement). Note that callbacks are *not* invoked
> +   implicitly when the context stack instance is garbage collected.
> +
> +   This stack model is used so that context managers that acquire their
> +   resources in their ``__init__`` method (such as file objects) can be
> +   handled correctly.
> +
> +   Since registered callbacks are invoked in the reverse order of
> +   registration, this ends up behaving as if multiple nested ``with``
> +   statements had been used with the registered set of callbacks. This even
> +   extends to exception handling - if an inner callback suppresses or 
> replaces
> +   an exception, then outer callbacks will be passed arguments based on that
> +   updated state.
> +
> +   This is a relatively low level API that takes care of the details of
> +   correctly unwinding the stack of exit callbacks. It provides a suitable
> +   foundation for higher level context managers that manipulate the exit
> +   stack in application specific ways.
> +
> +   .. method:: enter_context(cm)
> +
> +  Enters a new context manager and adds its :meth:`__exit__` method to
> +  the callback stack. The return value is the result of the context
> +  manager's own :meth:`__enter__` method.
> +
> +  These context managers may suppress exceptions just as they normally
> +  would if used directly as part of a ``with`` statement.
> +
> +   .. method:: push(exit)
> +
> +  Adds a context manager's :meth:`__exit__` method to the callback stack.
> +
> +  As ``__enter__`` is *not* invoked, this method can be used to cover
> +  part of an :meth:`__enter__` implementation with a context manager's 
> own
> +  :meth:`__exit__` method.
> +
> +  If passed an object that is not a context manager, this method assumes
> +  it is a callback with the same signature as a context manager's
> +  :meth:`__exit__` method and adds it directly to the callback stack.
> +
> +  By returning true values, these callbacks can suppress exceptions the
> +  same way context manager :meth:`__exit__` methods can.
> +
> +  The passed in object is returned from the function, allowing this
> +  method to be used is a function decorator.
> +
> +   .. method:: callback(callback, *args, **kwds)
> +
> +  Accepts an arbitrary callback function and arguments and adds it to
> +  the callback stack.
> +
> +  Unlike the other methods, callbacks added this way cannot suppress
> +  exceptions (as they are never passed the exception details).
> +
> +  The passed in callback is returned from the function, allowing this
> +  method to be used is a function decorator.
> +
> +   .. method:: pop_all()
> +
> +  Transfers the callback stack to a fresh :class:`ExitStack` instance
> +  and returns it. No callbacks are invoked by this operation - instead,
> +  they will now be invoked when the new stack is closed (either
> +  explicitly or implicitly).
> +
> +  For example, a group of files can be opened as an "all or nothing"
> +  operation 

Re: [Python-Dev] cpython (3.2): #14766: Add correct algorithm for when a 'time' object is naive.

[Georg Brandl]

Am 15.05.2012 04:33, schrieb r.david.murray:

> diff --git a/Doc/library/datetime.rst b/Doc/library/datetime.rst
> --- a/Doc/library/datetime.rst
> +++ b/Doc/library/datetime.rst
> @@ -15,16 +15,23 @@
>  formatting and manipulation. For related
>  functionality, see also the :mod:`time` and :mod:`calendar` modules.
>  
> -There are two kinds of date and time objects: "naive" and "aware". This
> -distinction refers to whether the object has any notion of time zone, 
> daylight
> -saving time, or other kind of algorithmic or political time adjustment.  
> Whether
> -a naive :class:`.datetime` object represents Coordinated Universal Time 
> (UTC),
> +There are two kinds of date and time objects: "naive" and "aware".
> +
> +An aware object has sufficient knowledge of applicable algorithmic and
> +political time adjustments, such as time zone and daylight saving time
> +information, to locate itself relative to other aware objects.  An aware 
> object
> +is used to represent a specific moment in time that is not open to
> +interpretation [#]_.

> @@ -1806,3 +1816,7 @@
> When the ``%z`` directive is provided to the :meth:`strptime` method, an
> aware :class:`.datetime` object will be produced.  The ``tzinfo`` of the
> result will be set to a :class:`timezone` instance.
> +
> +.. rubric:: Footnotes
> +
> +.. [#] If, that is, we ignore the effects of Relativity

I like that :)

Georg

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

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

[Éric Araujo]

Le 21/05/2012 07:42, Georg Brandl a écrit :
> What about:
> 
> * Canonical:
> 
> docs.python.org/2/
> docs.python.org/3/
> 
> for latest versions of 2.x and 3.x
> 
> docs.python.org/2.7/ etc.
> 
> for latest minor versions
> 
> docs.python.org/dev/
> 
> for latest dev version.
+1.

I’d be +1 to adding /stable but both 2.7 and 3.2 are stable at this time.

> * Redirected:
> 
> docs.python.org/  -->  either /2/ or /3/ or a "disambiguation page"
Either sounds good, I’m in favor of redirecting to /2 for a few years
still to preserve existing links and avoid the need to click on each page.

> docs.python.org/py3k/ -> /3/
+1, the py3k name is not obvious for everyone.

> There is also /release/X.Y.Z for individual released versions, which
> I don't want to change.
The URIs should not change, but it seems a bit bad to me that for
example the 2.7.1 docs don’t link to the latest 2.7 page and mention 2.6
as stable version

> I also like Martin's idea of offering more links between individual
> pages, not only the front-pages.
+1

On a related note, we may want to find a way to make the version more
prominent in the pages; I’ve seen beginners install Python 3 and use the
Python 2 docs and fail at the first print 'Hello, world!' example.
That’s why I support always having the version numbers in the URIs.

Cheers
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Reedy]

On 5/21/2012 11:50 AM, Georg Brandl wrote:

On 05/21/2012 02:14 PM, R. David Murray wrote:

On Mon, 21 May 2012 11:41:29 +0200, Georg Brandl  wrote:

On 05/21/2012 03:23 AM, Guido van Rossum wrote:

I suggest that we add a separate (virtual) subdomain, e.g. docs3.python.org.



Here are the time machine keys: this subdomain has existed for a few years now 
:)


The fact that none of us knew about it may say something about its
effectiveness, though.


Sure.  I was never fond of it, but there was a discussion probably similar
to this one, and it was agreed to add that subdomain.


Since there is no link to it from docs.python.org, of course it it 
difficult to find 8-). Such a link is part of the otherwise redundant 
proposal.


--
Terry Jan Reedy

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

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

[PJ Eby]

On Mon, May 21, 2012 at 9:55 AM, Guido van Rossum  wrote:

> Ah, I see. But I disagree that this is a reasonable constraint on
> sys.path. The magic __path__ object of a toplevel namespace module
> should know it is a toplevel module, and explicitly refetch sys.path
> rather than just keeping around a copy.
>

That's fine by me - the class could actually be defined to take a module
name and attribute (e.g. 'sys', 'path' or 'foo', '__path__'), and then
there'd be no need to special case anything: it would behave exactly the
same way for subpackages and top-level packages.


> This leaves the magic __path__ objects for namespace modules, which I
> could live with, as long as their repr was not the same as a list, and
> assuming a good rationale is given. Although I'd still prefer plain
> lists here as well; I'd like to be able to manually construct a
> namespace package and force its directories to be a specific set of
> directories that I happen to know about, regardless of whether they
> are related to sys.path or not. And I'd like to know that my setup in
> that case would not be disturbed by changes to sys.path.
>

To do that, you just assign to __path__, the same as now, ala __path__ =
pkgutil.extend_path().  The auto-updating is in the initially-assigned
__path__ object, not the module object or some sort of generalized magic.


 I'd like to hear more about this from Philip -- is that feature
> actually widely used?


Well, it's built into setuptools, so yes.  ;-)  It gets used any time a
dynamically specified dependency is used that might contain a namespace
package.  This means, for example, that every setup script out there using
"setup.py test", every project using certain paste.deploy features...  it's
really difficult to spell out the scope of things that are using this, in
the context of setuptools and distribute, because there are an immense
number of ways to indirectly rely on it.

This doesn't mean that the feature can't continue to be implemented inside
setuptools' dynamic dependency system, but the code to do it in setuptools
is MUCH more complicated than the PEP 420 code, and doesn't work if you
manually add something to sys.path without asking setuptools to do it.
It's also somewhat timing-sensitive, depending on when and whether you
import 'site' and pkg_resources, and whether you are mixing eggs and
non-eggs in your namespace packages.

In short, the implementation is a huge mess that the PEP 420 approach would
vastly simplify.

But...  that wasn't the original reason why I proposed it.  The original
reason was simply that it makes namespace packages act more like the
equivalents do in other languages.  While being able to override __path__
can be considered a feature of Python, its being static by default is NOT a
feature, in the same way that *requiring* an __init__.py is not really a
feature.

The principle of least surprise says (at least IMO) that if you add a
directory to sys.path, you should be able to import stuff from it.  That
whether it works depends on whether or not you already imported part of a
namespace package earlier is both surprising and confusing.  (More on this
below.)



> What would a package have to do if the feature didn't exist?


Continue to depend on setuptools to do it for them, or use some
hypothetical update API...   but that's not really the right question.  ;-)

The right question is, what happens to package *users* if the feature
didn't exist?

And the answer to that question is, "you must call this hypothetical update
API *every time* you change sys.path, because otherwise your imports might
break, depending on whether or not some other package imported something
from a namespace before you changed sys.path".

And of course, you also need to make sure that any third-party code you use
does this too, if it adds something to sys.path for you.

And if you're writing cross-Python-version code, you need to check to make
sure whether the API is actually available.

And if you're someone helping Python newbies, you need to add this to your
list of debugging questions for import-related problems.

And remember: if you forget to do this, it might not break now.  It'll
break later, when you add that other plugin or update that random module
that dynamically decides to import something that just happens to be in a
namespace package, so be prepared for it to break your application in the
field, when an end-user is using it with a collection of plugins that you
haven't tested together, or in the same import sequence...

The people using setuptools won't have these problems, but *new* Python
users will, as people begin using a PEP 420 that lacks this feature.

The key scope question, I think, is: "How often do programs change sys.path
at runtime, and what have they imported up to that point?"  (Because for
the other part of the scope, I think it's a fairly safe bet that namespace
packages are going to become even *more* popular than they are now, once
PEP 420 is in

Re: [Python-Dev] cpython: Close #14588: added a PEP 3115 compliant dynamic type creation mechanism

[Georg Brandl]

Am 19.05.2012 18:34, schrieb nick.coghlan:

> diff --git a/Doc/library/types.rst b/Doc/library/types.rst
> --- a/Doc/library/types.rst
> +++ b/Doc/library/types.rst
> @@ -1,5 +1,5 @@
> -:mod:`types` --- Names for built-in types
> -=
> +:mod:`types` --- Dynamic type creation and names for built-in types
> +===
>  
>  .. module:: types
> :synopsis: Names for built-in types.
> @@ -8,20 +8,69 @@
>  
>  --
>  
> -This module defines names for some object types that are used by the standard
> +This module defines utility function to assist in dynamic creation of
> +new types.
> +
> +It also defines names for some object types that are used by the standard
>  Python interpreter, but not exposed as builtins like :class:`int` or
> -:class:`str` are.  Also, it does not include some of the types that arise
> -transparently during processing such as the ``listiterator`` type.
> +:class:`str` are.
>  
> -Typical use is for :func:`isinstance` or :func:`issubclass` checks.
>  
> -The module defines the following names:
> +Dynamic Type Creation
> +-
> +
> +.. function:: new_class(name, bases=(), kwds=None, exec_body=None)
> +
> +   Creates a class object dynamically using the appropriate metaclass.
> +
> +   The arguments are the components that make up a class definition: the
> +   class name, the base classes (in order), the keyword arguments (such as
> +   ``metaclass``) and the callback function to populate the class namespace.
> +
> +   The *exec_body* callback should accept the class namespace as its sole
> +   argument and update the namespace directly with the class contents.
> +
> +.. function:: prepare_class(name, bases=(), kwds=None)
> +
> +   Calculates the appropriate metaclass and creates the class namespace.
> +
> +   The arguments are the components that make up a class definition: the
> +   class name, the base classes (in order) and the keyword arguments (such as
> +   ``metaclass``).
> +
> +   The return value is a 3-tuple: ``metaclass, namespace, kwds``
> +
> +   *metaclass* is the appropriate metaclass
> +   *namespace* is the prepared class namespace
> +   *kwds* is an updated copy of the passed in *kwds* argument with any
> +   ``'metaclass'`` entry removed. If no *kwds* argument is passed in, this
> +   will be an empty dict.
> +
> +
> +.. seealso::
> +
> +   :pep:`3115` - Metaclasses in Python 3000
> +  Introduced the ``__prepare__`` namespace hook
> +
> +

Should have versionadded.

Georg


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

Re: [Python-Dev] cpython (3.2): Issue12541 - Add UserWarning for unquoted realms

[Georg Brandl]

Am 15.05.2012 18:08, schrieb senthil.kumaran:

> diff --git a/Lib/urllib/request.py b/Lib/urllib/request.py
> --- a/Lib/urllib/request.py
> +++ b/Lib/urllib/request.py
> @@ -95,6 +95,7 @@
>  import sys
>  import time
>  import collections
> +import warnings
>  
>  from urllib.error import URLError, HTTPError, ContentTooShortError
>  from urllib.parse import (
> @@ -827,6 +828,9 @@
>  mo = AbstractBasicAuthHandler.rx.search(authreq)
>  if mo:
>  scheme, quote, realm = mo.groups()
> +if quote not in ["'", '"']:
> +warnings.warn("Basic Auth Realm was unquoted",
> +  UserWarning, 2)
>  if scheme.lower() == 'basic':
>  response = self.retry_http_basic_auth(host, req, realm)
>  if response and response.code != 401:


This looks suspect.  Do we issue UserWarnings/any warnings anywhere else in the
network-related libs when servers don't implement protocols correctly?
I'm afraid of spurious warnings generated that will bug users unnecessarily.

If the warning is left in, the message should probably include the offending
realm string.

Georg

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

[Python-Dev] Volunteering to be PEP czar for PEP 421, sys.implementation

[Barry Warsaw]

I've mentioned this in private to a few folks, with generally positive
feedback.

I am formally volunteering to be PEP czar for PEP 421, sys.implementation.  If
there are no objections in the next few days, I'll make it official.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

As a simple example to back up PJE's explanation, consider:
1.  encodings becomes a namespace package
2. It sometimes gets imported during interpreter startup to initialise the
standard io streams
3. An application modifies sys.path after startup and wants to contribute
additional encodings

Searching the entire parent path for new portions on every import would be
needlessly slow.

Not recognising new portions would be needlessly confusing for users. In
our simple case above, the application would fail if the io initialisation
accessed the encodings package, but work if it did not (e.g. when all
streams are utf-8).

PEP 420 splits the difference via an automatically invalidated cache: when
you iterate over a namespace package __path__ object, it rescans the parent
path for new portions *if and only if* the contents of the parent path have
changed since the previous scan.

Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)
On May 22, 2012 4:10 AM, "PJ Eby"  wrote:

> On Mon, May 21, 2012 at 9:55 AM, Guido van Rossum wrote:
>
>> Ah, I see. But I disagree that this is a reasonable constraint on
>>  sys.path. The magic __path__ object of a toplevel namespace module
>> should know it is a toplevel module, and explicitly refetch sys.path
>> rather than just keeping around a copy.
>>
>
> That's fine by me - the class could actually be defined to take a module
> name and attribute (e.g. 'sys', 'path' or 'foo', '__path__'), and then
> there'd be no need to special case anything: it would behave exactly the
> same way for subpackages and top-level packages.
>
>
>> This leaves the magic __path__ objects for namespace modules, which I
>> could live with, as long as their repr was not the same as a list, and
>> assuming a good rationale is given. Although I'd still prefer plain
>> lists here as well; I'd like to be able to manually construct a
>> namespace package and force its directories to be a specific set of
>> directories that I happen to know about, regardless of whether they
>> are related to sys.path or not. And I'd like to know that my setup in
>> that case would not be disturbed by changes to sys.path.
>>
>
> To do that, you just assign to __path__, the same as now, ala __path__ =
> pkgutil.extend_path().  The auto-updating is in the initially-assigned
> __path__ object, not the module object or some sort of generalized magic.
>
>
>  I'd like to hear more about this from Philip -- is that feature
>> actually widely used?
>
>
> Well, it's built into setuptools, so yes.  ;-)  It gets used any time a
> dynamically specified dependency is used that might contain a namespace
> package.  This means, for example, that every setup script out there using
> "setup.py test", every project using certain paste.deploy features...  it's
> really difficult to spell out the scope of things that are using this, in
> the context of setuptools and distribute, because there are an immense
> number of ways to indirectly rely on it.
>
> This doesn't mean that the feature can't continue to be implemented inside
> setuptools' dynamic dependency system, but the code to do it in setuptools
> is MUCH more complicated than the PEP 420 code, and doesn't work if you
> manually add something to sys.path without asking setuptools to do it.
> It's also somewhat timing-sensitive, depending on when and whether you
> import 'site' and pkg_resources, and whether you are mixing eggs and
> non-eggs in your namespace packages.
>
> In short, the implementation is a huge mess that the PEP 420 approach
> would vastly simplify.
>
> But...  that wasn't the original reason why I proposed it.  The original
> reason was simply that it makes namespace packages act more like the
> equivalents do in other languages.  While being able to override __path__
> can be considered a feature of Python, its being static by default is NOT a
> feature, in the same way that *requiring* an __init__.py is not really a
> feature.
>
> The principle of least surprise says (at least IMO) that if you add a
> directory to sys.path, you should be able to import stuff from it.  That
> whether it works depends on whether or not you already imported part of a
> namespace package earlier is both surprising and confusing.  (More on this
> below.)
>
>
>
>> What would a package have to do if the feature didn't exist?
>
>
> Continue to depend on setuptools to do it for them, or use some
> hypothetical update API...   but that's not really the right question.  ;-)
>
> The right question is, what happens to package *users* if the feature
> didn't exist?
>
> And the answer to that question is, "you must call this hypothetical
> update API *every time* you change sys.path, because otherwise your imports
> might break, depending on whether or not some other package imported
> something from a namespace before you changed sys.path".
>
> And of course, you also need to make sure that any third-party code you
> use does this too, if it adds something to sys.path for you.
>
> And

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

[Nick Coghlan]

I agree the parent path should be retrieved by name rather than a direct
reference when checking the cache validity, though.

--
Sent from my phone, thus the relative brevity :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

On 5/21/2012 2:08 PM, PJ Eby wrote:
> On Mon, May 21, 2012 at 9:55 AM, Guido van Rossum  > wrote:
> 
> Ah, I see. But I disagree that this is a reasonable constraint on
> sys.path. The magic __path__ object of a toplevel namespace module
> should know it is a toplevel module, and explicitly refetch sys.path
> rather than just keeping around a copy.
> 
> 
> That's fine by me - the class could actually be defined to take a module
> name and attribute (e.g. 'sys', 'path' or 'foo', '__path__'), and then
> there'd be no need to special case anything: it would behave exactly the
> same way for subpackages and top-level packages.

Any reason to make this the string "sys" or "foo", and not the module
itself? Can the module be replaced in sys.modules? Mostly I'm just curious.

But regardless, I'm okay with keeping these both as strings and looking
it up in sys.modules and then by attribute.

Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com