[Python-Dev] python docs website not accessible!

2008-10-02 Thread itconsense
Hi,

I'm not sure, if this is the right place to post. The python-docs on 
www.python.org are not accessible.

The overview http://docs.python.org/lib/lib.html works fine, but no link on the 
page i have tried works.

http://docs.python.org/lib/doctest-unittest-api.html
http://docs.python.org/lib/profile-instant.html

Is python ceasing to be open source with 2.6? ;-)

Thanks for caring,
-Tom


___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Thomas Wouters
I hotfixed docs.python.org and www.python.org/doc with some cutesy improv --
the URLs changed from .../lib/ to ../library/, and any HTML pages inside
them are completely different. So, any http://docs.python.org/lib/... URL
now redirects to the toplevel http://docs.python.org/library/ (and similar
for www.python.org/doc/lib.) If anyone feels particularly frustrated by the
old URLs breaking, I wouldn't mind adding a redirection for each individual
URL as long as I don't have to build that mapping :-)

Georg is working on fixing the main www.python.org/doc page, I believe, as
well as providing downloadable docs.

-- 
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Antoine Pitrou
Thomas Wouters  python.org> writes:
> 
> If anyone feels particularly frustrated by the old URLs breaking, I wouldn't
mind adding a redirection for each individual URL as long as I don't have to
build that mapping

Well in general URLs aren't supposed to break (except the ones which are
deliberately temporary). Could a RewriteRule do the trick?


___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Doug Hellmann


On Oct 2, 2008, at 7:28 AM, Thomas Wouters wrote:




On Thu, Oct 2, 2008 at 12:44, Antoine Pitrou <[EMAIL PROTECTED]>  
wrote:

Thomas Wouters  python.org> writes:
>
> If anyone feels particularly frustrated by the old URLs breaking,  
I wouldn't
mind adding a redirection for each individual URL as long as I don't  
have to

build that mapping

Well in general URLs aren't supposed to break (except the ones which  
are

deliberately temporary). Could a RewriteRule do the trick?

Not a single one, no. The URLs *all* changed. There is not a single  
one that's the same. We may be able to do a single rewrite rule for  
most of the module-*.html URLs, but everything else -- and there is  
quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better  
mapping. Feel free to send me that mapping :-)


Perhaps it has already been suggested and rejected for some reason,  
but we could include the major/minor version numbers in the URLs.   
That would make it easier to rewrite old URLs, and I assume there will  
be 2.x and 3.x documentation available online for some period of time?


docs.python.org/lib/* could redirect to docs.python.org/2.5/lib/*

docs.pyhton.org/ (note no *) could redirect to docs.python.org/2.6/  
and include a link to docs.python.org/3.0/


That way all of the old references (in Google and bookmarks) would  
still work.


Perhaps we should restore the old version of the files until this is  
resolved?  Being redirected to the top landing page is a little  
disconcerting if you come to the site through a search engine and  
aren't familiar with the organization of the manual.  For example, I  
went to look for the documentation on how slots work, and ended up at  
the top of the reference manual.  The local search didn't work (no  
results), "slots" isn't in the index, and google still has the old URL.


Doug

___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Antoine Pitrou

> 
> Not a single one, no. The URLs *all* changed. There is not a single
> one that's the same. We may be able to do a single rewrite rule for
> most of the module-*.html URLs, but everything else -- and there is
> quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better
> mapping. Feel free to send me that mapping :-)

My bad. I thought it was just a matter of doing a generic substitution.
Well, then we'll have to live with it I suppose :)

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] RELEASED Python 2.6 final

2008-10-02 Thread Barry Warsaw

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 2, 2008, at 12:19 AM, Haoyu Bai wrote:


Now almost all the pages on docs.python.org can't be accessed. For
example http://docs.python.org/lib/lib.html returns 403 forbidden.


Thanks to Georg and Thomas, the docs should all be fixed now.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSOS6g3EjvBPtnXfVAQKw5wP+I2L6qPZWp1qDs7qSRdlOE5xSAazhnuzE
h7gCUWah0tcewuJC38cE7kNAVkpmp9suBbGgI+FRYTeJJpoO109Io4cF4fRvYd2H
NpVfhIOo6VUchNTnsdtP4UzuaIKnkCKgWxMPPjMW9jEZlHPNdOC8stTsxOq1FWFt
hlJscML5yQA=
=wPLO
-END PGP SIGNATURE-
___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Georg Brandl
Doug Hellmann schrieb:

>> Not a single one, no. The URLs *all* changed. There is not a single
>> one that's the same. We may be able to do a single rewrite rule for
>> most of the module-*.html URLs, but everything else -- and there is
>> quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better
>> mapping. Feel free to send me that mapping :-)
> 
> Perhaps it has already been suggested and rejected for some reason, but
> we could include the major/minor version numbers in the URLs.  That
> would make it easier to rewrite old URLs, and I assume there will be 2.x
> and 3.x documentation available online for some period of time?
> 
> docs.python.org/lib/* could redirect to docs.python.org/2.5/lib/*

That would be possible, but not sensible IMO -- it doesn't make people
update their links, instead keeps links to outdated documentation.

> docs.pyhton.org/ (note no *) could redirect to docs.python.org/2.6/ and
> include a link to docs.python.org/3.0/

We already have archived versioned docs at http://www.python.org/doc/X.Y.

> That way all of the old references (in Google and bookmarks) would still
> work.
> 
> Perhaps we should restore the old version of the files until this is
> resolved?  Being redirected to the top landing page is a little
> disconcerting if you come to the site through a search engine and aren't
> familiar with the organization of the manual.  For example, I went to
> look for the documentation on how slots work, and ended up at the top of
> the reference manual.  The local search didn't work (no results),
> "slots" isn't in the index, and google still has the old URL.

__slots__ is in the index (with the underscores). The local search shows me
__slots__ as the first result when I search for "__slots__" or "slots".

As for Google, I can only assume it will soon update its index.

Nevertheless, I will come up with a mapping for the old module URLs,
which is relatively easy.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Nick Coghlan
Doug Hellmann wrote:
> Perhaps it has already been suggested and rejected for some reason, but
> we could include the major/minor version numbers in the URLs.  That
> would make it easier to rewrite old URLs, and I assume there will be 2.x
> and 3.x documentation available online for some period of time?

The old doc directories are already kept around (all the way back to 1.4
in fact: http://www.python.org/doc/1.4/)

As a quick fix for the old links, a rewrite rule to map such links to
the 2.5 docs seems like a very good idea to me. Since old URLs all use
abbreviations in the directory name (tut, lib, mac, ref, ext, api, doc,
inst, dist), it should be straightforward to redirect them without
affecting the links to the new docs (tutorial, using, reference, howto,
extending, c-api, install, distutils, documenting).


> Perhaps we should restore the old version of the files until this is
> resolved?  Being redirected to the top landing page is a little
> disconcerting if you come to the site through a search engine and aren't
> familiar with the organization of the manual.

A redirect rule to the 2.5.2 docs for the old naming scheme is probably
a better short-term solution.

>  For example, I went to
> look for the documentation on how slots work, and ended up at the top of
> the reference manual.  The local search didn't work (no results),
> "slots" isn't in the index, and google still has the old URL.

The quick search is actually working for me these days (it wasn't for a
while when the new docs were still in development). (e.g. the first hit
I get when searching for "slots" now is
http://www.python.org/doc/2.6/reference/datamodel.html?highlight=slots#__slots__)

I believe it's a Javascript based search though, so there may be issues
with browser compatibility (or user's with JS disabled).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Adam Olsen
On Thu, Oct 2, 2008 at 6:17 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Doug Hellmann schrieb:
>
>>> Not a single one, no. The URLs *all* changed. There is not a single
>>> one that's the same. We may be able to do a single rewrite rule for
>>> most of the module-*.html URLs, but everything else -- and there is
>>> quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better
>>> mapping. Feel free to send me that mapping :-)
>>
>> Perhaps it has already been suggested and rejected for some reason, but
>> we could include the major/minor version numbers in the URLs.  That
>> would make it easier to rewrite old URLs, and I assume there will be 2.x
>> and 3.x documentation available online for some period of time?
>>
>> docs.python.org/lib/* could redirect to docs.python.org/2.5/lib/*
>
> That would be possible, but not sensible IMO -- it doesn't make people
> update their links, instead keeps links to outdated documentation.
>
>> docs.pyhton.org/ (note no *) could redirect to docs.python.org/2.6/ and
>> include a link to docs.python.org/3.0/
>
> We already have archived versioned docs at http://www.python.org/doc/X.Y.

Why not use versioned URLs, but with a  link at the top of old pages
saying they're outdated, linking to the new version.  Either way they
should update their links, but this way you don't shoot them in the
foot to do it.

Breaking old links should be avoided if at all possible.


-- 
Adam Olsen, aka Rhamphoryncus
___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Thomas Wouters
On Thu, Oct 2, 2008 at 12:44, Antoine Pitrou <[EMAIL PROTECTED]> wrote:

> Thomas Wouters  python.org> writes:
> >
> > If anyone feels particularly frustrated by the old URLs breaking, I
> wouldn't
> mind adding a redirection for each individual URL as long as I don't have
> to
> build that mapping
>
> Well in general URLs aren't supposed to break (except the ones which are
> deliberately temporary). Could a RewriteRule do the trick?
>

Not a single one, no. The URLs *all* changed. There is not a single one
that's the same. We may be able to do a single rewrite rule for most of the
module-*.html URLs, but everything else -- and there is quite a lot of
'else' in the 2.5-and-earlier docs -- needs a better mapping. Feel free to
send me that mapping :-)

-- 
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Nick Coghlan
Georg Brandl wrote:
> Nevertheless, I will come up with a mapping for the old module URLs,
> which is relatively easy.

Best solution of all :)

I was actually only suggesting redirecting to the old docs until such a
mapping was available - but if that mapping will be available fairly
soon, then bumping old links up to the base URL for a day or two won't
be too bad.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Georg Brandl
Adam Olsen schrieb:
> On Thu, Oct 2, 2008 at 6:17 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Doug Hellmann schrieb:
>>
 Not a single one, no. The URLs *all* changed. There is not a single
 one that's the same. We may be able to do a single rewrite rule for
 most of the module-*.html URLs, but everything else -- and there is
 quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better
 mapping. Feel free to send me that mapping :-)
>>>
>>> Perhaps it has already been suggested and rejected for some reason, but
>>> we could include the major/minor version numbers in the URLs.  That
>>> would make it easier to rewrite old URLs, and I assume there will be 2.x
>>> and 3.x documentation available online for some period of time?
>>>
>>> docs.python.org/lib/* could redirect to docs.python.org/2.5/lib/*
>>
>> That would be possible, but not sensible IMO -- it doesn't make people
>> update their links, instead keeps links to outdated documentation.
>>
>>> docs.pyhton.org/ (note no *) could redirect to docs.python.org/2.6/ and
>>> include a link to docs.python.org/3.0/
>>
>> We already have archived versioned docs at http://www.python.org/doc/X.Y.
> 
> Why not use versioned URLs, but with a  link at the top of old pages
> saying they're outdated, linking to the new version.  Either way they
> should update their links, but this way you don't shoot them in the
> foot to do it.

If linking to the new version could be done easily, we could as well directly
redirect. The problem is that having that mapping in the first place is hard.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Doug Hellmann


On Oct 2, 2008, at 8:17 AM, Georg Brandl wrote:


Doug Hellmann schrieb:


Not a single one, no. The URLs *all* changed. There is not a single
one that's the same. We may be able to do a single rewrite rule for
most of the module-*.html URLs, but everything else -- and there is
quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better
mapping. Feel free to send me that mapping :-)


Perhaps it has already been suggested and rejected for some reason,  
but

we could include the major/minor version numbers in the URLs.  That
would make it easier to rewrite old URLs, and I assume there will  
be 2.x

and 3.x documentation available online for some period of time?

docs.python.org/lib/* could redirect to docs.python.org/2.5/lib/*


That would be possible, but not sensible IMO -- it doesn't make people
update their links, instead keeps links to outdated documentation.


The documentation isn't outdated if you're still running Python 2.5,  
as a lot of people will be.  Not everyone gets to upgrade right away  
when there's a new release.  For example, the product we build at work  
depends on 2.5 and we don't have time in our schedule to upgrade right  
away.  It may be several months before we do.


docs.pyhton.org/ (note no *) could redirect to docs.python.org/2.6/  
and

include a link to docs.python.org/3.0/


We already have archived versioned docs at http://www.python.org/doc/X.Y 
.


Great, so we can just redirect the old links over there.  If you can  
make them point to the correct form of the new docs, that would be  
even better, but at least sending them to the old docs means they  
point to *something* useful.


That way all of the old references (in Google and bookmarks) would  
still

work.

Perhaps we should restore the old version of the files until this is
resolved?  Being redirected to the top landing page is a little
disconcerting if you come to the site through a search engine and  
aren't

familiar with the organization of the manual.  For example, I went to
look for the documentation on how slots work, and ended up at the  
top of

the reference manual.  The local search didn't work (no results),
"slots" isn't in the index, and google still has the old URL.


__slots__ is in the index (with the underscores). The local search  
shows me
__slots__ as the first result when I search for "__slots__" or  
"slots".


OK, searching for "slots" at http://docs.python.org found several  
results this time.  I don't know why it would have given me no results  
the last time, but I found what I needed.


Doug

___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Doug Hellmann


On Oct 2, 2008, at 8:34 AM, Georg Brandl wrote:



If linking to the new version could be done easily, we could as well  
directly
redirect. The problem is that having that mapping in the first place  
is hard.



I was looking for the easy route.  If the layout of the new docs  
changed completely, anything that starts with the old abbreviations (/ 
lib/, /tut/, /ref/, etc.) could just go over to the 2.5.2 docs,  
right?  You don't need to map every sub-section to its new URL unless  
you feel really strongly that links to pages in the old organization  
should point to the new location.


Doug

___
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] Doc nits question

2008-10-02 Thread Jesse Noller
So, we just released and there are a few doc typo bugs being filed -
my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
can hotfix the 2.6 docs?

-jesse
___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Georg Brandl wrote:
> Adam Olsen schrieb:
>> On Thu, Oct 2, 2008 at 6:17 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>>> Doug Hellmann schrieb:
>>>
> Not a single one, no. The URLs *all* changed. There is not a single
> one that's the same. We may be able to do a single rewrite rule for
> most of the module-*.html URLs, but everything else -- and there is
> quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better
> mapping. Feel free to send me that mapping :-)
 Perhaps it has already been suggested and rejected for some reason, but
 we could include the major/minor version numbers in the URLs.  That
 would make it easier to rewrite old URLs, and I assume there will be 2.x
 and 3.x documentation available online for some period of time?

 docs.python.org/lib/* could redirect to docs.python.org/2.5/lib/*
>>> That would be possible, but not sensible IMO -- it doesn't make people
>>> update their links, instead keeps links to outdated documentation.
>>>
 docs.pyhton.org/ (note no *) could redirect to docs.python.org/2.6/ and
 include a link to docs.python.org/3.0/
>>> We already have archived versioned docs at http://www.python.org/doc/X.Y.
>> Why not use versioned URLs, but with a  link at the top of old pages
>> saying they're outdated, linking to the new version.  Either way they
>> should update their links, but this way you don't shoot them in the
>> foot to do it.
> 
> If linking to the new version could be done easily, we could as well directly
> redirect. The problem is that having that mapping in the first place is hard.

Why would you remove the old docs (ones with 2.5 in the URL)?  They
still provide value for folks who can't yet move to 2.6 / 3.0;  forcibly
redirecting a versioned URL to "current" can't possibley be sane.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI5MlR+gerLs4ltQ4RAicWAKC6gxTtxq/CwZXH9SekRs7DD1fFTwCeMyb/
eJqkvkb4zdDGZG8oPvp1GjI=
=0Atv
-END PGP SIGNATURE-

___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Georg Brandl
Tres Seaver schrieb:
> Georg Brandl wrote:

> docs.pyhton.org/ (note no *) could redirect to docs.python.org/2.6/ and
> include a link to docs.python.org/3.0/
 We already have archived versioned docs at http://www.python.org/doc/X.Y.
>>> Why not use versioned URLs, but with a  link at the top of old pages
>>> saying they're outdated, linking to the new version.  Either way they
>>> should update their links, but this way you don't shoot them in the
>>> foot to do it.
> 
>> If linking to the new version could be done easily, we could as well directly
>> redirect. The problem is that having that mapping in the first place is hard.
> 
> Why would you remove the old docs (ones with 2.5 in the URL)?  They
> still provide value for folks who can't yet move to 2.6 / 3.0;  forcibly
> redirecting a versioned URL to "current" can't possibley be sane.

That's true; it's also not what I meant. The versioned docs will of course
always stay there. The question is what to do for URLs that refer to
docs.python.org, but with old filenames.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Doc nits question

2008-10-02 Thread Georg Brandl
Jesse Noller schrieb:
> So, we just released and there are a few doc typo bugs being filed -
> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
> can hotfix the 2.6 docs?

I intend to set things up so that the docs at docs.python.org are continually
rebuilt, just like the /dev docs were until now.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Doc nits question

2008-10-02 Thread Jesse Noller
On Thu, Oct 2, 2008 at 9:21 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Jesse Noller schrieb:
>> So, we just released and there are a few doc typo bugs being filed -
>> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
>> can hotfix the 2.6 docs?
>
> I intend to set things up so that the docs at docs.python.org are continually
> rebuilt, just like the /dev docs were until now.
>
> Georg

Fantastic, so the doc updates should go to the 2.6 branch, correct?
(Not that I'm suggesting checking in all willy nilly)
___
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] Doc nits question

2008-10-02 Thread Nick Coghlan
Jesse Noller wrote:
> So, we just released and there are a few doc typo bugs being filed -
> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
> can hotfix the 2.6 docs?

Well the fixes can definitely all go in to SVN on both the trunk and the
maintenance branch.

As to when we update docs.python.org from the maintenance branch... I
believe historically it has only been done at each new maintenance
release, but I don't see any fundamental problems with the idea of
updating it more frequently.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] Doc nits question

2008-10-02 Thread Georg Brandl
Jesse Noller schrieb:
> On Thu, Oct 2, 2008 at 9:21 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Jesse Noller schrieb:
>>> So, we just released and there are a few doc typo bugs being filed -
>>> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
>>> can hotfix the 2.6 docs?
>>
>> I intend to set things up so that the docs at docs.python.org are continually
>> rebuilt, just like the /dev docs were until now.
>>
>> Georg
> 
> Fantastic, so the doc updates should go to the 2.6 branch, correct?
> (Not that I'm suggesting checking in all willy nilly)

This is another thing that needs to be discussed: how to handle backports
between 2.6 and 2.7. Up to now, we backported changes from trunk to maint
manually, but after the experience we've had with svnmerge, I see several
possibilities:

1. Do bugfixes in maint, merge them to trunk via svnmerge. This has the
   drawback that you have to work in two different repos for fixes vs.
   new features. The advantage however is that normally all fixes that
   go into maint apply to trunk as well, so almost no blocks need to be done.
   However, since Py3k merges are done from trunk, the 3k merge will see
   merges as single commits, so they aren't easy to block if not applicable.
   This will mean more conflicts.

2. Do bugfixes in trunk, and merge them to maint via svnmerge.
   Arguments as for 1, but reversed: many blocks, but less problems with 3k.

3. Backport bugfixes manually, like for the previous maintenance branches.

cheers,
Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Nick Coghlan
Georg Brandl wrote:
> That's true; it's also not what I meant. The versioned docs will of course
> always stay there. The question is what to do for URLs that refer to
> docs.python.org, but with old filenames.

I still like the idea of redirecting such URLs to the old 2.5.2 docs as
a short-term fix, with a more complex remapping to the appropriate 2.6
files when it is available.

(Whether or not the first part is worth doing obviously depends on how
much time you expect the second part to take).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread skip
>> Not a single one, no. The URLs *all* changed. There is not a single
>> one that's the same. We may be able to do a single rewrite rule for
>> most of the module-*.html URLs, but everything else -- and there is
>> quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better
>> mapping. Feel free to send me that mapping :-)

Antoine> My bad. I thought it was just a matter of doing a generic
Antoine> substitution.  Well, then we'll have to live with it I suppose
Antoine> :)

Unfortunately, without some mapping the search engines will toss everything
out.  While they will eventually get around to fetching
http://docs.python.org/ and traversing the tree of pages, but that might
take awhile.  I won't have time for the next day or two to scan the docs
error log, but if I can come up with a list of the ten most frequent
failures I suspect we can easily define RewriteRule directives for them.

Skip
___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Thomas Wouters
On Thu, Oct 2, 2008 at 15:47, <[EMAIL PROTECTED]> wrote:

>>> Not a single one, no. The URLs *all* changed. There is not a single
>>> one that's the same. We may be able to do a single rewrite rule for
>>> most of the module-*.html URLs, but everything else -- and there is
>>> quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better
>>> mapping. Feel free to send me that mapping :-)
>
> Antoine> My bad. I thought it was just a matter of doing a generic
>Antoine> substitution.  Well, then we'll have to live with it I suppose
>Antoine> :)
>
> Unfortunately, without some mapping the search engines will toss everything
> out.  While they will eventually get around to fetching
> http://docs.python.org/ and traversing the tree of pages, but that might
> take awhile.  I won't have time for the next day or two to scan the docs
> error log, but if I can come up with a list of the ten most frequent
> failures I suspect we can easily define RewriteRule directives for them.


To be sure, the URLs *are* mapped. They're just mapped to something other
than they were mapped to before -- because those pages no longer exist for
the 'current version' of the documentation. Pages covering the same or
nearly the same thing may exist in some cases, but not in others. We can do
a best-effort to redirect the old URLs to something covering the same
information, or we can wait a few days to let search engines realize the
URLs changed, and let everyone else deal with searching a little further for
the information they had bookmarked.

-- 
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread skip

Nick> The old doc directories are already kept around (all the way back
Nick> to 1.4 in fact: http://www.python.org/doc/1.4/)

Nick> As a quick fix for the old links, a rewrite rule to map such links
Nick> to the 2.5 docs seems like a very good idea to me. Since old URLs
Nick> all use abbreviations in the directory name (tut, lib, mac, ref,
Nick> ext, api, doc, inst, dist), it should be straightforward to
Nick> redirect them without affecting the links to the new docs
Nick> (tutorial, using, reference, howto, extending, c-api, install,
Nick> distutils, documenting).

Yes, we should probably still get the top-level links redirected to the new
docs though.  The 2.5 tutorial is probably going to get stale over time
while the 2.6 version will be updated at least until 2.7 is released.

Skip
___
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] Doc nits question

2008-10-02 Thread Fred Drake

On Oct 2, 2008, at 9:21 AM, Georg Brandl wrote:
I intend to set things up so that the docs at docs.python.org are  
continually

rebuilt, just like the /dev docs were until now.


Wonderful!  This should help avoid repeat reports of simple typos.

At one point, we started to separate the documentation releases so  
that update releases could be easily pushed at times when there wasn't  
a corresponding Python release.  There are a couple of examples of  
these in the specific-versions list, IIRC.  These have version numbers  
ending with "p1" (for patch 1; no more than one patched version was  
ever released for any particular Python version).


It may be worth trying this or something like it again as well, if  
there's enough volunteer time available.  Such versions would need to  
be clearly marked on every page as to when they were updated, so that  
readers can tell if they have the latest update.



  -Fred

--
Fred L. Drake, Jr.  

___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Thomas Wouters
On Thu, Oct 2, 2008 at 15:51, <[EMAIL PROTECTED]> wrote:

>
>Nick> The old doc directories are already kept around (all the way back
>Nick> to 1.4 in fact: http://www.python.org/doc/1.4/)
>
>Nick> As a quick fix for the old links, a rewrite rule to map such links
>Nick> to the 2.5 docs seems like a very good idea to me. Since old URLs
>Nick> all use abbreviations in the directory name (tut, lib, mac, ref,
>Nick> ext, api, doc, inst, dist), it should be straightforward to
>Nick> redirect them without affecting the links to the new docs
>Nick> (tutorial, using, reference, howto, extending, c-api, install,
>Nick> distutils, documenting).
>
> Yes, we should probably still get the top-level links redirected to the new
> docs though.  The 2.5 tutorial is probably going to get stale over time
> while the 2.6 version will be updated at least until 2.7 is released.
>

After discussing on #python-dev (briefly), I made the toplevel directories
refer to the new, 2.6 toplevel directories, but deeper URLs in the old
directories redirect to www.python.org/doc/2.5.2/. I still think this is the
wrong approach, especially in the long term: it means people who just follow
old documentation links will not see the new results, and search engines
will not realize the pages are effectively stale.

-- 
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
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 docs website not accessible!

2008-10-02 Thread Aahz
On Thu, Oct 02, 2008, [EMAIL PROTECTED] wrote:
> 
>I'm not sure, if this is the right place to post. The python-docs on
>www.python.org are not accessible.

This is definitely the wrong place to post.  As usual for most sites,
[EMAIL PROTECTED] is the right place.  But please don't bother, we've
already had about twenty other people reporting.  ;-)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"...if I were on life-support, I'd rather have it run by a Gameboy than a
Windows box."  --Cliff Wells, comp.lang.python, 3/13/2002
___
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] Doc nits question

2008-10-02 Thread Georg Brandl
Fred Drake schrieb:
> On Oct 2, 2008, at 9:21 AM, Georg Brandl wrote:
>> I intend to set things up so that the docs at docs.python.org are  
>> continually
>> rebuilt, just like the /dev docs were until now.
> 
> Wonderful!  This should help avoid repeat reports of simple typos.
> 
> At one point, we started to separate the documentation releases so  
> that update releases could be easily pushed at times when there wasn't  
> a corresponding Python release.  There are a couple of examples of  
> these in the specific-versions list, IIRC.  These have version numbers  
> ending with "p1" (for patch 1; no more than one patched version was  
> ever released for any particular Python version).
> 
> It may be worth trying this or something like it again as well, if  
> there's enough volunteer time available.  Such versions would need to  
> be clearly marked on every page as to when they were updated, so that  
> readers can tell if they have the latest update.

All Sphinx-generated pages currently have a "last update on:" in the footer.
Do you think that suffices for this purpose?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] Doc nits question

2008-10-02 Thread Fred Drake

On Oct 2, 2008, at 1:17 PM, Georg Brandl wrote:
All Sphinx-generated pages currently have a "last update on:" in the  
footer.

Do you think that suffices for this purpose?


Yes, I do.


  -Fred

--
Fred L. Drake, Jr.  

___
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] Real segmentation fault handler

2008-10-02 Thread Thomas Heller
Victor Stinner schrieb:
> Hi,
> 
> I would like to be able to catch SIGSEGV in my Python code! So I started to 
> hack Python trunk to support this feature. The idea is to use a signal 
> handler which call longjmp(), and add setjmp() at Py_EvalFrameEx() enter.

On windows, ctypes catches fatal errors (exception violations) in 
foreign function calls, thanks to windows structured exception handling.

On other platforms, there is the WAD module by David Beazley which
may do something similar:

http://www.dabeaz.com/papers/Python2001/python.html

I do not know whether the code itself is still available or not.

-- 
Thanks,
Thomas

___
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] c99 comments in the 2.6 code base?

2008-10-02 Thread Fredrik Lundh

http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/

mentions that Objects/frameobject.c contains a C99-style comment, which 
means that Python 2.6 won't build on AIX.


shouldn't we use a suitable gcc option for the buildbots to prevent that 
from happening?




___
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] c99 comments in the 2.6 code base?

2008-10-02 Thread Christian Heimes

Fredrik Lundh wrote:

http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/

mentions that Objects/frameobject.c contains a C99-style comment, which 
means that Python 2.6 won't build on AIX.


shouldn't we use a suitable gcc option for the buildbots to prevent that 
from happening?


Ouch! This shouldn't have happend. I'm going to discuss the matter on 
#python-dev. Perhaps --with-pydebug could add more restrict error 
checking to the Makefile like -std=c89 -pedantic -Werror


Christian

___
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] c99 comments in the 2.6 code base?

2008-10-02 Thread Antoine Pitrou
Christian Heimes  cheimes.de> writes:
> 
> Ouch! This shouldn't have happend. I'm going to discuss the matter on 
> #python-dev. Perhaps --with-pydebug could add more restrict error 
> checking to the Makefile like -std=c89 -pedantic -Werror

As discussed on python-dev, I think it should also be added in release mode.
Some developers probably never compile in debug mode (*), and compiling in
release mode is useful when you want to do performance tuning.

(*) not thinking of anyone in particular !

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


[Python-Dev] Bugfix porting policy (was Re: Doc nits question)

2008-10-02 Thread Georg Brandl
Just now, Christian decided for option 2...

Georg

> This is another thing that needs to be discussed: how to handle backports
> between 2.6 and 2.7. Up to now, we backported changes from trunk to maint
> manually, but after the experience we've had with svnmerge, I see several
> possibilities:
> 
> 1. Do bugfixes in maint, merge them to trunk via svnmerge. This has the
>drawback that you have to work in two different repos for fixes vs.
>new features. The advantage however is that normally all fixes that
>go into maint apply to trunk as well, so almost no blocks need to be done.
>However, since Py3k merges are done from trunk, the 3k merge will see
>merges as single commits, so they aren't easy to block if not applicable.
>This will mean more conflicts.
> 
> 2. Do bugfixes in trunk, and merge them to maint via svnmerge.
>Arguments as for 1, but reversed: many blocks, but less problems with 3k.
> 
> 3. Backport bugfixes manually, like for the previous maintenance branches.


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] RELEASED Python 2.6 final

2008-10-02 Thread Barry Warsaw

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 1, 2008, at 11:46 PM, Barry Warsaw wrote:

On behalf of the Python development team and the Python community, I  
am happy to announce the release of Python 2.6 final.  This is the  
production-ready version of the latest in the Python 2 series.


Source tarballs, Windows installers, and Mac disk images can be  
downloaded from the Python 2.6 page:


   http://www.python.org/download/releases/2.6/


Due to a minor snafu in our build scripts, the source tgz and tar.bz2  
files contained some extra cruft.  I have created and uploaded new  
tarballs but I have /not/ bumped the Python version number since they  
were made from exactly the same Subversion tag.  The new tarballs are  
identical to the originals except that they don't contain the cruft  
(.svn files and such).


If you have already downloaded the tarballs, you do not need to  
download the new ones. The new tarballs are about 2MB smaller though.


With apologies,
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCUAwUBSOUgjnEjvBPtnXfVAQJ3gQP4mxxW9kaaMlsg7yd1uNcgYa29pitYdF2+
DhFgrCajPZpskc3XlKbPcnPJWT8wtI/EIC5QcPEpAWCHECrTUHzPyGLNeMQz0kFF
/ZGCGbef7Mc/JaZvEyF6OATnKhYA5XyUOPdddygx6oar/Y6ZbK2JyLR4pvzh+gtQ
SA+u6OPIpQ==
=7uu8
-END PGP SIGNATURE-
___
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] c99 comments in the 2.6 code base?

2008-10-02 Thread Christian Heimes

Fredrik Lundh wrote:

http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/


I've found several more occasions of // comments and one usage of 
inline. We *really* should have some way to compile Python with C89 checks


Python doesn't compile with the -pedantic option but it compiles with 
-std=c89 -Werror after I've applied some patches. I've added a new make 
command to add extra checks. Maybe the build bots could use "make c89" 
instead of "make" to build Python?


c89:
$(MAKE) CFLAGS="$(CFLAGS) -std=c89 -Werror"


Christian

___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Martin v. Löwis
> Why not use versioned URLs, but with a  link at the top of old pages
> saying they're outdated, linking to the new version.  Either way they
> should update their links, but this way you don't shoot them in the
> foot to do it.

Wouldn't that require changes to the old pages?

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] Bugfix porting policy (was Re: Doc nits question)

2008-10-02 Thread Martin v. Löwis
>> 2. Do bugfixes in trunk, and merge them to maint via svnmerge.
>>Arguments as for 1, but reversed: many blocks, but less problems with 3k.

I'm not so sure that we need to block all the changes that we don't
want, though: it would be sufficient to just not merge them, right?

(of course, somebody could go over it from time to time and block
everything older than a month that was still available, just to prevent
accidental merging)

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] c99 comments in the 2.6 code base?

2008-10-02 Thread Martin v. Löwis
> shouldn't we use a suitable gcc option for the buildbots to prevent that
> from happening?

Which one specifically?

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] Bugfix porting policy (was Re: Doc nits question)

2008-10-02 Thread Benjamin Peterson
On Thu, Oct 2, 2008 at 3:18 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> 2. Do bugfixes in trunk, and merge them to maint via svnmerge.
>>>Arguments as for 1, but reversed: many blocks, but less problems with 3k.
>
> I'm not so sure that we need to block all the changes that we don't
> want, though: it would be sufficient to just not merge them, right?

A large merge queue would accumulate making hard for someone to pick
out the bugfixes. Of course, people could just merge fixes right after
they apply it to the trunk, though.

>
> (of course, somebody could go over it from time to time and block
> everything older than a month that was still available, just to prevent
> accidental merging)
>
> 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/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
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] Bugfix porting policy (was Re: Doc nits question)

2008-10-02 Thread Martin v. Löwis
> A large merge queue would accumulate making hard for someone to pick
> out the bugfixes. Of course, people could just merge fixes right after
> they apply it to the trunk, though.

I think they should. To my knowledge, nobody goes through the changelog
anymore trying to find out what needs backporting. Tracking what still
needs merging should happen in the bug tracker, by leaving the report
open until merging has been done. Every change that isn't immediately
merged and doesn't have an open issue just won't get merged at all.

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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Adam Olsen
On Thu, Oct 2, 2008 at 2:13 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Why not use versioned URLs, but with a  link at the top of old pages
>> saying they're outdated, linking to the new version.  Either way they
>> should update their links, but this way you don't shoot them in the
>> foot to do it.
>
> Wouldn't that require changes to the old pages?

Hopefully just to whatever common templating they're using.  I'm not
familiar with how they're generated though.


-- 
Adam Olsen, aka Rhamphoryncus
___
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] Bugfix porting policy (was Re: Doc nits question)

2008-10-02 Thread Georg Brandl
Martin v. Löwis schrieb:
>> A large merge queue would accumulate making hard for someone to pick
>> out the bugfixes. Of course, people could just merge fixes right after
>> they apply it to the trunk, though.
> 
> I think they should. To my knowledge, nobody goes through the changelog
> anymore trying to find out what needs backporting. Tracking what still
> needs merging should happen in the bug tracker, by leaving the report
> open until merging has been done. Every change that isn't immediately
> merged and doesn't have an open issue just won't get merged at all.

This is why it's good to track what was merged and what not via svnmerge,
because it cannot miss commits. It also is easy for someone to select
which stuff to merge if the commit message on the trunk indicates
backportable fixes.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Martin v. Löwis
>> Wouldn't that require changes to the old pages?
> 
> Hopefully just to whatever common templating they're using.  I'm not
> familiar with how they're generated though.

That's exactly the problem: they are generated. I don't think it's
feasible to regenerate them, and still expect the output to be the
same. Also, I don't think the generator supports templating in the
way you might expect it to. To be specific, it's latex2html.

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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Georg Brandl
Thomas Wouters schrieb:

> After discussing on #python-dev (briefly), I made the toplevel
> directories refer to the new, 2.6 toplevel directories, but deeper URLs
> in the old directories redirect to www.python.org/doc/2.5.2/
> . I still think this is the wrong
> approach, especially in the long term: it means people who just follow
> old documentation links will not see the new results, and search engines
> will not realize the pages are effectively stale.

I'll work on a more thorough redirection in about two weeks' time.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] www.python.org/doc and docs.python.org hotfixed

2008-10-02 Thread Nick Coghlan
Thomas Wouters wrote:
> 
> 
> On Thu, Oct 2, 2008 at 15:51, <[EMAIL PROTECTED] >
> wrote:
> 
> 
>Nick> The old doc directories are already kept around (all the
> way back
>Nick> to 1.4 in fact: http://www.python.org/doc/1.4/)
> 
>Nick> As a quick fix for the old links, a rewrite rule to map
> such links
>Nick> to the 2.5 docs seems like a very good idea to me. Since
> old URLs
>Nick> all use abbreviations in the directory name (tut, lib, mac,
> ref,
>Nick> ext, api, doc, inst, dist), it should be straightforward to
>Nick> redirect them without affecting the links to the new docs
>Nick> (tutorial, using, reference, howto, extending, c-api, install,
>Nick> distutils, documenting).
> 
> Yes, we should probably still get the top-level links redirected to
> the new
> docs though.  The 2.5 tutorial is probably going to get stale over time
> while the 2.6 version will be updated at least until 2.7 is released.
> 
> 
> After discussing on #python-dev (briefly), I made the toplevel
> directories refer to the new, 2.6 toplevel directories, but deeper URLs
> in the old directories redirect to www.python.org/doc/2.5.2/
> . I still think this is the wrong
> approach, especially in the long term: it means people who just follow
> old documentation links will not see the new results, and search engines
> will not realize the pages are effectively stale.

Agreed, but I think it's a better near-term solution than dumping deep
links back at the top of the relevant document (it always annoys me when
web sites do that).

Long term, remapping even the deep links to the appropriate part of the
new docs should hopefully be possible.

For the search engine issue, is there any way we can tell robots to
ignore the rewrite rules so they see the broken links? (although even
that may not be ideal, since what we really want is to tell the robot
the link is broken, and provide the new alternative)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] 2to3 bug fixes

2008-10-02 Thread Benjamin Peterson
What should the policy on 2to3 bug fixes be for the maintenance
branch? I'm asking because I remember vaguely someone suggesting that
new 2to3 fixers could fit into that category.

So, should I only merge "pure" bug fixes, or do I get to stretch the
definition a little?

-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
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] 2to3 bug fixes

2008-10-02 Thread Guido van Rossum
On Thu, Oct 2, 2008 at 3:13 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> What should the policy on 2to3 bug fixes be for the maintenance
> branch? I'm asking because I remember vaguely someone suggesting that
> new 2to3 fixers could fit into that category.
>
> So, should I only merge "pure" bug fixes, or do I get to stretch the
> definition a little?

We agreed that new fixers (and possibly other changes) to 2to3 are
fair game for bugfix releases.

-- 
--Guido van Rossum (home page: http://www.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] 2to3 bug fixes

2008-10-02 Thread Victor Stinner
Le Friday 03 October 2008 00:13:16 Benjamin Peterson, vous avez écrit :
> What should the policy on 2to3 bug fixes be for the maintenance
> branch? I'm asking because I remember vaguely someone suggesting that
> new 2to3 fixers could fit into that category.

Python3 removes os.getcwdu() and introduces os.getcwdb(). A fixer should 
replace "os.getcwdu()" to "os.getcwd()". See for example attached fixer 
(which also replaced "getcwdu()" to "getcwd()").

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/


fix_getcwdu.py
Description: application/python
___
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] 2to3 bug fixes

2008-10-02 Thread Benjamin Peterson
On Thu, Oct 2, 2008 at 5:36 PM, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Le Friday 03 October 2008 00:13:16 Benjamin Peterson, vous avez écrit :
>> What should the policy on 2to3 bug fixes be for the maintenance
>> branch? I'm asking because I remember vaguely someone suggesting that
>> new 2to3 fixers could fit into that category.
>
> Python3 removes os.getcwdu() and introduces os.getcwdb(). A fixer should
> replace "os.getcwdu()" to "os.getcwd()". See for example attached fixer
> (which also replaced "getcwdu()" to "getcwd()").

Once again, please post it to the tracker and assign it to me.



-- 
Cheers,
Benjamin Peterson
"There's nothing quite as beautiful as an oboe... except a chicken
stuck in a vacuum cleaner."
___
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] c99 comments in the 2.6 code base?

2008-10-02 Thread Christian Heimes

Martin v. Löwis wrote:

shouldn't we use a suitable gcc option for the buildbots to prevent that
from happening?


Which one specifically?


I suggest we add "-std=c89" to CFLAGS. We could also add a new target 
called buildbot to the Makefile that appends "-std=c89 -Werror" to 
CFLAGS. I don't think it's wise to add "-Werror" to the standard build 
target. However a new build target with extra checks should help to 
detect errors much sooner.


Christian
___
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] c99 comments in the 2.6 code base?

2008-10-02 Thread Martin v. Löwis
>>> shouldn't we use a suitable gcc option for the buildbots to prevent that
>>> from happening?
>>
>> Which one specifically?
> 
> I suggest we add "-std=c89" to CFLAGS.

That needs thorough testing, in particular across many old Linux
distributions. It might be that some sets of Linux header files
rely on GNU C extensions, without using the __extension__ keyword.

> We could also add a new target
> called buildbot to the Makefile that appends "-std=c89 -Werror" to
> CFLAGS. I don't think it's wise to add "-Werror" to the standard build
> target. However a new build target with extra checks should help to
> detect errors much sooner.

That would need to go along with a policy that Python must never cause
GCC to emit any warnings.

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] c99 comments in the 2.6 code base?

2008-10-02 Thread skip

 shouldn't we use a suitable gcc option for the buildbots to prevent
 that from happening?
>>> 
>>> Which one specifically?
>> 
>> I suggest we add "-std=c89" to CFLAGS.

Martin> That needs thorough testing, in particular across many old Linux
Martin> distributions. It might be that some sets of Linux header files
Martin> rely on GNU C extensions, without using the __extension__
Martin> keyword.

Surely we don't need to be that careful with the buildbots do we?  If
anything, I think it would be a good idea to be more strict for them than
the default.

Skip
___
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] Doc nits question

2008-10-02 Thread Terry Reedy

Georg Brandl wrote:

Fred Drake schrieb:

On Oct 2, 2008, at 9:21 AM, Georg Brandl wrote:
I intend to set things up so that the docs at docs.python.org are  
continually

rebuilt, just like the /dev docs were until now.


Will you do the same for the 3.0 version?
http://docs.python.org/dev/3.0/

The following page has no reference to the 3.0 version
http://www.python.org/doc/versions/
The 'unreleased' link at the top goes to a link that only referenced the 
SVN version and not the built version above.  Adding a link to the build 
version would have made it easier to find ;-).



All Sphinx-generated pages currently have a "last update on:" in the footer.
Do you think that suffices for this purpose?


It certainly would limit a search for closed issues not incorporated in 
the update (to avoiding duplication).


___
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] Doc nits question

2008-10-02 Thread Neal Norwitz
On Thu, Oct 2, 2008 at 6:21 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Jesse Noller schrieb:
>> So, we just released and there are a few doc typo bugs being filed -
>> my question is if all doc-fixes have to wait for 2.6.1/2.7 or if we
>> can hotfix the 2.6 docs?
>
> I intend to set things up so that the docs at docs.python.org are continually
> rebuilt, just like the /dev docs were until now.

The 2.6 docs are now updated similar to how 2.5 was (hourly).  2.5
docs are no longer updated. In case you can't guess the url, it's:

http://docs.python.org/dev/2.6/

3.0 should continue to work.  Let me know if you have any problems.

n

>
> Georg
>
> --
> Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
> Four shall be the number of spaces thou shalt indent, and the number of thy
> indenting shall be four. Eight shalt thou not indent, nor either indent thou
> two, excepting that thou then proceed to four. Tabs are right out.
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/nnorwitz%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