R. David Murray added the comment:
Um. I'm inclined to think that #13637 was a mistake.
Functions that accept bytes and return bytes and also accept string and return
string seem uncontroversial. However, accepting bytes or string and returning
bytes is not an obviously good idea, an
R. David Murray added the comment:
OK, I skimmed the thread I was remembering, and while it was discussing
str->str and bytes->bytes primarily, the only pronouncement I could find was
that functions should not accept a *mix* of bytes and string. So I guess I
withdraw my objection, al
R. David Murray added the comment:
Did you upload urlparse.py to the issue by accident?
Can you please provide some examples of where you think the current code is
producing incorrect results?
--
nosy: +r.david.murray
___
Python tracker
<h
R. David Murray added the comment:
It's not a patch if it is the whole file. A diff would be much more useful,
since then we could see the changes easily.
This kind of change would require a bit of discussion. I'm doubtful that it
would be applied as a bug fix, and we might eve
R. David Murray added the comment:
OK' I'm back to being 100% on the side of rejecting both of these changes.
ASCII is not unocode, it is bytes. You can decode it to unicode but it is not
unicode. Those transformations operate bytes to bytes, not bytes to unicode.
We made
R. David Murray added the comment:
Non-ascii binary data should not be being rejected unless validate
is true. So what are you going to do with non-ascii-range unicode in
that case? Ignore it as well? That can't be right.
I believe this should be discussed on pytho
R. David Murray added the comment:
I disagree with this commit. Reopening pending discussion on python-dev.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issu
R. David Murray added the comment:
I disagree with this feature. Reopening pending discussion on python-dev.
--
nosy: +r.david.murray
status: closed -> open
___
Python tracker
<http://bugs.python.org/issu
R. David Murray added the comment:
Discussion resolved in favor of patch.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Changes by R. David Murray :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13641>
___
___
Python-bugs-list mailing list
Unsubscri
R. David Murray added the comment:
Is it totally insane to think about using a float subclass with an additional
attribute instead of a tuple?
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue14
R. David Murray added the comment:
You'll have to give more details about what you are doing, but I suspect you
are in fact calling it incorrectly. In addition, there are pretty much no
circumstances in which you want to use string.rfind in 2.7. Just use ''.rfind.
R. David Murray added the comment:
Ah, perhaps you *meant* you are calling rfind on a string, rather than calling
rfind on the 'string' module as I imagined.
So, we definitely need more details about how you are producing this failure
and what the traceback looks like.
R. David Murray added the comment:
Why not just call the helper in setUp? Otherwise, it looks good to me.
This is a bug fix and should be backported, I believe.
--
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.
R. David Murray added the comment:
Unless I'm misunderstanding, this is a duplicate of issue 1602.
You will note that the problem is *not* with Python (or open source software in
general), the problem is that Microsoft treats the command line as a second (or
third, or fourth) class ci
R. David Murray added the comment:
OK, so I still don't understand what problem it is you are reporting. What do
you mean by "can't craete non-valid strings"? Of course you can't. (I don't
see how you could do that programatically, either, although that depen
R. David Murray added the comment:
I'm changing the title since PEP 414 has no bearing here.
--
title: Fix unicode literals (for PEP 414) -> Fix unicode literals
___
Python tracker
<http://bugs.python.org
R. David Murray added the comment:
Since this bug is about adding a new feature, it is unlikely to be the correct
bug for this to be against.
Given that you've identified a regression, I suggest you open a new bug with a
reproducer, and we'll set it to relea
R. David Murray added the comment:
Marking as release blocker since this is a regression. Added people from the
other curses issue as being likely to be interested in this one.
--
nosy: +cben, gpolo, haypo, inigoserna, jcea, phep, pitrou, python-dev,
r.david.murray, schodet, zeha
R. David Murray added the comment:
I agree with Eric. I've run in to this error, and immediatly figured out what
I'd done wrong based on the existing error message.
--
nosy: +r.david.murray
resolution: -> invalid
stage: -> committed/rejected
status
R. David Murray added the comment:
To answer Glenn's procedural question: no this is not a bug whose fix can be
backported. API changes are not allowed in maintenance releases. Doc
improvements can be backported, though, so I'm leaving versios alone
(alternatively someone could
R. David Murray added the comment:
32 is re.U, which is always ored with the passed in flags, unless re.A is set
in the passed in flags. The flag docs should certinaly be updated to reflect
this.
--
nosy: +r.david.murray
stage: -> needs patch
versions: +Python
R. David Murray added the comment:
Yes, cleanups would be better as a separate issue.
--
___
Python tracker
<http://bugs.python.org/issue8739>
___
___
Python-bug
R. David Murray added the comment:
Juhana: thanks for the patch. I see an issue with it, though. What if the
email address is something like john.si...@example.com?
My thought is that there are two ways to handle this. Either we do a full RFC
address parse in __getaddr and have it return
R. David Murray added the comment:
OK, reopening. I've added 3.2 and 3.3 as I imagine the same problem will exist
there.
Now we need someone to propose a patch to fix it.
--
resolution: out of date ->
stage: test needed -> needs patch
status: closed -> open
version
R. David Murray added the comment:
+10 :)
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue14265>
___
___
Python-bugs-list mailin
R. David Murray added the comment:
I think it should use the same default as open, but frankly I couldn't remember
the right way to achieve that. Suggestions welcome :)
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/i
R. David Murray added the comment:
I committed Tatiana's patch because it looks reasonable to me, but I'm not
familiar enough with zipimport to know if additional tests are needed. If you
think there are additional tests that should be added, please reopen the issue.
-
R. David Murray added the comment:
Duh. I should have remembered that the io module used None to represent the
default encoding. Thanks, Éric.
--
___
Python tracker
<http://bugs.python.org/issue5
R. David Murray added the comment:
Heh. Good point.
Documenting this is a clear way may be non-trivial.
--
___
Python tracker
<http://bugs.python.org/issue14
R. David Murray added the comment:
It doesn't look like it. Is that the right issue number?
--
___
Python tracker
<http://bugs.python.org/issue14250>
___
___
R. David Murray added the comment:
For 3.2 could we use the same fix, but without exposing the ability to *change*
the encoding? That is, we use TextIOWrapper but always with the default None
for encoding.
It also occurs to me that this really exposes a weakness in the design. What
if the
R. David Murray added the comment:
It also occurs to me that this fix makes the charset hook look rather odd. We
could render it redundant by passing charset to open in the non-openhook case,
and mark it deprecated.
There is also a bug in the hook_encoding docs. It says the file is opened
New submission from R. David Murray :
In Python2, this works:
>>> from email.mime.text import MIMEText
>>> m = MIMEText('abc')
>>> str(m)
'From nobody Tue Mar 13 15:44:59 2012\nContent-Type: text/plain;
charset="us-ascii"\n
R. David Murray added the comment:
It makes no sense that changing how Subject is generated would affect the later
formatting of the mime header. There is no coupling that I'm aware of in the
code.
I notice that your handcrafted version uses uppercase for the charset and CTE
code. Ca
R. David Murray added the comment:
Thanks, Brian.
(For the record, this is a bug in email6 code that hasn't been checked into
trunk yet.)
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
I fixed this for test_email by adding automatic unit test discovery to
test_email.__init__.
I believe it should be possible for a similar thing to do be done for
test_importlib.
--
nosy: +r.david.murray
Changes by R. David Murray :
--
nosy: +eric.smith
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue14297>
___
___
Python-bug
R. David Murray added the comment:
We could also just decide we don't need it :)
If we do (I haven't read the PEP) does a statement with an assignment make the
variable global in that scope, or does it only affect the global variable for
the duration of the assignment, and oth
R. David Murray added the comment:
Fix committed. Thanks Ali.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
I think the next thing to do would be to replace the call to send_message with
code that calls BytesGenerator to write the message out to disk, and diff the
output of the two versions (normal subject and hand-encoded subject). Maybe
that will give us a
R. David Murray added the comment:
I'm pretty sure Michael is talking about unittest. Doing the same for regrtest
would be interesting but not as important. (When I run individual tests from
the Python test suite I generally use -m unittest to
R. David Murray added the comment:
OK, got it. When I created BytesParser I turned the 'NL' constant into a class
attribute, but in the line that handles Header objects in BytesParser I failed
to change NL to self._NL. So when send_message calls flatten with
linesep='\r\
R. David Murray added the comment:
Thanks for the bug report. I thought we had tests for processing Header
objects when serializing a message using BytesParser, but clearly we didn't.
And thanks Tatiana and Martin for issue review and testing.
--
resolution: -> fixed
stat
Changes by R. David Murray :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
By the way, Alberto, if you haven't already submitted a contributor agreement,
could you do so please? We have one from Dan from the sprints. Michele, you
aren't marked in the tracker as having submitted an agreement but you've been
activ
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
2401 - 2500 of 10554 matches
Mail list logo
