Re: [Python-Dev] cpython (2.7): note Ellipsis syntax

2011-07-30 Thread Raymond Hettinger

On Jul 30, 2011, at 11:28 PM, Georg Brandl wrote:

> 
> (Also, there must have been some reason to make "..." available everywhere
> for Python 3.)
> 

It's really nice for stub functions:

def foo(x):
...


Raymond

___
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 (2.7): note Ellipsis syntax

2011-07-30 Thread Georg Brandl
On 07/30/11 19:25, Benjamin Peterson wrote:
> 2011/7/30 Georg Brandl :
>> On 07/30/11 17:00, benjamin.peterson wrote:
>>> http://hg.python.org/cpython/rev/402f94edf11b
>>> changeset:   71637:402f94edf11b
>>> branch:  2.7
>>> user:Benjamin Peterson 
>>> date:Sat Jul 30 09:59:12 2011 -0500
>>> summary:
>>>   note Ellipsis syntax
>>>
>>> files:
>>>   Doc/library/stdtypes.rst |  2 +-
>>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>>
>>> diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst
>>> --- a/Doc/library/stdtypes.rst
>>> +++ b/Doc/library/stdtypes.rst
>>> @@ -2930,7 +2930,7 @@
>>>  supports no special operations.  There is exactly one ellipsis object, 
>>> named
>>>  :const:`Ellipsis` (a built-in name).
>>>
>>> -It is written as ``Ellipsis``.
>>> +It is written as ``Ellipsis`` or ``...``.
>>
>> In 2.7, this is not true; ``...`` only works in slices there.
> 
> I know, but why would you use Ellipsis outside of slices?

I wouldn't, but that's not the point: the wording as it is now will lead readers
to think that they can use the Ellipsis singleton as in Python 3, and they will
complain and report bugs about this.

(Also, there must have been some reason to make "..." available everywhere
for Python 3.)

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] [Python-checkins] cpython: Fix closes Issue11281 - smtplib.STMP gets source_address parameter, which adds

2011-07-30 Thread Senthil Kumaran
On Sat, Jul 30, 2011 at 11:11:08PM +0300, Ezio Melotti wrote:
> >-.. class:: SMTP(host='', port=0, local_hostname=None[, timeout])
> >+.. class:: SMTP(host='', port=0, local_hostname=None[, timeout], 
> >source_address=None)
> 
> The "[, timeout]" now looks weird there, and it would be better to
> convert it to ", timeout=..." to match the other args.
> However I don't know what the value should be, since the real value
> is socket._GLOBAL_DEFAULT_TIMEOUT (i.e. object()) and I don't think
> it's a good idea to expose that.  Maybe "None" can be used instead?

I found that [, timeout] bit odd too. But is not mentioning that as
timeout=None when it is timeout=socket._GLOBAL_DEFAULT_TIME
technically inaccurate?

FWIW, I see similar style (...,[,timeout], kw=val) adopted elsewhere
in the library docs too.  urllib, httplib, nntplib etc. Though it does
not look okay, it is better than giving inaccurate information.

While ftplib and poplib, has them as timeout=None, while they default
to socket._GLOBAL_DEFAULT_TIMEOUT object.

If we decide upon something, it can be made consistent. So, the
question is, when the timeout argument refers to
socket._GLOBAL_DEFAULT_TIME, how should we write the docs.

1. def somesocketmethod(arg1,arg2, timeout=socket._GLOBAL_DEFAULT_TIMEOUT, ...)

- I don't see anything is wrong with this.

2. def somesocketmethod(arg1,arg2, timeout=None, ...)

- And explain that it actually points to a socket default timeout
object, which is odd and can lead to user errors.

3. def somesocketmethod(arg1,arg2[,timeout], kwarg=value)

- That's how it is currently explained at some places. If this style
  is okay, we can change the places were it refers to None  to be
  above.

Thanks for your review comments, I have address the remaining ones.

-- 
Senthil
___
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 (2.7): note Ellipsis syntax

2011-07-30 Thread Greg Ewing

Benjamin Peterson wrote:


why would you use Ellipsis outside of slices?


I could imagine someone wanting to use it as part of a
function API. For example,

   print(a, b, c, ...)

would have been a nice way to tell print() not to put
a newline on the end.

--
Greg
___
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] [Python-checkins] cpython: Fix closes Issue11281 - smtplib.STMP gets source_address parameter, which adds

2011-07-30 Thread Ezio Melotti

Hi,

On 30/07/2011 5.58, senthil.kumaran wrote:

http://hg.python.org/cpython/rev/26839edf3cc1
changeset:   71617:26839edf3cc1
parent:  71613:018e14a46454
user:Senthil Kumaran
date:Sat Jul 30 10:56:50 2011 +0800
summary:
   Fix closes Issue11281 - smtplib.STMP gets source_address parameter, which 
adds the ability to bind to specific source address on a machine with multiple 
interfaces. Patch by Paulo Scardine.

files:
   Doc/library/smtplib.rst  |  33 +-
   Lib/smtplib.py   |  40 ++-
   Lib/test/mock_socket.py  |   3 +-
   Lib/test/test_smtplib.py |  17 +++
   Misc/NEWS|   4 ++
   5 files changed, 75 insertions(+), 22 deletions(-)


diff --git a/Doc/library/smtplib.rst b/Doc/library/smtplib.rst
--- a/Doc/library/smtplib.rst
+++ b/Doc/library/smtplib.rst
@@ -20,7 +20,7 @@
  Protocol) and :rfc:`1869` (SMTP Service Extensions).


-.. class:: SMTP(host='', port=0, local_hostname=None[, timeout])
+.. class:: SMTP(host='', port=0, local_hostname=None[, timeout], 
source_address=None)


The "[, timeout]" now looks weird there, and it would be better to 
convert it to ", timeout=..." to match the other args.
However I don't know what the value should be, since the real value is 
socket._GLOBAL_DEFAULT_TIMEOUT (i.e. object()) and I don't think it's a 
good idea to expose that.  Maybe "None" can be used instead?




 A :class:`SMTP` instance encapsulates an SMTP connection.  It has methods
 that support a full repertoire of SMTP and ESMTP operations. If the 
optional
@@ -29,7 +29,12 @@
 raised if the specified host doesn't respond correctly. The optional
 *timeout* parameter specifies a timeout in seconds for blocking operations
 like the connection attempt (if not specified, the global default timeout
-   setting will be used).
+   setting will be used). The optional source_address parameter allows to bind 
to some
+   specific source address in a machine with multiple network interfaces,
+   and/or to some specific source tcp port. It takes a 2-tuple (host, port),


I think TCP should be uppercase.


+   for the socket to bind to as its source address before connecting. If
+   ommited (or if host or port are '' and/or 0 respectively) the OS default


s/ommited/omitted/ and s/''/``''``/


+   behavior will be used.

 For normal use, you should only require the initialization/connect,
 :meth:`sendmail`, and :meth:`quit` methods.  An example is included below.
@@ -48,8 +53,10 @@
 .. versionchanged:: 3.3
Support for the :keyword:`with` statement was added.

+   .. versionadded:: 3.3
+  source_address parameter.


I think the convention is to use "versionadded" when the 
function/method/class/etc has been added, and "versionchanged" for all 
the changes, including new arguments.



-.. class:: SMTP_SSL(host='', port=0, local_hostname=None, keyfile=None, 
certfile=None[, timeout], context=None)
+.. class:: SMTP_SSL(host='', port=0, local_hostname=None, keyfile=None, 
certfile=None[, timeout], context=None, source_address=None)


Ditto for "[, timeout]" and the typos/markup below.


 A :class:`SMTP_SSL` instance behaves exactly the same as instances of
 :class:`SMTP`. :class:`SMTP_SSL` should be used for situations where SSL is
@@ -62,18 +69,28 @@
 keyfile and certfile must be None.  The optional *timeout*
 parameter specifies a timeout in seconds for blocking operations like the
 connection attempt (if not specified, the global default timeout setting
-   will be used).
+   will be used). The optional source_address parameter allows to bind to some
+   specific source address in a machine with multiple network interfaces,
+   and/or to some specific source tcp port. It takes a 2-tuple (host, port),
+   for the socket to bind to as its source address before connecting. If
+   ommited (or if host or port are '' and/or 0 respectively) the OS default
+   behavior will be used.

 .. versionchanged:: 3.3
*context* was added.

+   .. versionadded:: 3.3
+  source_address parameter.

-.. class:: LMTP(host='', port=LMTP_PORT, local_hostname=None)
+
+.. class:: LMTP(host='', port=LMTP_PORT, local_hostname=None, 
source_address=None)

 The LMTP protocol, which is very similar to ESMTP, is heavily based on the
-   standard SMTP client. It's common to use Unix sockets for LMTP, so our 
:meth:`connect`
-   method must support that as well as a regular host:port server. To specify a
-   Unix socket, you must use an absolute path for *host*, starting with a '/'.
+   standard SMTP client. It's common to use Unix sockets for LMTP, so our
+   :meth:`connect` method must support that as well as a regular host:port
+   server. The optional parameters local_hostname and source_address has the


s/has/have/?
Also I prefer 'arguments' rather than 'parameters', the smtplib doc uses 
both, but 'arguments' seems to be used more.



+   same meaning as that of SMTP cli

Re: [Python-Dev] [Python-checkins] cpython: Modernize modulefinder module and tests a bit.

2011-07-30 Thread Ezio Melotti

Hi,

On 29/07/2011 15.35, eric.araujo wrote:

http://hg.python.org/cpython/rev/1521d9837d16
changeset:   71569:1521d9837d16
user:Éric Araujo
date:Thu Jul 28 23:35:29 2011 +0200
summary:
   Modernize modulefinder module and tests a bit.

The tests don’t use an internal distutils function anymore, and use
regular assertEqual with sorted lists instead of a convoluted manual
diff.

files:
   Lib/modulefinder.py   |  15 ++
   Lib/test/test_modulefinder.py |  48 +++---
   2 files changed, 31 insertions(+), 32 deletions(-)


diff --git a/Lib/modulefinder.py b/Lib/modulefinder.py
--- a/Lib/modulefinder.py
+++ b/Lib/modulefinder.py
@@ -1,6 +1,5 @@
  """Find modules used by a script, using introspection."""

-from __future__ import generators
  import dis
  import imp
  import marshal
@@ -9,8 +8,6 @@
  import types
  import struct

-READ_MODE = "rU"
-
  # XXX Clean up once str8's cstor matches bytes.
  LOAD_CONST = bytes([dis.opname.index('LOAD_CONST')])
  IMPORT_NAME = bytes([dis.opname.index('IMPORT_NAME')])
@@ -29,8 +26,7 @@

  # A Public interface
  def AddPackagePath(packagename, path):
-paths = packagePathMap.get(packagename, [])
-paths.append(path)
+paths = packagePathMap.setdefault(packagename, []).append(path)


I'm assuming that packagePathMap is a dict that might contain or not a 
*packagename* key that maps to a list of paths.
Now, unless I'm missing something, the old code assigned to *paths* the 
list of paths or [] if it wasn't there, and then appended *path* to it.

AFAICS, the new code introduced two changes:
  1) the packagename key is added to the dict if it was missing -- and 
this seems reasonable;
  2) append is now on the same line, it returns None, and None is 
assigned to *paths* -- and this seems wrong;



  packagePathMap[packagename] = paths


Also this is not necessary anymore if you use setdefault.


  replacePackageMap = {}
@@ -106,14 +102,14 @@

  [...]


Best Regards,
Ezio Melotti
___
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 (2.7): note Ellipsis syntax

2011-07-30 Thread Benjamin Peterson
2011/7/30 Georg Brandl :
> On 07/30/11 17:00, benjamin.peterson wrote:
>> http://hg.python.org/cpython/rev/402f94edf11b
>> changeset:   71637:402f94edf11b
>> branch:      2.7
>> user:        Benjamin Peterson 
>> date:        Sat Jul 30 09:59:12 2011 -0500
>> summary:
>>   note Ellipsis syntax
>>
>> files:
>>   Doc/library/stdtypes.rst |  2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>>
>> diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst
>> --- a/Doc/library/stdtypes.rst
>> +++ b/Doc/library/stdtypes.rst
>> @@ -2930,7 +2930,7 @@
>>  supports no special operations.  There is exactly one ellipsis object, named
>>  :const:`Ellipsis` (a built-in name).
>>
>> -It is written as ``Ellipsis``.
>> +It is written as ``Ellipsis`` or ``...``.
>
> In 2.7, this is not true; ``...`` only works in slices there.

I know, but why would you use Ellipsis outside of slices?



-- 
Regards,
Benjamin
___
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: we can call singleton types now

2011-07-30 Thread Georg Brandl
On 07/30/11 17:03, benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/4a07b772f0e0
> changeset:   71639:4a07b772f0e0
> user:Benjamin Peterson 
> date:Sat Jul 30 10:03:09 2011 -0500
> summary:
>   we can call singleton types now
> 
> files:
>   Doc/library/stdtypes.rst |  8 +---
>   1 files changed, 5 insertions(+), 3 deletions(-)
> 
> 
> diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst
> --- a/Doc/library/stdtypes.rst
> +++ b/Doc/library/stdtypes.rst
> @@ -2706,7 +2706,7 @@
>  
>  This object is returned by functions that don't explicitly return a value.  
> It
>  supports no special operations.  There is exactly one null object, named
> -``None`` (a built-in name).
> +``None`` (a built-in name).  Calling ``type(None)`` produces the same 
> singleton.

I know this is technically correct, but it will look like you mean "calling
type with None as argument" (same for the other singletons).

Probably better to say something like "``type(None)()`` produces ...".

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 (2.7): note Ellipsis syntax

2011-07-30 Thread Georg Brandl
On 07/30/11 17:00, benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/402f94edf11b
> changeset:   71637:402f94edf11b
> branch:  2.7
> user:Benjamin Peterson 
> date:Sat Jul 30 09:59:12 2011 -0500
> summary:
>   note Ellipsis syntax
> 
> files:
>   Doc/library/stdtypes.rst |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst
> --- a/Doc/library/stdtypes.rst
> +++ b/Doc/library/stdtypes.rst
> @@ -2930,7 +2930,7 @@
>  supports no special operations.  There is exactly one ellipsis object, named
>  :const:`Ellipsis` (a built-in name).
>  
> -It is written as ``Ellipsis``.
> +It is written as ``Ellipsis`` or ``...``.

In 2.7, this is not true; ``...`` only works in slices there.

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: make the types of None and Ellipsis callable

2011-07-30 Thread Nick Coghlan
On Sun, Jul 31, 2011 at 1:30 AM, Nick Coghlan  wrote:
> And on that note... was there any particular reason for leaving
> NotImplemented out for this change?

Never mind, just noticed the subsequest checkin.

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] [Python-checkins] cpython: Issue 12647: Add __bool__() method to the None object.

2011-07-30 Thread Nick Coghlan
On Sat, Jul 30, 2011 at 6:08 AM, Brett Cannon  wrote:
> Wasn't this change only in 3.3 where __nonzero__ doesn't exist? So when PyPy
> eventually supports Python 3 they will have to update to support __bool__ on
> None but this test won't exercise that for them. IOW I think the guard is
> wrong and should go.

The entire assertion was removed by Raymond's checkin, as the addition
of None.__bool__ made it false on CPython as well.

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] Convention on functions that shadow existing stdlib functions

2011-07-30 Thread Nick Coghlan
On Sun, Jul 31, 2011 at 1:38 AM, Barry Warsaw  wrote:
> On Jul 31, 2011, at 01:23 AM, Nick Coghlan wrote:
>
>>It sounds to me like you're really objecting to the devguide living in
>>a separate clone. This doesn't bode well for the prospects of ever
>>splitting the stdlib out from the CPython interpreter core...
>
> Actually, no.  I'm objecting to moving documentation for code to a different
> repo than the code.  If/when the stdlib is split out (which I support), then
> the documentation should go with it.

That's a rather valid point that I can definitely agree with.

OK, you've convinced me that the right thing to do is leave the
test.support docs where they are and just apply the appropriate markup
to keep them out of the various indices.

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] Convention on functions that shadow existing stdlib functions

2011-07-30 Thread Barry Warsaw
On Jul 31, 2011, at 01:23 AM, Nick Coghlan wrote:

>It sounds to me like you're really objecting to the devguide living in
>a separate clone. This doesn't bode well for the prospects of ever
>splitting the stdlib out from the CPython interpreter core...

Actually, no.  I'm objecting to moving documentation for code to a different
repo than the code.  If/when the stdlib is split out (which I support), then
the documentation should go with it.

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] cpython: make the types of None and Ellipsis callable

2011-07-30 Thread Nick Coghlan
On Sun, Jul 31, 2011 at 12:12 AM, Benjamin Peterson  wrote:
> 2011/7/29 Georg Brandl :
>> Shouldn't there be a matching Doc change somewhere?
>
> Somewhere is the question!

While None/NotImplemented/Ellipsis are all documented as singletons,
the behaviour of calling their types is not specified anywhere. If
this was to be detailed anywhere, then the sections on
None/NotImplemented/Ellipsis in section 3.2 of the language reference
would be the place.

And on that note... was there any particular reason for leaving
NotImplemented out for this change?

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] Convention on functions that shadow existing stdlib functions

2011-07-30 Thread Nick Coghlan
On Sat, Jul 30, 2011 at 1:49 AM, Barry Warsaw  wrote:
> On Jul 30, 2011, at 01:02 AM, Nick Coghlan wrote:
> If test.support is truly and only an internal implementation detail, then it
> should adhere to Pythonic convention for such things, and be renamed
> test._support.  Then you won't need to document it at all except in the
> module.

Aside from test.regrtest and test.support, the entirety of the rest of
the test package is completely undocumented. test.support is unique,
as it is the only component other than the main executable that is
documented *at all*, solely for the benefits of people writing new
tests. We don't even document the resources that can be enabled from
the command line, instead telling people to look at the command line
help output.

The entire test package is an implementation detail, underscore or no
underscore - we will never, ever, offer any kind of backwards
compatibility guarantee for code in that part of the package
hierarchy.

> Here's another problem with moving the documentation for test.support to the
> devguide.  They will invariably get out of sync.  It's hard enough to keep
> stdlib code and stdlib docs in sync, but I think it will be even harder to
> keep stdlib code in sync with devguide documentation.  It will also be harder
> to know what version of the devguide corresponds to what version of the code
> repository.

By that reasoning, we should just give up and delete the test.support
docs entirely  (since they're *already* treated with disrespect by
contrast to the real stdlib docs).

It sounds to me like you're really objecting to the devguide living in
a separate clone. This doesn't bode well for the prospects of ever
splitting the stdlib out from the CPython interpreter core...

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] Draft PEP: "Simplified Package Layout and Partitioning"

2011-07-30 Thread Sandro Tosi
On Sat, Jul 30, 2011 at 14:57, Éric Araujo  wrote:
>> On Wed, Jul 20, 2011 at 05:58, P.J. Eby  wrote:
>>> For those implementing PEP \302 importer objects:
>>
>> the '\' should be removed, right?
>
> No.  Philip used backslashes to prevent the HTML conversion to transform
> each and every instance of “PEP \d+” to a link, which gets annoying
> after the few first hundred times.  (It was discussed a few months ago
> probably on web-sig or python-dev for PEP 333 or , if memory serves.)

Gaah, sorry for the noise then! (but at least I learnt a new thing!)

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
___
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: make the types of None and Ellipsis callable

2011-07-30 Thread Benjamin Peterson
2011/7/29 Georg Brandl :
> Am 30.07.2011 01:20, schrieb benjamin.peterson:
>> http://hg.python.org/cpython/rev/84c3be27b4c7
>> changeset:   71614:84c3be27b4c7
>> parent:      71611:a6afd26caa8a
>> user:        Benjamin Peterson 
>> date:        Fri Jul 29 18:19:43 2011 -0500
>> summary:
>>   make the types of None and Ellipsis callable
>>
>> files:
>>   Lib/test/test_builtin.py |   7 +
>>   Misc/NEWS                |   3 ++
>>   Objects/object.c         |  34 
>>   Objects/sliceobject.c    |  29 +++
>>   4 files changed, 73 insertions(+), 0 deletions(-)
>
> Shouldn't there be a matching Doc change somewhere?

Somewhere is the question!


-- 
Regards,
Benjamin
___
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: Fix closes Issue11281 - smtplib.STMP gets source_address parameter, which adds

2011-07-30 Thread Senthil Kumaran
Hello Antoine,

On Sat, Jul 30, 2011 at 08:46:00AM +0200, Antoine Pitrou wrote:

> (I know PEP 8 is not always followed in old code, but there's no reason
> not to follow it in code that we add to the stdlib)
> 

Thanks for pointing out. I somehow overlooked it. I shall refactor
that lib.


> Unless this test is also using some kind of mock socket (it doesn't
> seem to), this can break as soon as port 19876 is already in use.

Yes, there is one test which does not follow the mock socket and had
not realized this it may break when run in parallel (and 19876 is
use). Shall use the test facilities which are provided to resolve
(/synchronize) that condition.

> > +print(dir(smtp))

:-) That's was definitely my unintentional mistake. Funny that when I
ran the individual tests a couple of times, I did not see that
remaining and hard to see it when run the entire suite. Should
be removed.

-- 
Senthil
___
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] Convention on functions that shadow existing stdlib functions

2011-07-30 Thread Antoine Pitrou
On Sat, 30 Jul 2011 09:25:27 -0400
Terry Reedy  wrote:
> >
> > I'm sorry, can you be more precise. The effect of what?
> 
> Your proposal to remove the current formatted documentation of 
> test.support instead of completing it and force all developers to only 
> have reference to the docstrings scattered through the code.
> 
> > And why would that be so?
> 
> Because not everyone is like you. Because the condensed formatted docs 
> make learning and using a module significantly easier for some people.

Ok, I understand. I just hope the notice at the top of the module doc
is prominent enough that nobody will think there's any API guarantee
there.

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] the history of tests being inside Lib/ in Python

2011-07-30 Thread R. David Murray
On Sat, 30 Jul 2011 06:30:40 +0300, Eli Bendersky  wrote:
> This mail can appear as if advocating the transfer of Lib/test into Tests/,
> but this is not my intention here. Honest :-) I'm just trying to understand
> the history and rationale behind this structure in the CPython project.

My understanding (I could well be wrong) is that one reason is that we
prefer that the tests be installed.  That is also the reason that a number
of tests that use large data files fetch them from the network (if and
only if the relevant resource is enabled).

--
R. David Murray   http://www.bitdance.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] Convention on functions that shadow existing stdlib functions

2011-07-30 Thread Terry Reedy

On 7/29/2011 7:27 PM, Antoine Pitrou wrote:

On Fri, 29 Jul 2011 19:02:32 -0400
Terry Reedy  wrote:

On 7/29/2011 5:32 PM, Antoine Pitrou wrote:

On Fri, 29 Jul 2011 11:51:18 -0400
Barry Warsaw   wrote:



The solution then is to rename test.support to test._support to make it clear
it's an internal implementation detail.  Then you can remove the entire
section from the stdlib docs and just document it in the code.


Ideally so.


The effect of this will be to discourage new people (including myself in
the category) from writing or reviewing patches.


I'm sorry, can you be more precise. The effect of what?


Your proposal to remove the current formatted documentation of 
test.support instead of completing it and force all developers to only 
have reference to the docstrings scattered through the code.



And why would that be so?


Because not everyone is like you. Because the condensed formatted docs 
make learning and using a module significantly easier for some people.


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] Convention on functions that shadow existing stdlib functions

2011-07-30 Thread Terry Reedy

On 7/29/2011 6:54 PM, Antoine Pitrou wrote:

On Fri, 29 Jul 2011 18:47:07 -0400
Terry Reedy  wrote:



And test.support *is* for internal use.


No, the stuff in there is *not* for internal use within the module but
for external use is possiby every test module.


I meant internal use for us. Really, whether or not it's
used cross-module is irrelevant.


It is not at all irrelevant to me as a newer developer. I see uses of 
test.support.x quite often in checkins and I apparently should know 
about the contents of test.support for writing tests so I can use things 
as appropriate. Ditto for everyone else. On the other hand, the private 
support functions in trace.py are irrelevant to everyone except for the 
occasional person doing occasion maintenance work on that module.


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] Draft PEP: "Simplified Package Layout and Partitioning"

2011-07-30 Thread Éric Araujo
Hi Sandro,

> On Wed, Jul 20, 2011 at 05:58, P.J. Eby  wrote:
>> For those implementing PEP \302 importer objects:
> 
> the '\' should be removed, right?

No.  Philip used backslashes to prevent the HTML conversion to transform
each and every instance of “PEP \d+” to a link, which gets annoying
after the few first hundred times.  (It was discussed a few months ago
probably on web-sig or python-dev for PEP 333 or , if memory serves.)

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] Draft PEP: "Simplified Package Layout and Partitioning"

2011-07-30 Thread Sandro Tosi
Hi,
sorry for nitpicking, but...

On Wed, Jul 20, 2011 at 05:58, P.J. Eby  wrote:
...
> For those implementing PEP \302 importer objects:

the '\' should be removed, right?

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
___
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] Convention on functions that shadow existing stdlib functions

2011-07-30 Thread Georg Brandl
Am 27.07.2011 19:47, schrieb Terry Reedy:
> On 7/27/2011 1:27 PM, Brett Cannon wrote:
> 
>> Perhaps what we could do is move the documentation for test.support to
>> the devguide, and then vet the test suite so that unlink and friends
>> are always called as 'support.unlink', etc.
>>
>>
>> I like this solution since this issue of documenting test.support keeps
>> coming up. Otherwise we can not document test.support,
> 
> We already do.
> 
> 25.6. test.support — Utility functions for tests

FWIW, this heading could give wrong impressions.  I just changed it to

:mod:`test.support` --- Utilities for the Python test suite

and also added another note under it that the API is subject to change
at any time.

> is about half of the page that also contains
> 25.5. test — Regression tests package for Python
> The latter contains
> 25.5.1. Writing Unit Tests for the test package
> which should also be moved to the dev guide if 25.6 is.

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] Convention on functions that shadow existing stdlib functions

2011-07-30 Thread Georg Brandl
Am 27.07.2011 19:44, schrieb Terry Reedy:
> On 7/27/2011 9:24 AM, Antoine Pitrou wrote:
> 
>> Docstrings are sufficient for own our purposes.
> 
>  >>> import test.support as t
>  >>> help(t.rmtree)
> Help on function rmtree in module test.support:
> 
> rmtree(path)

Well, what are you waiting for... just add the docstring!

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