Changes by R. David Murray :
--
versions: -Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/issue14590>
___
___
Python-bugs-list mailin
R. David Murray added the comment:
There wouldn't be serious backward incompatibility. Truncate(0) would still
mean the same thing as truncate(size=0). I don't remember if we treat
supporting the keyword form when it is doced that as a bug or not, though, so
you might be rig
Changes by R. David Murray :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue14588>
___
___
Python-bugs-list mailing list
Unsubscri
R. David Murray added the comment:
Something seems to have gone wrong with the 'reply' form. Sorry about that.
Please use the URL instead.
--
nosy: +r.david.murray
resolution: -> invalid
stage: -> committed/rejected
status
R. David Murray added the comment:
Hmm. The account *looks* normal, and has your email address attached. Can you
log in using the password you chose?
--
___
Python tracker
<http://bugs.python.org/issue14
R. David Murray added the comment:
As long as you are good with a registered account, that's what's important. If
I get time I'll take a deeper look, but most likely I won't unless this happens
again.
--
___
P
Changes by R. David Murray :
--
nosy: +brett.cannon
___
Python tracker
<http://bugs.python.org/issue14592>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
This is essentially a duplicate of issue 14551, but perhaps with a bit more
weight behind it.
--
nosy: +brett.cannon, pitrou, r.david.murray
versions: -Python 2.6, Python 2.7, Python 3.1
___
Python tracker
<h
R. David Murray added the comment:
In general it is difficult to impossible to get Python2 to unload modules
before the interpreter shuts down. See issue 9072. I'm not savvy enough with
the C stuff to know if the fact that you loaded it via ctypes changes anything,
but I doubt it.
R. David Murray added the comment:
Yeah, they really need to be documented in order for us to document them as
deprecated if we decide we really want to remove them later. "Obsolete" is
not, I think, the same as "deprecated".
--
__
R. David Murray added the comment:
This appears to be failing on the buildbots:
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/3358/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/2037/steps/test/logs
R. David Murray added the comment:
The one-liner is "good enough", but...
The use case is indeed loading a module from an arbitrary file without having
to worry about sys.path, etc. For that load_source is intuitive. The
one-liner is an adequate substitute, but feels like a ste
R. David Murray added the comment:
Current default will become 3.3. 3.1 has been out for a while :)
Your thought sounds reasonable, though Martin may have further input.
Would you are to propose a patch? Otherwise most like nothing will happen with
this issue. 3.3 Beta is scheduled for
New submission from R. David Murray :
Not sure which revision triggered this, so opening a new bug:
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6381/steps/test/logs/stdio
There's also a test_reprlib failure, no idea if it is related.
--
keywords: bui
R. David Murray added the comment:
Well, if you want backward compatibility, you pretty much have to keep it as
is, don't you?
This is the only time I've used load_source, and it was used because we didn't
want to bother mucking with the path but did want to load the mo
R. David Murray added the comment:
I think you misunderstand the way that python arguments work. If you have a
function so:
def func(size=None):
Then func(0) and func(size=0) are equivalent, and func(0, size=0) is a
TypeError because you've provided two arguments instead of jus
R. David Murray added the comment:
Ah, I'm glad someone else chimed in. I was going to say that I was pretty sure
we had a macro for doing this, but I don't do much C level coding so I didn't
have a reference handy.
--
___
Python
R. David Murray added the comment:
macro, function...something automated, anyway :)
--
___
Python tracker
<http://bugs.python.org/issue14586>
___
___
Python-bug
R. David Murray added the comment:
Can you demonstrate the parsing error? maxlen should have no effect during
parsing.
--
___
Python tracker
<https://bugs.python.org/issue36
R. David Murray added the comment:
As for the other, I don't see the need for a custom error. It's a ValueError
in my view. I wouldn't object to it strongly, but note that this error is
content dependent. If there's nothing to encode, you can "get away with"
R. David Murray added the comment:
Good point about the backward compatibility. Yes I agree, I think raising the
error is probably better. A deprecation warning seems like a good path
forward...I will be very surprised if anyone encounters it, though
R. David Murray added the comment:
Right, one of the fundamental principles of the email library is that when
parsing input we do not ever raise an error. We may note defects, but whatever
we get we *must* parse and turn in to *something
R. David Murray added the comment:
A cleaner/safer solution here would be:
tok, *remainder = _wsp_splitter(value, 1)
if _rfc2047_matcher(tok):
tok, *remainder = value.partition('=?')
where _rfc2047_matcher would be a regex that matches a correctly formatted
en
R. David Murray added the comment:
I don't see that line of code in unstructured_ew_without_whitespace.diff.
Oh, you are referring to his monkey patch. Yes, that is not a suitable
solution for anyone but him, and I don't think he meant to imply
R. David Murray added the comment:
New changeset feac6cd7753425fba006e97e2d9b74a0c0c75894 by R. David Murray
(Abhilash Raj) in branch 'master':
bpo-33524: Fix the folding of email header when max_line_length is 0 or None
(#13391)
https://github.com/python/cpyt
R. David Murray added the comment:
New changeset ef5bb25e2d6147cd44be9c9b166525fb30485be0 by R. David Murray
(Batuhan Taşkaya) in branch 'master':
bpo-27737: Allow whitespace only headers encoding (#13478)
https://github.com/python/cpython/commit/ef5bb25e2d6147cd44be9c9b166525
R. David Murray added the comment:
Thanks.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.or
R. David Murray added the comment:
Can you demonstrate the problem with an actual email object?
header_store_parse is not meant to be called directly.
--
___
Python tracker
<https://bugs.python.org/issue36
R. David Murray added the comment:
Nevermind, I was testing with the wrong version of python. This bug was
introduced somewhere after 3.4 :(
>>> from email.message import EmailMessage
>>> m = EmailMessage()
>>> m['Subject'] = 'Hello Wörld! H
R. David Murray added the comment:
New changeset 0416d6f05a96e0f1b3751aa97abfffe6d3323976 by R. David Murray (Miss
Islington (bot)) in branch '3.7':
bpo-27737: Allow whitespace only headers encoding (GH-13478) (#13517)
https://github.com/python/cpyt
R. David Murray added the comment:
"But - what are we solving for here?" I'll tell you what my fairly common use
case is. Suppose I have some test infrastructure code, and I want to make some
assertions in it. What I invariably end up doing is passing 'self'
R. David Murray added the comment:
The fact that the original report mentions HeaderParserError implies that the
new API is being used, though the report didn't make that clear. The problem
still exists:
>>> m = message_from_string("To: :Foo
>>> \n\n
R. David Murray added the comment:
BareQuotedString implies the new API is being used, though that was not made
clear in the report. However, unlike the other recently closed issue, this one
was in fact fixed (and I have a vague memory of reviewing the PR):
>>> m = message_fr
R. David Murray added the comment:
Note that the reporter indicated that the message was an instance of
EmailMessage (the new API). You'd need to use policy-default to get that using
message_from_string. But yes, this was fixed in another issue.
--
stage: patch review ->
R. David Murray added the comment:
This problem is the whole reason "mangle_from" exists in the email library...
--
___
Python tracker
<https://bugs.python.o
R. David Murray added the comment:
FYI, it would have been most helpful if you had posted your example in the
issue text instead of as an attached file, as it explains the problem better
than your text does :)
Here is a minimal reproducer:
>>> m = EmailMessage(policy=strict)
&g
R. David Murray added the comment:
The display name is a phrase, and a phrase is a sequence of words, and a word
is either a quoted string or an atom. So it is legal to mix quoted strings and
encoded words in a display name. I'd vote to do whichever one is easier to
implement :
R. David Murray added the comment:
Right, those absolutely are valid addresses. A resolver will normally look up
a name with an internal dot first as if it were an FQDN, but if it does so and
does not get an answer it will then look it up again as a "local" address
(appending i
Change by R. David Murray :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
R. David Murray added the comment:
The input header is not valid (non-ascii is not allowed in headers), so you
shouldn't expect make_header to do anything sensible. Note that this is the
legacy API, which is a toolkit and does not hold your hand when it comes to RFC
compliance. Aside
R. David Murray added the comment:
Right, and the python email package fully supports non ascii:
>>> msg = EmailMessage()
>>> msg['Subject'] = "Panamá- Casco Antiguo"
>>> bytes(msg)
b'Subject: =?utf-8?q?Panam=C3=A1-?= Casco Antiguo\n\n'
R. David Murray added the comment:
New changeset b9c3da5c89c66dcccf382e8f196746da2a06d4cc by R. David Murray
(Sanyam Khurana) in branch 'master':
bpo-24744: Raises error in pkgutil.walk_packages if path is str (#1926)
https://github.com/python/cpyt
R. David Murray added the comment:
Thanks, Sanyam.
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
R. David Murray added the comment:
Since according to Eryk there's no way to have a reliable cross-platform
exception class catching file name to long, I'm rejecting this feature request.
--
resolution: -> rejected
stage: -> resolved
status
R. David Murray added the comment:
It's not obvious from your discussion, Nick, *why* venv won't use an upgraded
system pip if it has been manually upgraded. There's no need for internet
access in that case (which is the argument for using the bundled pip when
running ensurepi
Changes by R. David Murray :
--
nosy: +brett.cannon, eric.snow, ncoghlan, r.david.murray
___
Python tracker
<http://bugs.python.org/issue30645>
___
___
Python-bug
Changes by R. David Murray :
--
resolution: not a bug -> third party
___
Python tracker
<http://bugs.python.org/issue30655>
___
___
Python-bugs-list mai
R. David Murray added the comment:
OK, so the key here is venv's dependency on a pip wheel. That makes sense, but
is certainly counterintuitive. One would naively think that having a copy of
PIP installed would make it easy to link that into the venv, but obviously it
is a lot more co
R. David Murray added the comment:
Yes, that's all you needed to do. She updated your status in the tracker (you
now have the CLA signed '*' next to your name).
--
___
Python tracker
<http://bugs.pyt
R. David Murray added the comment:
We don't generally document all exceptions that a method can raise, only those
that are relevant to its specific API. In this case, documenting the exception
answers the question, "what happens if the directory already exists?" This
question
R. David Murray added the comment:
This seems sensible to me (I haven't looked at the PR, I'm talking about adding
the support). When textwrap was written python was pretty ascii oriented, so
it is not too much of a surprise that unicode em dashes were not supported.
-
R. David Murray added the comment:
The problem is that if it returns None on parse failure, then you can't tell
the difference between the header not existing and the date not being
parseable. I don't have a solution for this problem. Suggestions welcome.
(Note that this is only
R. David Murray added the comment:
This appears to be a duplicate of issue 29097.
--
nosy: +r.david.murray
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> datetime.fromtimestamp(t) when 0 <= t <= 86399 fa
R. David Murray added the comment:
OK, I think I've reloaded my brain at least partially on this topic.
I think my original reason for having prasedate_to_datetime raise errors is
that it was my opinion that that is the way it should work, and that parsedate
should work the same way (
R. David Murray added the comment:
I'll make one argument in favor of retaining the exception, and if that doesn't
fly then I agree to the solution and will try to review the PR soon.
The argument is this: if parsedate_to_datetime raises an error, you get
information about *why* th
R. David Murray added the comment:
Yep, you found an edge case I didn't write a test for. The defect should get
added to the header object during parsing. (Those are supposed to get copied
to the message object...)
--
___
Python tracker
R. David Murray added the comment:
IMO, it would actually be surprising for ChainMap to support unhashable keys.
In Python, as Raymond indicates, "mapping" is pretty much synonymous with
'dict-like', and it would be where that was *not* true that we might add
R. David Murray added the comment:
This isn't the place to get help on Python coding, but since this is a
relatively new API I'll give you a pointer, and then you can tell me where the
docs need improvement :)
If you do message_from_string(yourstring, policy=email.policy.default), y
R. David Murray added the comment:
On the PR Berker wrote:
I'm wondering if we should still advertise the use of set([...]). We
replaced all instances of it with set literals in the stdlib.
set([...]) is part of the language, and the python documentation is also a
specification o
R. David Murray added the comment:
Just as well. I had no time last weekend. I should have time this Sunday,
though.
--
___
Python tracker
<http://bugs.python.org/issue30
R. David Murray added the comment:
New changeset b350c22ebcbb891412e0b334afc9f0db19534e06 by R. David Murray (Joel
Hillacre) in branch 'master':
bpo-30532: Fix whitespace folding in certain cases
https://github.com/python/cpython/commit/b350c22ebcbb891412e0b334afc9f0
Changes by R. David Murray :
--
stage: -> backport needed
___
Python tracker
<http://bugs.python.org/issue30532>
___
___
Python-bugs-list mailing list
Un
R. David Murray added the comment:
Given that there hasn't been any response that would help us improve the docs
on this, I'm going to close the issue. I hope you've figured out how to do
what you want to do!
--
resolution: -> not a bug
stage: -> resolved
s
R. David Murray added the comment:
If it's a good idea, why close the issue? Maybe post it to core-mentorship
instead? It's not an easy issue, but it also has the beginnings of a patch.
So if there is anyone on core-mentorship with some windows knowledge (and I'm
guessing th
R. David Murray added the comment:
Given that background, closing it seems reasonable to me :)
--
___
Python tracker
<http://bugs.python.org/issue12939>
___
___
R. David Murray added the comment:
IMO allow_non_nfkc=True that just returns False would be a bad idea, since as
Benjamin points out it *is* a valid identifier, it's just not normalized (yet).
Raising might work, that way you could tell the difference, but that would be
a weird API for
Changes by R. David Murray :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue30755>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by R. David Murray :
--
nosy: +lukasz.langa
___
Python tracker
<http://bugs.python.org/issue30760>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
See also issue 30772 about the deeper problem.
--
___
Python tracker
<http://bugs.python.org/issue13821>
___
___
Python-bug
R. David Murray added the comment:
Hmm. All the dunder methods are listed in the index on the '_' page. It would
kind of be consistent to have an '@' page. Not sure what would be needed to
make that happen though (might be a sphinx level thing).
--
n
R. David Murray added the comment:
I'm not entirely sure what you are asking for opinions on, but for what it is
worth I'm with Haypo: the repr should show the *actual* value of the attributes.
--
nosy: +r.david.murray
___
Python trac
R. David Murray added the comment:
If the docstring changes incorporate changes from this PR, I'd keep them in a
single PR myself. If not, two PRs would make review easier. On the other
hand, if haypo is volunteering to do the review, do whatever he
R. David Murray added the comment:
We should fix the docs for 3.5 and 3.6, and open an enhancement request for 3.7
if we still think this feature is a good idea.
--
___
Python tracker
<http://bugs.python.org/issue30
R. David Murray added the comment:
See also issue 12568.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue30717>
___
___
Python-bugs-list m
R. David Murray added the comment:
Interestingly, this just came up again in issue 30717.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue12
R. David Murray added the comment:
If you pass shell=True, PWD gests set, because it is a shell variable and the
shell sets it. If you don't, it doesn't, just like all the other
shell-maintained variables. I'm not sure it is worth calling out specifically
in the Popen docs
R. David Murray added the comment:
Per our current policy with respect to mime types, this should be added to all
currently maintained versions.
--
stage: -> needs patch
versions: +Python 2.7, Python 3.5, Python 3.6
___
Python tracker
&l
R. David Murray added the comment:
Yes. There's a chance someone else will review it if you do that. I'm still
not likely to have time for a while, myself, but ping me again in a month if I
haven't gotten to it.
--
___
Python
R. David Murray added the comment:
I have no opinion on that issue. I opened this issue to fix a hole in our
validation, but if that hole no longer exists after that (subsequently opened
:) issue is resolved, then this isn't needed (sorry, Ammar, and thank you for
your
R. David Murray added the comment:
There's a deeper problem here involving how Header is used in compat32 that
I've been aware of for a while but haven't had time to try to think through a
fix for (there may not be one, given the history of the compat32 code). In the
meantim
Changes by R. David Murray :
--
versions: -Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue30835>
___
___
Python-bugs-list mailin
R. David Murray added the comment:
Yes, setting _MAX_LENGTH can be an independent feature request.
The default will not be changed, however, since it is the most useful default
given that assertEquals in general produces a much more useful diff output in
addition to the one-line summary
Changes by R. David Murray :
--
assignee: -> docs@python
components: +Documentation
nosy: +brett.cannon, docs@python, eric.snow, ncoghlan
versions: +Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issu
R. David Murray added the comment:
I'm guessing we can only do something here in 3.7, for backward compatibility
reasons, but maybe I'm wrong. Hopefully Lukasz will notice the activity on the
issue and have time to take a look.
--
nosy: +r.david.murray
versions: +Python 3
R. David Murray added the comment:
This issue is closed. Please open a new issue for your problem and proposal.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue10
R. David Murray added the comment:
Probably. Figure out a protocol to inject them into linecache, perhaps. But
I'm not sure such a thing would be accepted. If you can figure out a way to
make it work at least theoretically, it would probably be best to talk about it
on python-ideas
R. David Murray added the comment:
I think the current error message is more informative than your suggestion,
myself. However, the message could say "keyword argument name" instead of just
"keyword", which I think would be quite a bit clearer.
I seem to remember anothe
R. David Murray added the comment:
I will let Vinay answer definitively, but this is working as designed. This
allows you to set 'debug' level on a sub-logger without getting debug output
for every logger in your system, which is what you would get otherwise as the
default loggin
R. David Murray added the comment:
If I saw your message, I would think "what is a 'simple name'?". There's no
glossary entry for that, nor is it a concept used elsewhere in the
documentation as far as I remember. One could instead use "single identifier&qu
R. David Murray added the comment:
@qingyunha: we are telling you that that would *introduce* a bug. This is
working the way it is supposed to.
Vinay, what if we rewrote the beginning of that paragraph like this:
Sets the threshold for this logger to lvl. Logging messages which are less
R. David Murray added the comment:
Reading through some of the linked material, it looks like the issue is with
how UNC "symlinks" are resolved.
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.o
R. David Murray added the comment:
New changeset c60d2f5e8609b040ab58c498fde23928fe9dbef5 by R. David Murray (Joel
Hillacre) in branch '3.6':
bpo-30532: Fix whitespace folding in certain cases (#2591)
https://github.com/python/cpython/commit/c60d2f5e8609b040ab58c498fde239
R. David Murray added the comment:
New changeset 3bbdf990a2c1b0b303b950058e3177a1bd5f697a by R. David Murray (Joel
Hillacre) in branch '3.5':
bpo-30532: Fix whitespace folding in certain cases (#2592)
https://github.com/python/cpython/commit/3bbdf990a2c1b0b303b950058e3177
R. David Murray added the comment:
Thanks, Joel!
--
resolution: -> fixed
stage: backport needed -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
R. David Murray added the comment:
I think we are waiting on confirmation that we have a buildbot that has the
necessary headers.
--
___
Python tracker
<http://bugs.python.org/issue27
R. David Murray added the comment:
Given a choice between catering for Python programmers and catering for
Java/C++ programmers, the Python docs obviously ought to chose to cater to
Python programmers. To a python programmer, calling C.f() is intuitive.
I would myself definitely *not
R. David Murray added the comment:
Also note that we have fixed a number of bugs in the stdlib code where a raw
string was not used for a docstring when it should have been. And when I say
bugs, I mean both formatting problems in pydoc, and doctest bugs. There may
even have been a case
R. David Murray added the comment:
I'm not sure there's a "best practice" choice between the two calling forms
that are documented. Although obviously when you don't have an instance you
can't use the instance calling form. I think it is *common* practice to u
R. David Murray added the comment:
I don't think that helps. The issue here is that *sequences* are iterated over
by incrementing an integer index. If you change the size of the list, you are
potentially changing which value any given index points to. Presumably the
tutorial writer th
R. David Murray added the comment:
Thanks. OK, so you agree a fix is appropriate. What about the question of
backport/backward compatibility?
--
___
Python tracker
<http://bugs.python.org/issue23
2701 - 2800 of 10554 matches
Mail list logo