R. David Murray added the comment:
Well, we want it to apply to python3 as well, since we want to see jython
support python3 eventually :)
Also, optparse is present in python3 for backward compatibility reasons
only...there were very few changes between the time python3 branched from
python2
R. David Murray added the comment:
Thanks, Glenn.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
Thanks.
The patch contains a number of lines that are not wrapped to <80, which is one
of our requirements. It would be great to get that fixed. (In the
documentation, you can use \ to wrap the prototype line.)
There is non-ascii in one place in
R. David Murray added the comment:
The precedent has already been set by the 'cleandoc' function, I think. This
one seems to go right along with that one.
--
___
Python tracker
<http://bugs.python.o
Changes by R. David Murray :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue1650090>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by R. David Murray :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11316>
___
___
Python-bugs-list mailing list
Unsubscrib
R. David Murray added the comment:
This will be fixed as part of issue 15014, which also adds support for
providing user created auth methods.
--
resolution: -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder: -> smtplib: add support f
Changes by R. David Murray :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue18099>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by R. David Murray :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue18099>
___
___
Python-bugs-list mailing list
Unsubscrib
R. David Murray added the comment:
Thanks, Rafael.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
Well, perhaps inspect needs a get_doc_synopsis method :)
Actually, I'm not sure that should be a smiley.
I don't really have a strong opinion on this myself (say I'm +0 for inspect),
so I asked a couple other core devs here at the sprint (Eric
R. David Murray added the comment:
As far as I can tell from the messages, there is nothing left to do here, so
I'm closing it.
--
nosy: +r.david.murray
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Changes by R. David Murray :
--
resolution: -> works for me
stage: -> committed/rejected
status: open -> pending
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
Thanks, Sam.
--
nosy: +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:
The patch looks good. I'd like the comment to say "We use urlsafe_b64decode
here because some mailers apparently use the urlsafe b64 alphabet, and
urlsafe_b64decode will correctly decode both the urlsafe and regular alphabets".
Also, the ne
R. David Murray added the comment:
There is no file 'email.py' in the Python standard library. You must have such
a file in your python path somewhere, so when you import email it actually
imports that file instead of the email package. You will note that 'email.py'
i
R. David Murray added the comment:
OK, it is great having a test that makes this at least mostly reproducible :)
Having reloaded my brain on this thing, I'm thinking that the best solution may
be indeed to switch to ordered dicts. If we then reorder the hardcoded lists
to be in "
New submission from R. David Murray:
>>> help(ImportError.__init__)
Help on wrapper_descriptor:
__init__(self, /, *args, **kwargs)
Initialize self. See help(type(self)) for accurate signature.
The above also appears (without the wrapper_descriptor bit) in the help ou
R. David Murray added the comment:
Well, it's 'expected' behavior in the sense that we don't know about 'adobe'
format. Is there some better way to detect jpeg format than to look for
particular format identifiers in a specific byte position?
--
type: en
Changes by R. David Murray :
--
title: Backport hashlib.pbkdf2_hmac to Python 2.7 -> PEP 446: Backport
hashlib.pbkdf2_hmac to Python 2.7
___
Python tracker
<http://bugs.python.org/issu
R. David Murray added the comment:
Thanks, Glenn. I tweaked the wording further. If someone thinks it is worth
the effort to backport this to 2.7, they can do so and reopen the issue.
--
assignee: eric.araujo ->
nosy: +r.david.murray
resolution: -> fixed
stage: needs
R. David Murray added the comment:
The change covered by the patch (which patch rejected as garbage, by the way, I
have no idea why) has already been applied by Serhiy Storchaka, apparently as a
blanked change of 'empty string' to 'empty bytes object'.
There are several
Changes by R. David Murray :
--
Removed message: http://bugs.python.org/msg216880
___
Python tracker
<http://bugs.python.org/issue4744>
___
___
Python-bugs-list m
R. David Murray added the comment:
The change covered by the patch (which patch rejected as garbage, by the way, I
have no idea why) has already been applied by Serhiy Storchaka, apparently as a
blanket change of 'empty string' to 'empty bytes object'.
There are several
R. David Murray added the comment:
The magic of newline='' in python3 is that it *preserves* the line end
characters, which is the same thing binary mode does on windows. The place
that matters, as I remember it, is when there is a newline embedded inside a
quoted string. I don&
Changes by R. David Murray :
--
components: +email
nosy: +barry, r.david.murray
___
Python tracker
<http://bugs.python.org/issue21296>
___
___
Python-bugs-list m
R. David Murray added the comment:
Can you confirm that this is really still a problem, despite the Solaris
cleanup in issue 1759169?
--
___
Python tracker
<http://bugs.python.org/issue837
R. David Murray added the comment:
Thanks, amathew and Marek.
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by R. David Murray :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue21221>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
Yes, after thinking about this this weekend, it is clear to me that in the
future we will *need* a scheme where by the NEWS entry can be safely included
in the patch in some form.
I think the commit message is also going to be in the patch, which will be in
R. David Murray added the comment:
In order for things to work with a patch gating system, I believe it will be
the most practical for the news items to be each in a separate file.
--
___
Python tracker
<http://bugs.python.org/issue18
R. David Murray added the comment:
2.7 can't be changed for backward compatibility reasons, and python3 enforces
the restriction in dict, as you observe.
I don't know if a python2 documentation note is worthwhile, but given the
conversations at pycon about adding additional -3 warni
R. David Murray added the comment:
Hmm. It seems to me that .name not being set is a bug in importlib. It
appears that importlib doesn't set it in the 'from x import y' case. After a
bit of experimenting at the python prompt, I'm not even sure what that code in
runpy i
R. David Murray added the comment:
It should receive a string. This is parallel to cleandoc, and I think splitdoc
should go in the documentation right after cleandoc.
--
___
Python tracker
<http://bugs.python.org/issue12
R. David Murray added the comment:
Thanks, Sam. It is more helpful if the NEWS entry is *not* put in the patch
given the current state of the tooling. What's needs to be added is an entry
in Doc/whatsnew/3.5.
For the new test, you can take advantage of the temp_dir and
EnvironmentVar
R. David Murray added the comment:
That would probably work for now, but it wouldn't work for the patch gating
system. On the other hand, it would sure make it easier to build/check
whatsnew.
--
___
Python tracker
<http://bugs.py
R. David Murray added the comment:
That makes the tooling of the gating system harder, though. If the NEWS can
just be a file in the patch, we don't have to have any special tooling for it
in the gating system.
--
___
Python tracker
R. David Murray added the comment:
Yeah, Guido was strongly in favor of that too.
--
___
Python tracker
<http://bugs.python.org/issue18967>
___
___
Python-bug
R. David Murray added the comment:
Looks good to me.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue21225>
___
___
Python-bugs-list m
R. David Murray added the comment:
That section of the docs is indeed rather confusing. Probably it just needs to
be changed to say "for the methods supported by this object, see HTTPResponse
Objects.
I'd like to see the docs reorganized so that the '.. class' declara
R. David Murray added the comment:
No. x.encode('unicode-escape').decode('unicode-escape') should return the same
result, and it does.
The bug, I think, is that bytes.decode('unicode-escape') is not objecting to
the non-ascii characters. It appears to be tre
R. David Murray added the comment:
Someone has to find the time to do a commit review on the patch. As Guilherme
said, there's no specific maintainer for wave, so I'm afraid it just got
forgotten about. On the other hand, as a new feature it would now go in 3.5,
and we're
R. David Murray added the comment:
Using unicode_escape to decode non-ascii is simply wrong. It can't work.
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
To understand why, understand that a byte string has no encoding inherent. So
when you call b'utf8string'.decode('unicode_escape'), python has no way to know
how to interpret the non-ascii characters in that bytestring. If you want
R. David Murray added the comment:
Also, I'm not sure what this should do, but what it does do doesn't look right:
>>> codecs.decode('ä', 'unicode-escape')
'ä'
--
___
P
Changes by R. David Murray :
--
components: +email
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue12489>
___
___
Python-bugs-list mailing list
Unsub
R. David Murray added the comment:
Thanks, Akira.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
I'm not going to reopen it, but my point was that if we really are going to add
additional -3 warnings to help people port 2.7, as discussed at the language
summit, then this would be a candidate.
--
___
P
R. David Murray added the comment:
Works fine for me.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue21398>
___
___
Python-bugs-list m
R. David Murray added the comment:
Like I said, the compatibility claims are almost certainly incorrect.
--
___
Python tracker
<http://bugs.python.org/issue20
R. David Murray added the comment:
Ah, yes, my lc_ctype was en_US.utf-8. I can reproduce it if I change that.
--
___
Python tracker
<http://bugs.python.org/issue21
R. David Murray added the comment:
This is why we should have had named constants and not Enums :)
But no, nothing in the python Enum implementation restricts it to a value
*range*. It is really a collection of named constants.
--
nosy: +r.david.murray
R. David Murray added the comment:
I don't think it's a bug. The subclass-goes-first behavior is very
intentional. The implicit __ne__ returning the boolean inverse of __eq__ is
what fooled me when I looked at it.
Or did you mean that following the subclass rule in the case where
R. David Murray added the comment:
Oh, I see. Yes, that would seem more consistent.
--
___
Python tracker
<http://bugs.python.org/issue21408>
___
___
Python-bug
R. David Murray added the comment:
Since you say the bug is fixed, what do you intend the purpose of this issue to
be?
--
___
Python tracker
<http://bugs.python.org/issue21
R. David Murray added the comment:
Oh, I missed the fact that you had closed it.
--
___
Python tracker
<http://bugs.python.org/issue21267>
___
___
Python-bug
R. David Murray added the comment:
The precisionist in me isn't quite happy, but any wording I've come up with to
make it more precise isn't as informative :) (The 'real' situation is that the
return value of the function is determined by the last return statement
e
R. David Murray added the comment:
I would remove the parenthetical (it was so stated in immediately preceding
paragraph and thus is redundant), and instead of "win", I would say "will
always be the last one executed".
--
___
P
R. David Murray added the comment:
There's no pressing reason to revisit this, but...I think it would be better to
say "works only on systems that support devpoll (ie: Solaris and derivatives)"
Also, as long as you are changing the try/except, you could use
skipUnless
R. David Murray added the comment:
While this is classed as a CPython implementation detail (see issue 15718) it
doesn't sound like it is likely to be changed (see issue 2723).
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.py
R. David Murray added the comment:
Well, it would be 3.5, so there's plenty of time yet. We are hoping for an
answer from Tim Peters, but if we don't get one someone else will review it as
time allows. Pinging the issue like this was good; do it again in another
month if there
R. David Murray added the comment:
Mark: I thought it was too, but the two I noted were the closest I could find.
Maybe you'll find something even more on point :)
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
Note that there has never been a strict correspondence between
linecache/getsource, the module in memory, and the code on disk. If the file
is changed before a traceback is generated, for example, you will get the new
source. That doesn't mean fixin
R. David Murray added the comment:
Can you provide more details on how to reproduce the problem, please? For
example, a sample message and the sequence of python calls you use to parse it.
--
___
Python tracker
<http://bugs.python.org/issue21
R. David Murray added the comment:
We'll need the data file as well. This is going to be a data-dependent issue.
With a 12MB body, I'm guessing there's some decoding pathology involved, which
may or may not have been already fixed in python3.
To confirm this you could u
R. David Murray added the comment:
Sorry, I was using RFC-speak. A message is divided into 'headers' and 'body',
and all of the attachments are part of the body in RFC terms. But think of it
as 'initial headers' and 'everything else'. Please eithe
R. David Murray added the comment:
Also to clarify: HeaderParser will *also* read the entire message, it just
won't look for MIME attachments in the 'everything else', it will just treat
the 'everything else' as arbitrary data and record it as the payload of the
Changes by R. David Murray :
--
components: +email
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue21300>
___
___
Python-bugs-list mailing list
Unsub
R. David Murray added the comment:
Thanks for the heads up.
policy.default will become the default policy eventually, but first the new
stuff has to get out of provisional status (which I expect will happen in 3.5).
I did a pass over the documentation of all of the policy arguments and
R. David Murray added the comment:
An implicit ceiling of 4000 seconds on the timeout? I routinely use timeouts
of approximately 24 hours in calls to Event().wait(). What am I
misunderstanding? If I'm not misunderstanding, then no, I don't think that
change would be
R. David Murray added the comment:
I have production code on Windows using python2.7 that calls Event().wait()
with a timeout of approximately 24 hours, and it works just fine. Having that
no longer work is, IMO, an unacceptable regression. (I'm ready to move this
code to python3 as so
R. David Murray added the comment:
Python 3.4.0+ (3.4:d994d75cce95, May 6 2014, 21:37:02)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> json.load
R. David Murray added the comment:
Hmm. I guess I don't have any objection in principle. It is hard to imagine
why someone would depend on the exact format of the old low-information
messages, though anything is possible.
--
___
Python tr
R. David Murray added the comment:
Take a look at the source for msg_16.txt. The last part is a message/rfc822,
which encapsulates a text/plain message. So it *does* iterate over it, even
though it isn't a 'multipart' type (the opposite of what you say in the doc
patc
R. David Murray added the comment:
Using _structure is a great idea. I'm not so fond of the full example, but
I'll have to contemplate the text to decide what I'd rather do. Probably I'll
take this patch of yours and tweak it, rather than try to tell you what I want
:)
R. David Murray added the comment:
Yes, that would be great.
--
___
Python tracker
<http://bugs.python.org/issue21083>
___
___
Python-bugs-list mailing list
Unsub
R. David Murray added the comment:
I'm adding Mark Dickinson to nosy to see if our math expert has a comment on
the arithmetic :)
--
nosy: +mark.dickinson
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
Looks pretty good.
The docs should say that the value of header is returned, and should also
mentioned that the value is lower cased. You should also add a 'versionadded'
directive, and for bonus points an entry in the whatsnew document for 3.5.
R. David Murray added the comment:
Looks good, thanks.
--
___
Python tracker
<http://bugs.python.org/issue21083>
___
___
Python-bugs-list mailing list
Unsub
R. David Murray added the comment:
That was actually copy and paste of an existing typo, which I've also now
fixed. Thanks.
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
Francisco: I'd say that was a good idea. Would you like to propose a patch?
(ie: figure out where it should go)
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
Arfrever's advice was misleading...the test would have needed to be
assertIsNot(True << 0, 1), but the fact that True is not preserved is not
really what we want to test. What we want to test is that the return value is
of type 'int', w
R. David Murray added the comment:
Arfrever pointed out on irc that I misread. It would indeed be assertIs(True
<< 0, 1), but that wouldn't make a good test because the fact that '1 is 1' is
an implementation detail of CPython and
R. David Murray added the comment:
It doesn't really matter what order you do it in (though I prefer to write
tests first, usually), but yes, we will want tests before we commit the fix.
I tried to be thorough in my testing, but obviously I missed some bra
R. David Murray added the comment:
The error is actually the first case returning string rather than bytes. See
issue 6302.
--
dependencies: +Add decode_header_as_string method to email.utils
resolution: -> duplicate
stage: -> resolved
status: open -&g
R. David Murray added the comment:
Hmm. It looks like we decided that we couldn't fix the behavior for backward
compatibility reasons. In 3.4 you can use the new email policies to get
automatic, correct stringification of headers.
--
___
P
R. David Murray added the comment:
The data structure you are asking for bears a resemblance to the data structure
used by the email package to record message headers. Email uses a list with a
dict-like API cobbled together on top. The difference with your suggestion is
that email also
Changes by R. David Murray :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue21338>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
As a historical note, the docs are probably correct...but at some point
relatively recently we fixed the inconsistency in what was raised in the thread
and threading modules, but obviously no one noticed that multiprocessing had
the same issue. It could be
R. David Murray added the comment:
I'm not that familiar with multiprocessing, but I'd guess it was to avoid
burning cpu in a busy-wait (it seems to me that that doesn't matter during
finalization, but does during normal running). Maybe it could be changed to an
event wai
R. David Murray added the comment:
Thanks, Akira.
--
nosy: +r.david.murray
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
I wonder if changing this would break any working programs. I'd like to think
not, but it is certainly possible for someone to be actually depending this bug.
--
components: +email
nosy: +akuchling, barry, r.david.m
R. David Murray added the comment:
I think detach is the correct way to to this, so I'm closing the issue.
--
nosy: +r.david.murray
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http:
R. David Murray added the comment:
The issue of (mixed) string and binary input/output on the standard streams is
still a bit of a work in progress, I think, both documentation wise and code
wise. So I'm not sure we know yet what the best practice is to recommend here.
I think I agree
R. David Murray added the comment:
Note that in 3.4 we have contextlib.replace_stdout, but it doesn't give any
examples of how to construct file-like objects that will work well with it.
--
___
Python tracker
<http://bugs.python.org/is
R. David Murray added the comment:
I mean redirect_stdout.
--
___
Python tracker
<http://bugs.python.org/issue21364>
___
___
Python-bugs-list mailing list
Unsub
Changes by R. David Murray :
--
versions: +Python 3.5 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue634412>
___
___
Python-bugs-list mailin
R. David Murray added the comment:
There is some support for this in the new email policies. Take a look at the
new examples in the 3.4 email documentation in particular.
The additional thing I would like to see is support in the content manager that
recognizes multipart/related and makes it
R. David Murray added the comment:
We should resolve issue 18022 before we decide how to "fix" this.
--
dependencies: +Inconsistency between quopri.decodestring() and
email.quoprimime.decode()
___
Python tracker
<http://bugs.python.o
R. David Murray added the comment:
Thanks. It's very clear. What isn't clear is if the line should be made to
work as apparently intended, or removed :) (My guess at this point without
re-reading the RFCs is that it should
5001 - 5100 of 10554 matches
Mail list logo