On Sun, 31 Oct 2010 18:15:43 +0100 (CET)
benjamin.peterson <python-checkins(a)python.org> wrote:
>
> # SimSMTPChannel doesn't fully support LOGIN or CRAM-MD5 auth because they
> # require a synchronous read to obtain the credentials...so instead smtpd
> @@ -503,6 +504,7 @@
> except smtplib.SMTPAuthenticationError as err:
> if sim_auth_login_password not in str(err):
> raise "expected encoded password not found in error message"
> + smtp.close()
Perhaps the string-raising above should be converted to 3.x-compliant
code?
> def testAUTH_CRAM_MD5(self):
> self.serv.add_feature("AUTH CRAM-MD5")
> @@ -512,6 +514,7 @@
> except smtplib.SMTPAuthenticationError as err:
> if sim_auth_credentials['cram-md5'] not in str(err):
> raise "expected encoded credentials not found in error message"
> + smtp.close()
Same here.
The regression tests for py3k (or, I think, any branch) fail on one of
my machines because test_grp chokes if /etc/group contains a "+" line,
which is a directive to pull information from NIS.
The test enumerates all entries in /etc/group using grp.getgrall() and
verifies that it can look up each entry by name using grp.getgrnam().
The current behavior of grp.getgrall() is to return entries whose
names start with plus or minus signs (NIS-related lines) as if they
were regular entries. The result is that the test tries to look up the
name "+" and fails because no entry is found.
It turns out that a bug on this issue has existed since 2003:
http://bugs.python.org/issue775964
The bug originally indicated that the problem is specific to Red Hat,
but that is not the case because I ran into it on Debian Squeeze.
According to a comment on the bug, this syntax in the group file has
been deprecated for a long time, which is why the issue rarely comes
up.
I believe the right thing to do at this point is to keep the behavior
of grp.getgrall(), but document that it will return NIS-related lines
along with regular entries and to modify the test to not try to look
up those entries with grp.getgrnam().
I've attached a patch to the bug that makes these changes and results
in the test passing. Is it possible that someone can review/ checkin
the patch? Thanks.
On Sun, Oct 31, 2010 at 9:56 AM, brian.curtin
<python-checkins(a)python.org> wrote:
> Author: brian.curtin
> Date: Sun Oct 31 01:56:45 2010
> New Revision: 86000
>
> Log:
> Fix ResourceWarning about unclosed file
>
>
> Modified:
> python/branches/py3k/Lib/test/test_fileio.py
>
> Modified: python/branches/py3k/Lib/test/test_fileio.py
> ==============================================================================
> --- python/branches/py3k/Lib/test/test_fileio.py (original)
> +++ python/branches/py3k/Lib/test/test_fileio.py Sun Oct 31 01:56:45 2010
> @@ -260,7 +260,6 @@
> # OS'es that don't support /dev/tty.
> pass
> else:
> - f = _FileIO("/dev/tty", "a")
> self.assertEquals(f.readable(), False)
> self.assertEquals(f.writable(), True)
> if sys.platform != "darwin" and \
Doesn't that delete the file object that the next two lines are trying to test?
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On Fri, Oct 29, 2010 at 10:38 AM, victor.stinner
<python-checkins(a)python.org> wrote:
> try:
> - path_list = env.get('PATH')
> + # ignore BytesWarning warning
> + with warnings.catch_warnings(record=True):
> + path_list = env.get('PATH')
This looks odd to me. You're requesting that the warnings be saved,
but not actually retrieving the list object where they're recorded
from the __enter__ method.
The correct way to suppress a specific warning type is:
with warnings.catch_warnings():
warnings.simplefilter("ignore", BytesWarning)
path_list = env.get('PATH')
I'll also echo Benjamin's concern with the embedded import. Of such
things, deadlocks are created. If there's a dependency problem between
os and the warnings build process in a fresh build, then it is better
to simply fix that rather than risking the deadlock.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On Fri, Oct 29, 2010 at 21:54, Barry Warsaw <barry(a)python.org> wrote:
> Another quick thought. What would people think about regular timed releases if python 2.7? This is probably more a question for Benjamin but doing sonmight provide better predictability and "customer service" to our users. I might like to see monthly releases but even quarterly would probably be useful. Doing timed releases might also incentivize folks to fix more outstanding 2.7 bugs.
I would really like to see a more regular and frequent release
schedule. Most of my experience with this is with Mercurial, where we
have a time-based schedule with a feature release every four months
and a bugfix release at least every month (usually at the first of
each month) and more often if we have bad regressions. It's nice
because (a) release are practiced more and therefore become easier to
do, (b) regressions can be fixed in a shorter timeframe. A predictable
schedule is also just nice for all parties involved.
In Gentoo, we actually started taking backports from the maintenance
branches to fix issues (regressions) in our packages, but didn't work
out so well. Obviously a random snapshot from SVN (even from a stable
branch) isn't exercised as well as an actual release, so we ended up
having some issues due to that. Also releasing packages with a version
number that doesn't fully correspond to the tarball is less than ideal
(we mitigated this somewhat by adding a date tag to the packages, but
still).
Here are the bugfix releases from the 2.6 branch:
2.6.1: 64 days
2.6.2: 131 days
2.6.3: 174 days
2.6.4: 23 days (critical regressions)
2.6.5: 145 days
2.6.6: 158 days
That's an average of 4 (if you include .4) or 4.5 months (PEP 6
specifies 6 months, but some of the parts seem outdated). I think
releasing each month might be a bit ambitious, but it would be great
to drive down the release interval towards 2-3 months instead of 4-5.
Cheers,
Dirkjan
For those of you who have not noticed, Antoine committed a patch that
raises a ResourceWarning under a pydebug build if a file or socket is
closed through garbage collection instead of being explicitly closed.
I have started to go through the test suite to fix as many of these
cases as possible, but it's time for me to stop. For those of you
interested in helping out, at the end of this email is a list of tests
which have some ResourceWarning raised. Some of them are probably
listed here because of some other module causing the problem.
Everything from test_mailbox and *up* I already tried to silence but
it the solution was non-obvious to me (or was very network-specific
which I don't have much experience with). from test_os *down* I have
not touched (although Antoine has gotten to some).
Just a little tip: if testMethod() comes up as the warning in unittest
it isn't unittest. =) Because the warning gets triggered at odd times
thanks to gc it doesn't always output a helpful line. Best thing is to
search for obvious things like "open(" or "socket(" to find things
that need a context manager if the line where the warning triggered
seems odd (both in the test and in the module being tested).
[ 92/349] test_distutils
[105/349] test_file
[108/349] test_fileio
[116/349] test_ftplib
[143/349] test_httplib
[144/349] test_httpservers
[154/349] test_io
[169/349] test_logging
[173/349] test_mailbox
[197/349] test_os
[214/349] test_pkgimport
[219/349] test_popen
[247/349] test_sax
[255/349] test_shutil
[260/349] test_smtplib
[263/349] test_socket
[267/349] test_ssl
[278/349] test_subprocess
[279/349] test_sunau
[289/349] test_tarfile
[291/349] test_telnetlib
[297/349] test_threading
[303/349] test_tokenize
[314/349] test_unicodedata
[320/349] test_urllib2_localnet
[328/349] test_uu
[343/349] test_xmlrpc
[345/349] test_zipfile
On Sat, 30 Oct 2010 02:13:01 +0200 (CEST)
brett.cannon <python-checkins(a)python.org> wrote:
> Author: brett.cannon
> Date: Sat Oct 30 02:13:00 2010
> New Revision: 85960
>
> Log:
> Silence some ResourceWarning in test_mailbox by using file context managers.
Unfortunately, these file-like objects don't support the context
management protocol:
======================================================================
ERROR: test_get_file (test.test_mailbox.TestMaildir)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_mailbox.py",
line 168, in test_get_file with self._box.get_file(key0) as file:
AttributeError: __exit__
======================================================================
ERROR: test_get_file (test.test_mailbox.TestMbox)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_mailbox.py",
line 168, in test_get_file with self._box.get_file(key0) as file:
AttributeError: __exit__
======================================================================
ERROR: test_get_file (test.test_mailbox.TestMMDF)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_mailbox.py",
line 168, in test_get_file with self._box.get_file(key0) as file:
AttributeError: __exit__
======================================================================
ERROR: test_get_file (test.test_mailbox.TestMH)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_mailbox.py",
line 168, in test_get_file with self._box.get_file(key0) as file:
AttributeError: __exit__
Am 25.10.2010 19:37, schrieb victor.stinner:
> Author: victor.stinner
> Date: Mon Oct 25 19:37:18 2010
> New Revision: 85838
>
> Log:
> update gitignore
>
> Added:
> python/branches/py3k/.gitignore
This looks more like "Add gitignore". Do we really want to check in
ignore files for every possible DVCS?
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.