Changes by R. David Murray :
--
stage: -> test needed
title: Exception AttributeError: AttributeError("'_DummyThread' object has no
attribute '_Thread__block'",) in ignored -> '_DummyThread' object has no
attribute '_Thread__b
R. David Murray added the comment:
OK, I've gone through Dan's update (thanks very much for the tests!). I'm
uploading a revised patch. The major differences are:
I've refactored the parsing. Now it is a three step process: peel off the
extra keyword (FROM:, TO:) i
Changes by R. David Murray :
Added file: http://bugs.python.org/file24855/issue8739.patch
___
Python tracker
<http://bugs.python.org/issue8739>
___
___
Python-bugs-list m
New submission from R. David Murray :
I'm working on a patch that updates smtpd, and when I ran the full test suite I
got a hang in test_logging. This means there's a bug in my update, but there
is also a bug in the logging test.
But see below for another issue I noticed while inv
R. David Murray added the comment:
The test failure in #14314 isn't a bug in my code, it is due to the fact that
you copied the __init__ method of SMTPChannel in your logging tests, and the
__init__ is changed by my patch. Clearly it would be good to resolve this
issue one way or an
R. David Murray added the comment:
Note that this patch causes test_logging to fail/hang. I've opened issue 14314
that mentions the hang (the issue is really about the lack of a timeout in
logging's smtp handler) and updated issue 11959 about the issues involved in
test_logging u
Changes by R. David Murray :
--
assignee: -> r.david.murray
resolution: -> fixed
stage: -> committed/rejected
type: -> behavior
___
Python tracker
<http://bugs.python
R. David Murray added the comment:
Fixed in the email6 feature branch. Thanks Brian.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
R. David Murray added the comment:
Thanks, Dylan.
--
nosy: +r.david.murray
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Changes by R. David Murray :
--
dependencies: +Update to smtpd.py to RFC 5321
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issu
R. David Murray added the comment:
Thanks for the patch.
I think this is fine.
An alternate approach would be to introduce the concept of a state (like
imaplib has), have a list of which commands are allowed in which state, and
implement the check in the command processing function, but
R. David Murray added the comment:
Oh, by the way the mention of EHLO in that message depends on issue 8739 going
in.
--
___
Python tracker
<http://bugs.python.org/issue14
R. David Murray added the comment:
When do patches get applied? The general answer is "when someone gets around
to it" :)
In this particular case the issue 8739 patch is waiting on the resolution of
its dependency (logging uses smtpd in its tests, and the 8739 patch breaks the
lo
Changes by R. David Murray :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
Nope, those errors are correct. The encodings functions do not apply to
Multipart messages. I've updated the docs to reflect that.
--
components: +Documentation -Library (Lib)
resolution: -> fixed
stage: -> committed/rejected
s
R. David Murray added the comment:
Thanks, fixed.
--
___
Python tracker
<http://bugs.python.org/issue11780>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
Thanks for the patch, Steffen.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
To answer your question about wrapping, it is best not to introduce noise into
the patch. The person who commits it can rewrap (although even then it is nice
to do the rewrapping in a separate changeset).
--
nosy: +r.david.murray
R. David Murray added the comment:
That doesn't produce an evalable repr, though. The repr should actually be
Policy(linesep='\\r\\n', max_line_length=None)
I'm not immediately seeing how to get that to happen.
--
___
P
R. David Murray added the comment:
Ach, I screwed up my testing at the interactive interpreter. Yes, it does
work, and I will commit the fix. Thanks for the report.
--
___
Python tracker
<http://bugs.python.org/issue14
R. David Murray added the comment:
Committed.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
The patch was actually by Brian Curtin, before he got commit privs :).
Attached is a fix.
I don't know what t.py has to do with the issue, though. I'm experimenting to
see if I can trigger the bug before I apply the fix.
--
keywor
Changes by R. David Murray :
--
nosy: +brian.curtin
___
Python tracker
<http://bugs.python.org/issue12757>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
OK, ./python -OO -m test test_json will trigger it.
Updated fix attached. I'm not completely happy with it, though, since it
prints the 'skipping test from module XXX' twice, and I don't know why (some
unittest thing I'm not
R. David Murray added the comment:
Oh, in case anyone is wondering, the fix for -OO test runs was originally made
because the unladen swallow folks ran the test suite that way. (I think
someone else wanted it too, but I don't remember who). It's broken again, so I
doubt anyone i
R. David Murray added the comment:
I believe this was already found by someone (Georg, Martin?) and fixed by Ezio.
--
assignee: docs@python -> ezio.melotti
nosy: +ezio.melotti, r.david.murray
___
Python tracker
<http://bugs.python.org/issu
R. David Murray added the comment:
Not only do I think we should support calling our tests via unittest, I think
we should move in the direction of having regrtest be implemented via standard
unittest hooks rather than the monster it currently is. That will take quite a
bit of effort
Changes by R. David Murray :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue14353>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
Yes, our preferred approach is to make such cleanups when we touch that section
of code for some other reason. Like Éric said, your willingness to contribute
is very much appreciated and we hope you'll find another bug to work on.
--
s
R. David Murray added the comment:
@Ramchandra: I think you referring to the traceback format (which is indeed
less useful than a normal Python traceback in the context of this tracker).
The OP, however, is referring to the exception itself:
TypeError: object.__new__(listiterator) is not
Changes by R. David Murray :
--
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue14350>
___
___
Python-bugs-list mailin
R. David Murray added the comment:
I think it is unlikely that anyone depends on argparse consuming multiple --
strings. If you are worried about it we could restrict the change to 3.3. But
personally I think this would be OK for a bug fix.
--
nosy: +r.david.murray
versions
R. David Murray added the comment:
It does look like there's anomalous behavior here of some sort, but I'd expect
--test=-- to result in test="--", myself, rather than an error. My intuition
is that '--' would need to be preceded by a space to function a
Changes by R. David Murray :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14115>
___
___
Python-bugs-list mailing list
Unsubscri
R. David Murray added the comment:
No, it is definitely a bug. It prevents implementing parsers that pass strings
on to another sub-parser or command. Imagine, for example, implementing a
script that takes some arguments, but takes the entire rest of the command
string and passes it to
R. David Murray added the comment:
Interesting. I would have said that an open source project ought to have a
link for reporting bugs on the front page, but I just checked perl.org and
apache.org, and they both put the bug tracker links on the 'get involved' page.
The devgui
R. David Murray added the comment:
That is indeed better than the current devguide for introducing people to the
community. I think the current devguide is better at explaining the
development process in detail, but that's not what is needed for a 'getting
invo
R. David Murray added the comment:
Interesting. Apparently we have no tests for the encode_ functions, nor do we
use them inside the email package itself (except for encode_7or8bit).
Do you have any interest in writing a patch with tests?
--
assignee: -> r.david.murray
n
R. David Murray added the comment:
Thanks, Eric.
--
nosy: +r.david.murray
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
If one could distinguish that python had ended because of a sigint from the
error code, then it would be possible for the caller to throw away stderr in
that case. I agree with the OP that that having to deal with the traceback
when you know what you want
R. David Murray added the comment:
I applied both patches, and I get 16 test failures in test_smtpd. I haven't
looked at the errors, but probably most of them are lack of a HELO in the test.
--
___
Python tracker
<http://bugs.py
R. David Murray added the comment:
Hmm. I'm certain that QUIT shouldn't require HELO, and I wouldn't expect that
NOOP would either.
I just checked the RFC. The *only* command that requires HELO/EHLO is MAIL (and
by implication RCPT, since it in turn requires MA
R. David Murray added the comment:
If you mean "either way in the test", that's true. But what we need to test is
that the smtpd server we are providing matches the spec, which means that we
need to confirm that it does *accept* QUIT, NOOP, etc without a previous HELO.
Also
R. David Murray added the comment:
I think we're close.
You new test 'test_HELO_RSET_syntax' should be named just 'test_HELO_RSET'.
And could you please add tests for RCPT and DATA generating the 'no HELO' error?
Thanks.
--
___
Changes by R. David Murray :
--
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue14375>
___
___
Python-bugs-list mailing list
Unsubscri
R. David Murray added the comment:
I tweaked a couple more of your test method names, but otherwise used your
patch as is. Welcome to the ACKS file :)
If you haven't already submitted a contributor agreement it would be great if
you did. I'm hoping you'll want to
R. David Murray added the comment:
Contributor agreement is here:
http://python.org/psf/contrib/contrib-form-python/
ACKS file ships in every Python source tarball (not sure if goes out in the
binary ones). Here it is in the repository:
http://hg.python.org/cpython/file/default
R. David Murray added the comment:
Well, a patch won't get committed if it lacks tests, so commit would have to
wait until I have time to write some, then.
The encode_ methods (from email.encoders) take *message* objects as their
arguments. MIMEText internally converts a byte string
R. David Murray added the comment:
Oh, you are right. I even noted that bug in my PyCon talk, but immediately
forgot about it :( I do intend to fix it.
You can get it to work by explicitly passing the charset:
>>> x = MIMEText('йцукен', _charset='utf8')
&
New submission from R. David Murray :
The MIMEText class of the email package in Python3 requires that a character
set be specified in order for the resulting email to be valid. If no character
set is specified, it currently assumes ascii but puts a unicode payload in the
message. Because
R. David Murray added the comment:
Since nobody really cares about this issue :), I went ahead and applied the
patch that at least avoids the tracebacks. Someone can open a new bug about
the duplicated message if they really care.
--
resolution: -> fixed
stage: test nee
R. David Murray added the comment:
PendingDeprecationWarning would mean that we are going to remove it "someday".
If you actually want to remove them in a reasonable time, you should use
"DeprecationWarning" in 3.3, and then remove them in 3.4.
But is there a need to
R. David Murray added the comment:
Also, posting a patch for review before committing is a good idea. If you
don't get a review in a reasonable time period, then as a committer you can of
course go ahead and commit, based on your judg
R. David Murray added the comment:
Thanks for the suggestion.
It is an interesting idea, but there are some issues. attrgetter and
itemgetter can take more than one key. It would probably make more sense to
have the returned function be the one that takes the default, but in that case
R. David Murray added the comment:
email in python3 doesn't necessarily work with binary payloads. (Obviously
here you've found the opposite problem, but it is in methods that aren't used
by the package itself.) There aren't any tests of binary payloads in the test
sui
Changes by R. David Murray :
--
keywords: +needs review
stage: -> patch review
type: -> enhancement
___
Python tracker
<http://bugs.python.org/i
R. David Murray added the comment:
Thanks for the report and patch. However, in general we prefer not to mask
exceptions (doing that can hide bugs in programs). It would probably be
reasonable to fix this in pydoc, however.
Alternatively there might be a specific exception or set of
R. David Murray added the comment:
After this commit the buildbots are dying randomly with segfaults.
--
nosy: +r.david.murray
priority: normal -> release blocker
status: closed -> open
___
Python tracker
<http://bugs.python.org/i
R. David Murray added the comment:
Looking at the traceback and your code, configparser is calling 'get',
expecting to call its own get method (that takes a 'raw' keyword), but instead
is calling the get on your subclass, which doesn't take a 'raw' keyword.
R. David Murray added the comment:
Michael, I thought you might be interested in this one since it looks like it
might involve inspect executing code unexpectedly, and I know you worked on
ways of not doing that...
--
nosy: +michael.foord
Changes by R. David Murray :
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
You might want to take a look at the Decimal module.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue14
R. David Murray added the comment:
This appears to be causing buildbot failures:
http://www.python.org/dev/buildbot/all/builders/x86%20debian%20parallel%203.x/builds/4077
http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/3520
--
keywords: +buildbot
R. David Murray added the comment:
Great. I'm going to close the issue, but it's only "for now": if you get a
good response and a design agreement on python-ideas please reopen the issue.
Of course, we'd need a patch, too; and I believe there would need to be
R. David Murray added the comment:
Pretty close. I'd do the check for us_ascii first, and only do the encode
test/switch to utf-8 if that's the charset. The reason is that that if a
charset has been specified, we don't waste time doing an unnecessary encoding
(and the asci
R. David Murray added the comment:
That looks good.
--
stage: test needed -> commit review
___
Python tracker
<http://bugs.python.org/issue14380>
___
___
Py
R. David Murray added the comment:
You are theoretically right about not posting trivial patches, but as you can
see, sometimes even a trivial patch elicits unexpected insights. So I like to
always post my patches, even the seemingly trivial ones. Then if I don't get
any respons
Changes by R. David Murray :
--
assignee: -> r.david.murray
___
Python tracker
<http://bugs.python.org/issue12553>
___
___
Python-bugs-list mailing list
Un
Changes by R. David Murray :
--
assignee: -> r.david.murray
___
Python tracker
<http://bugs.python.org/issue7304>
___
___
Python-bugs-list mailing list
Un
R. David Murray added the comment:
In Python2 the fix would be to use charset unknown-8bit instead of us-ascii.
In Python3 this actually puts unicode in the message body. There we should
default to utf-8, but this requires a more extensive change than the Python2
change, and probably should
R. David Murray added the comment:
See also issue 7304. It was niggling at the back of my brain, and I finally
managed to dig it up. Fixing that is much more complex than fixing this
(because set_charset is a *very* strange method), so I committed this patch in
case we don't manage t
R. David Murray added the comment:
Better, but not stable:
http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.2/builds/984/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.2/builds/998/steps/test/logs/stdio
R. David Murray added the comment:
Please, give it a try. But also be prepared for it being harder than it looks;
the problem is that there may be very limited knowledge available where the
error is generated. (I don't know; I haven't looked at the code and am not
likely to..
R. David Murray added the comment:
@telmich: I think you will have more success at getting what you want if you
work with us rather than being confrontational. Respect that we have reasons
for doing things a certain way (and not because we are stupid), and we will
respect your perspective
R. David Murray added the comment:
I believe it was actually Guido who suggested exposing dict_proxy, in response
to Victor (but independent of Victor's needs, if I understood the message
correctly).
It has always seemed odd to me ("always" referring my time working with
Pyt
R. David Murray added the comment:
I'm marking this as easy hoping someone in the mentoring group will pick it up
and take a look. The relevant code is in Python, and I'm guessing there is
some logic bug when only the comment is set (and nothing is added to the
zipfile), but
R. David Murray added the comment:
There is no sftp module in the standard library. Presumably you are talking
about a 3rd party product and should report the bug to its developers.
If you are trying instead to report a bug in the logging module, please reopen
the issue if you can provide a
R. David Murray added the comment:
OK, so whatever else is true, it seems like there isn't anything for the python
core dev team to do here. Any action would take place at the www.python.org
level, and this bug tracker isn't where such changes are tracked, so I'm
cl
Changes by R. David Murray :
--
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue14379>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by R. David Murray :
--
nosy: -smccardell
___
Python tracker
<http://bugs.python.org/issue786827>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
The bug tracker is not a good place to get programming help. Please try the
python-tutors list, or the general python-list (see mail.python.org for a list
of mailing lists). There will be people on one of those lists with time to
help you out
R. David Murray added the comment:
Somebody (Raymond?) is going to go through and edit for style and consistency
before the release. But I applied your tweak anyway.
--
nosy: +r.david.murray
resolution: -> fixed
stage: -> committed/rejected
status: open -&g
R. David Murray added the comment:
Looks like someone else noticed the problem, but did not notice that there was
an existing issue with a patch :(.
Sorry about that, Mark. Thanks very much for working on this, and I'm very
sorry it got lost. Hopefully Eli will review your patch and s
R. David Murray added the comment:
> Limited by what?
The alphabet.
I suppose we could use a -- option, but somebody would have to add support for
those.
--
___
Python tracker
<http://bugs.python.org/issu
R. David Murray added the comment:
I must admit to being concerned by the possible impact of this change as well.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue14
R. David Murray added the comment:
LOG_SYSLOG and LOG_UUCP have been present in Python for a *long* time (since
1998 at least).
The other two are not. What fallbacks should be used if they don't exist?
(I believe you meant 'facilities', rather than 'priorities'.)
-
R. David Murray added the comment:
Looking at this again, as_string defaults to maxheaderlen=0, which means no
wrapping. In Python 3.2 you can pass it a maxheaderlen of 78 to get the
correct behavior for passing the message to smtp.
--
resolution: -> invalid
stage: -> com
R. David Murray added the comment:
Hmm. When I did the same (changed to b'...') and ran it, I got an archive
test.zip. When I then opened that archive using ZipFile, its comment attribute
was b''. Thus I concluded that the bug exists in Python3. I don't remembe
Changes by R. David Murray :
--
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5301>
___
___
Pyth
Changes by R. David Murray :
--
resolution: -> duplicate
status: open -> closed
superseder: -> test_httpservers on Debian Testing
___
Python tracker
<http://bugs.python.o
R. David Murray added the comment:
That's probably reasonable (we have precedents for that in other modules),
except that that's not how the older possibly-not-there constants work. For
backward compatibility reasons we can't change the older constants, but I don't
see
R. David Murray added the comment:
Frederico: thanks for the patch. Do you want to do the doc patches as well?
--
___
Python tracker
<http://bugs.python.org/issue14
R. David Murray added the comment:
Thanks for the patch.
The advantage of the more complicated way being that you get an immediate
TypeError instead of a delayed one? Is there any other advantage? (That's
probably enough reason, though :)
Now we just need a unit test for
R. David Murray added the comment:
Close. We either need to mention that LOG_AUTHPRIV is only defined if the
platform defines it, or we need to change the implementation so that it is
always defined (by mapping it to some other facility if it doesn't exist). I'm
of mixed mind abo
R. David Murray added the comment:
Got you. We'll definitely go with the more complete fix, then.
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
I believe there is an example in the packaging unit tests of building an
extension module in a test (but I'm not 100% sure).
Also, the fact that the test will deadlock if it fails is not a deal breaker:
the test should pass normally, and if it fail
New submission from R. David Murray :
Currently the prototype uses timeout=socket._GLOBAL_DEFAULT_TIMEOUT, and the
docs give the prototype as:
urlopen(url, data=None[, timeout], *, cafile=None, capath=None)
which is unlike most other Python function prototypes in the docs, and makes no
R. David Murray added the comment:
Thinking about this some more, I think that AUTHPRIV is special. You don't
want to inadvertently log AUTHPRIV stuff to some other facility. So I think
the code patch is good, and we should add a note to the docs that AUTHPRIV may
not exist o
R. David Murray added the comment:
>From what I understand, that defeats the purpose of AUTHPRIV, which is to log
>messages that should be logged in a "safer" location than AUTH. That's why I
>said it was a special case. In other words, if an application is going
R. David Murray added the comment:
The tests don't seem to be included in the new patch. Also, you could
modernize the property definition (@property, @comment.setter).
--
___
Python tracker
<http://bugs.python.org/is
4701 - 4800 of 12944 matches
Mail list logo
