[Python-Dev] Two urllib issues

2010-12-15 Thread Senthil Kumaran
I know it is late to add features in beta release, but still I thought I
would ask for a little leeway for these issues, especially as they don't
change any API signatures.

http://bugs.python.org/issue3243
Has patch, tests and docs

http://bugs.python.org/issue1508475

I have patch ready and shall add the tests and docs too.

Nothing is dependent on those changes, just that that it would be good to
have.

Any suggestions on the above? Georg, is it okay if I push this in before
17th?

-- 
Senthil
___
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] r87253 - tracker/instances/python-dev/detectors/autonosy.py

2010-12-15 Thread Antoine Pitrou
On Wed, 15 Dec 2010 01:53:37 +0100 (CET)
ezio.melotti  wrote:

> Author: ezio.melotti
> Date: Wed Dec 15 01:53:37 2010
> New Revision: 87253
> 
> Log:
> #363: add automatically release managers to the nosy list for release 
> blockers. Initial patch by Georg Brandl.


You should probably add deferred blockers too.

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] Remove HTTP 0.9 support

2010-12-15 Thread Antoine Pitrou

Hello,

I would like to remove HTTP 0.9 support from http.client and
http.server. I've opened an issue at http://bugs.python.org/issue10711
for that. Would anyone think it's a bad idea?

(HTTP 1.0 was devised in 1996)

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] Remove HTTP 0.9 support

2010-12-15 Thread Fred Drake
On Wed, Dec 15, 2010 at 1:39 PM, Antoine Pitrou  wrote:
> I would like to remove HTTP 0.9 support from http.client and
> http.server.

+1


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
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] Remove HTTP 0.9 support

2010-12-15 Thread Glenn Linderman

On 12/15/2010 10:39 AM, Antoine Pitrou wrote:

Hello,

I would like to remove HTTP 0.9 support from http.client and
http.server. I've opened an issue at http://bugs.python.org/issue10711
for that. Would anyone think it's a bad idea?

(HTTP 1.0 was devised in 1996)


Please address the following comment from the server.py source:

# The default request version.  This only affects responses up until
# the point where the request line is parsed, so it mainly decides what
# the client gets back when sending a malformed request line.
# Most web servers default to HTTP 0.9, i.e. don't send a status line.
default_request_version = "HTTP/0.9"

I realize this is a somewhat obscure point, and in general, if your 
interest in http.client and http.server implies that some of the many 
outstanding bug reports for that code will get resolved, I have no 
concern for dropping support for HTTP 0.9 protocol, other than the above.


Glenn
___
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] Remove HTTP 0.9 support

2010-12-15 Thread Antoine Pitrou
On Wed, 15 Dec 2010 12:58:51 -0800
Glenn Linderman  wrote:
> On 12/15/2010 10:39 AM, Antoine Pitrou wrote:
> > Hello,
> >
> > I would like to remove HTTP 0.9 support from http.client and
> > http.server. I've opened an issue at http://bugs.python.org/issue10711
> > for that. Would anyone think it's a bad idea?
> >
> > (HTTP 1.0 was devised in 1996)
> 
> Please address the following comment from the server.py source:
> 
>  # The default request version.  This only affects responses up until
>  # the point where the request line is parsed, so it mainly decides what
>  # the client gets back when sending a malformed request line.
>  # Most web servers default to HTTP 0.9, i.e. don't send a status line.
>  default_request_version = "HTTP/0.9"

What do you mean by "address"? The patch changes this to 1.0.
And, as the comment says, this only affects what happens when the
client sends a syntactically invalid request line, so whether the server
does a 0.9-style or 1.0-style response is unimportant.

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] Remove HTTP 0.9 support

2010-12-15 Thread Glenn Linderman

On 12/15/2010 1:25 PM, Antoine Pitrou wrote:

On Wed, 15 Dec 2010 12:58:51 -0800
Glenn Linderman  wrote:

On 12/15/2010 10:39 AM, Antoine Pitrou wrote:

Hello,

I would like to remove HTTP 0.9 support from http.client and
http.server. I've opened an issue at http://bugs.python.org/issue10711
for that. Would anyone think it's a bad idea?

(HTTP 1.0 was devised in 1996)

Please address the following comment from the server.py source:

  # The default request version.  This only affects responses up until
  # the point where the request line is parsed, so it mainly decides what
  # the client gets back when sending a malformed request line.
  # Most web servers default to HTTP 0.9, i.e. don't send a status line.
  default_request_version = "HTTP/0.9"

What do you mean by "address"? The patch changes this to 1.0.
And, as the comment says, this only affects what happens when the
client sends a syntactically invalid request line, so whether the server
does a 0.9-style or 1.0-style response is unimportant.


Just what you did... justify the unimportance of not changing it :)  
Since now it is different than "most web servers".
___
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] Remove HTTP 0.9 support

2010-12-15 Thread Antoine Pitrou
On Wed, 15 Dec 2010 14:20:54 -0800
Glenn Linderman  wrote:

> On 12/15/2010 1:25 PM, Antoine Pitrou wrote:
> > On Wed, 15 Dec 2010 12:58:51 -0800
> > Glenn Linderman  wrote:
> >> On 12/15/2010 10:39 AM, Antoine Pitrou wrote:
> >>> Hello,
> >>>
> >>> I would like to remove HTTP 0.9 support from http.client and
> >>> http.server. I've opened an issue at http://bugs.python.org/issue10711
> >>> for that. Would anyone think it's a bad idea?
> >>>
> >>> (HTTP 1.0 was devised in 1996)
> >> Please address the following comment from the server.py source:
> >>
> >>   # The default request version.  This only affects responses up until
> >>   # the point where the request line is parsed, so it mainly decides 
> >> what
> >>   # the client gets back when sending a malformed request line.
> >>   # Most web servers default to HTTP 0.9, i.e. don't send a status 
> >> line.
> >>   default_request_version = "HTTP/0.9"
> > What do you mean by "address"? The patch changes this to 1.0.
> > And, as the comment says, this only affects what happens when the
> > client sends a syntactically invalid request line, so whether the server
> > does a 0.9-style or 1.0-style response is unimportant.
> 
> Just what you did... justify the unimportance of not changing it :)  
> Since now it is different than "most web servers".

Well, I think the "most web servers" comment itself is outdated.
Try e.g. www.mozilla.org or www.google.com or www.msn.com.
(but www.python.org or www.apache.org still have the legacy behaviour)

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] [Python-checkins] r87296 - python/branches/py3k/Doc/library/test.rst

2010-12-15 Thread Michael Foord
On 16 December 2010 00:23, eric.araujo  wrote:

> Author: eric.araujo
> Date: Thu Dec 16 01:23:30 2010
> New Revision: 87296
>
> Log:
> Advertise “python -m” instead of direct filename.
>
>
> Modified:
>   python/branches/py3k/Doc/library/test.rst
>
> Modified: python/branches/py3k/Doc/library/test.rst
>
> ==
> --- python/branches/py3k/Doc/library/test.rst   (original)
> +++ python/branches/py3k/Doc/library/test.rst   Thu Dec 16 01:23:30 2010
> @@ -168,14 +168,14 @@
>
>  Running :mod:`test.regrtest` directly allows what resources are available
> for
>  tests to use to be set. You do this by using the ``-u`` command-line
> -option. Run :program:`python regrtest.py -uall` to turn on all
> +option. Run :program:`python -m regrtest -uall` to turn on all
>

Shouldn't this be `python -m test.regrtest`, or even just `python -m test`?

Michael


>  resources; specifying ``all`` as an option for ``-u`` enables all
>  possible resources. If all but one resource is desired (a more common
> case), a
>  comma-separated list of resources that are not desired may be listed after
> -``all``. The command :program:`python regrtest.py -uall,-audio,-largefile`
> +``all``. The command :program:`python -m regrtest -uall,-audio,-largefile`
>  will run :mod:`test.regrtest` with all resources except the ``audio`` and
>  ``largefile`` resources. For a list of all resources and more command-line
> -options, run :program:`python regrtest.py -h`.
> +options, run :program:`python -m regrtest -h`.
>
>  Some other ways to execute the regression tests depend on what platform
> the
>  tests are being executed on. On Unix, you can run :program:`make test` at
> the
> ___
> Python-checkins mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-checkins
>



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


Re: [Python-Dev] [Python-checkins] r87296 - python/branches/py3k/Doc/library/test.rst

2010-12-15 Thread Éric Araujo
>> -option. Run :program:`python regrtest.py -uall` to turn on all
>> +option. Run :program:`python -m regrtest -uall` to turn on all
> 
> Shouldn't this be `python -m test.regrtest`, or even just `python -m test`?

It should :)  I was about to fix just that but then noticed I could
remove more references to regrtest (after all just an implementation
detail), so I rewrote the section title and first few lines of the section.

My stupid email client forces rewrapping, so I’m attaching the diff as a
separate file. I can repost the patch to the tracker if it’s
inconvenient to review in email, but I’d like to commit soon since I
have a big doc merge to do after this :)

Best regards
Index: Doc/library/test.rst
===
--- Doc/library/test.rst	(révision 87297)
+++ Doc/library/test.rst	(copie de travail)
@@ -154,28 +154,31 @@
 
 .. _regrtest:
 
-Running tests using :mod:`test.regrtest`
-
+Running tests using the command-line interface
+--
 
-:mod:`test.regrtest` can be used as a script to drive Python's regression test
-suite. Running the script by itself automatically starts running all regression
+The :mod:`test` package can be run as a script to drive Python's regression
+test suite, thanks to the :option:`-m` option: :program:`python -m test`. Under
+the hood, it uses :mod:`test.regrtest`; the call :program:`python -m
+test.regrtest` used in previous Python versions still works).
+Running the script by itself automatically starts running all regression
 tests in the :mod:`test` package. It does this by finding all modules in the
 package whose name starts with ``test_``, importing them, and executing the
 function :func:`test_main` if present. The names of tests to execute may also
 be passed to the script. Specifying a single regression test (:program:`python
-regrtest.py test_spam.py`) will minimize output and only print
+-m test test_spam`) will minimize output and only print
 whether the test passed or failed and thus minimize output.
 
-Running :mod:`test.regrtest` directly allows what resources are available for
+Running :mod:`test` directly allows what resources are available for
 tests to use to be set. You do this by using the ``-u`` command-line
-option. Run :program:`python -m regrtest -uall` to turn on all
+option. Run :program:`python -m test -uall` to turn on all
 resources; specifying ``all`` as an option for ``-u`` enables all
 possible resources. If all but one resource is desired (a more common case), a
 comma-separated list of resources that are not desired may be listed after
-``all``. The command :program:`python -m regrtest -uall,-audio,-largefile`
-will run :mod:`test.regrtest` with all resources except the ``audio`` and
+``all``. The command :program:`python -m test -uall,-audio,-largefile`
+will run :mod:`test` with all resources except the ``audio`` and
 ``largefile`` resources. For a list of all resources and more command-line
-options, run :program:`python -m regrtest -h`.
+options, run :program:`python -m test -h`.
 
 Some other ways to execute the regression tests depend on what platform the
 tests are being executed on. On Unix, you can run :program:`make test` at the
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-checkins] r87296 - python/branches/py3k/Doc/library/test.rst

2010-12-15 Thread Michael Foord

On 16/12/2010 01:07, Éric Araujo wrote:

-option. Run :program:`python regrtest.py -uall` to turn on all
+option. Run :program:`python -m regrtest -uall` to turn on all

Shouldn't this be `python -m test.regrtest`, or even just `python -m test`?

It should :)  I was about to fix just that but then noticed I could
remove more references to regrtest (after all just an implementation
detail), so I rewrote the section title and first few lines of the section.

My stupid email client forces rewrapping, so I’m attaching the diff as a
separate file. I can repost the patch to the tracker if it’s
inconvenient to review in email, but I’d like to commit soon since I
have a big doc merge to do after this :)


The diff looks good to me.

All the best,

Michael



Best regards



--

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

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


Re: [Python-Dev] [Python-checkins] r87299 - in python/branches/py3k: Doc/library/configparser.rst Lib/configparser.py Lib/test/test_cfgparser.py

2010-12-15 Thread Éric Araujo
> Author: lukasz.langa
> New Revision: 87299
> 
> Log:
> Broken ConfigParser removed, SafeConfigParser renamed to ConfigParser.
> Life is beatiful once again.
IIIUC, this change makes bugs requesting use of SafeConfigParser in
distutils and logging obsolete.

> @@ -1139,6 +1122,6 @@
>  
>  if __name__ == "__main__":
>  if "-c" in sys.argv:
> -test_coverage('/tmp/cmd.cover')
> +test_coverage('/tmp/configparser.cover')
>  else:
>  test_main()

Consider using the tempfile module.  You need to print the filename on
stderr, I think.  Alternatively, remove this custom functionality
entirely and move it to regrtest or unittest.

Cheers

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


Re: [Python-Dev] [Python-checkins] r87296 - python/branches/py3k/Doc/library/test.rst

2010-12-15 Thread Éric Araujo
> The diff looks good to me.

Committed as r87300, thank you sir!

___
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] PEPs and versionadded

2010-12-15 Thread Éric Araujo
Hi,

I noticed that changes related to PEP 3147 and PEP 3149 in Doc haven’t
been accompanied by versionadded/versionchanged directives.

Is that on purpose, meaning that everyone should be aware of these PEPs
when reading 3.2 docs, or just an oversight?

Regards

___
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] PEPs and versionadded

2010-12-15 Thread Barry Warsaw
On Dec 16, 2010, at 03:41 AM, Éric Araujo wrote:

>I noticed that changes related to PEP 3147 and PEP 3149 in Doc haven’t
>been accompanied by versionadded/versionchanged directives.
>
>Is that on purpose, meaning that everyone should be aware of these PEPs
>when reading 3.2 docs, or just an oversight?

It's an oversight.  The changes should be accompanied by version* directives.
I see you already committed a change for compileall.rst - thanks for that!
Please feel free to add anything you find missing or submit a bug report and
assign it to me.

-Barry


signature.asc
Description: 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] PEPs and versionadded

2010-12-15 Thread Éric Araujo
> It's an oversight.  The changes should be accompanied by version* directives.
> I see you already committed a change for compileall.rst - thanks for that!
> Please feel free to add anything you find missing or submit a bug report and
> assign it to me.

The PEP 3149 commits did not touch Doc, apart from sys.rst which got its
versionadded added (duh) a short time after the code changes.  I don’t
know if the introduction of ABI flags ought to be documented more
prominently; Doc/using seems still accurate, and Doc/distutils is rather
vague about extensions, so I guess we’re good.

PEP 3147 modified a handful of files in Doc; I’ve added missing
directives in r87312.

__cached__ is only described in library/runpy.rst and c-api/import.rst.
 If there is one canonical place to define what a module is (I couldn’t
tell from http://docs.python.org/dev/genindex-M), I think it should be
mentioned there.  Copy-pasting the paragraph about __cached__ from the
PEP would suffice.

Both PEPs are well covered in whatsnew.  Three cheers for Raymond!

Regards

___
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