Re: [Python-Dev] cpython (2.7): note Ellipsis syntax
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
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
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
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
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.
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/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
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
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
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.
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
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
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
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
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"
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/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
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
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
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
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
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"
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"
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
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
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