Re: [Python-Dev] cpython (3.2): Stop ignoring Mercurial merge conflits files (#12255).
On Fri, 29 Jul 2011 22:22:05 -0400 R. David Murray rdmur...@bitdance.com wrote: On Fri, 29 Jul 2011 23:36:03 +0200, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 29 Jul 2011 12:19:45 -0400 R. David Murray rdmur...@bitdance.com wrote: Besides, hg status is meant to show untracked files which could *potentially* be tracked. It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do. That's one view. My view is that 'hg status' tells me all the files that have appeared in my tree that I'm either not currently tracking or explicitly ignoring (because the project's automated tools will deal with them). Nothing in there about limiting it to files I *might* want to track. That is how I've always used my version control systems. Ok, I understand. However, it also makes things more tedious for other people who don't user their VCS in such a way, so it would be nice how other people feel about this. They can add those files to their personal .hgrc. I can't *remove* those ignores via mine. That's a good point. I hadn't thought about that. 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] cpython: Fix closes Issue11281 - smtplib.STMP gets source_address parameter, which adds
Hi Senthil,
+if source_address: self.source_address = source_address
Could you try to follow PEP 8?
(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)
+SMTP.__init__(self, host, port, local_hostname = local_hostname,
+source_address = source_address)
Ditto here (and other similar occurrences).
+def testSourceAddress(self):
+# connect
+smtp = smtplib.SMTP(HOST, self.port, local_hostname='localhost',
timeout=3,
+source_address=('127.0.0.1', 19876))
+self.assertEqual(smtp.source_address, ('127.0.0.1', 19876))
+self.assertEqual(smtp.local_hostname, 'localhost')
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.
There are utilities in test.support to help with this, such as
bind_port() or (less reliable) find_unused_port().
Actually, this can be triggered quite easily by running the test a
couple of times in parallel:
$ ./python -m test -m testSourceAddress -Fv -j3 test_smtplib
[...]
[ 14/4] test_smtplib
testSourceAddress (test.test_smtplib.GeneralTests) ... ok
testSourceAddress (test.test_smtplib.DebuggingServerTests) ... ERROR
==
ERROR: testSourceAddress (test.test_smtplib.DebuggingServerTests)
--
Traceback (most recent call last):
File /home/antoine/cpython/default/Lib/test/test_smtplib.py, line
220, in testSourceAddress source_address=('127.0.0.1', 19876))
File /home/antoine/cpython/default/Lib/smtplib.py, line 238, in
__init__ (code, msg) = self.connect(host, port)
File /home/antoine/cpython/default/Lib/smtplib.py, line 313, in
connect self.sock = self._get_socket(host, port, self.timeout)
File /home/antoine/cpython/default/Lib/smtplib.py, line 287, in
_get_socket self.source_address)
File /home/antoine/cpython/default/Lib/socket.py, line 407, in
create_connection raise err
File /home/antoine/cpython/default/Lib/socket.py, line 397, in
create_connection sock.bind(source_address)
socket.error: [Errno 98] Address already in use
--
+print(dir(smtp))
Usually, we avoid printing anything in tests, except when
support.verbose is True.
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] Convention on functions that shadow existing stdlib functions
Am 29.07.2011 11:26, schrieb Barry Warsaw: So I'm curious, why is this move better than adding noindexes, or just trusting users to understand the difference between test.support.unlink() and os.unlink()? If I currently search for 'unlink', os.unlink comes up first, which is good, and that should be preserved. The presence or not of some test.support.unlink documentation isn't going to make the search results that much better or worse (there's already 14 hits). Also don't forget that this is open-source: we shouldn't do questionable decisions (-1 from me on moving test.support docs to the devguide) just because the tool is lacking. I can probably hack up a small addition to Doc/tools/sphinxext in five minutes that ignores the whole of test.* when building the index. 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
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] Draft PEP: Simplified Package Layout and Partitioning
Hi, sorry for nitpicking, but... On Wed, Jul 20, 2011 at 05:58, P.J. Eby p...@telecommunity.com 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] Draft PEP: Simplified Package Layout and Partitioning
Hi Sandro, On Wed, Jul 20, 2011 at 05:58, P.J. Eby p...@telecommunity.com 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] 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 Reedytjre...@udel.edu 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] 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 Reedytjre...@udel.edu wrote: On 7/29/2011 5:32 PM, Antoine Pitrou wrote: On Fri, 29 Jul 2011 11:51:18 -0400 Barry Warsawba...@python.org 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] the history of tests being inside Lib/ in Python
On Sat, 30 Jul 2011 06:30:40 +0300, Eli Bendersky eli...@gmail.com 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 Sat, 30 Jul 2011 09:25:27 -0400 Terry Reedy tjre...@udel.edu 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] 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] cpython: make the types of None and Ellipsis callable
2011/7/29 Georg Brandl g.bra...@gmx.net: 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 benja...@python.org 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] Draft PEP: Simplified Package Layout and Partitioning
On Sat, Jul 30, 2011 at 14:57, Éric Araujo mer...@netwok.org wrote: On Wed, Jul 20, 2011 at 05:58, P.J. Eby p...@telecommunity.com 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] Convention on functions that shadow existing stdlib functions
On Sat, Jul 30, 2011 at 1:49 AM, Barry Warsaw ba...@python.org 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] cpython: make the types of None and Ellipsis callable
On Sun, Jul 31, 2011 at 12:12 AM, Benjamin Peterson benja...@python.org wrote: 2011/7/29 Georg Brandl g.bra...@gmx.net: 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 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] Convention on functions that shadow existing stdlib functions
On Sun, Jul 31, 2011 at 1:38 AM, Barry Warsaw ba...@python.org 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] [Python-checkins] cpython: Issue 12647: Add __bool__() method to the None object.
On Sat, Jul 30, 2011 at 6:08 AM, Brett Cannon br...@python.org 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] cpython: make the types of None and Ellipsis callable
On Sun, Jul 31, 2011 at 1:30 AM, Nick Coghlan ncogh...@gmail.com 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] 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 benja...@python.org 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: 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 benja...@python.org 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/7/30 Georg Brandl g.bra...@gmx.net: 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 benja...@python.org 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] [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 Araujomer...@netwok.org
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] [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 Kumaransent...@uthcode.com 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
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
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
