R. David Murray added the comment:
Nick, what Jakub is saying is that 'with' hasn't even gotten involved yet:
we're still executing the NamedTemporaryFile constructor, so the object hasn't
been returned for 'with' to operate on yet. In other words,
NamedTemporaryFile.__init__ isn't safe
R. David Murray added the comment:
Ah, maybe it doesn't handle it completely correctly; that decode looks
different now that I look at it in detail.
--
___
Python tracker
<https://bugs.python.org/issue34
R. David Murray added the comment:
Oops, I left out a step in that cut and paste. For completeness:
>>> x = x[3:]
--
___
Python tracker
<https://bugs.python.or
R. David Murray added the comment:
That does appear to be a bug. Note that the new email API handles it correctly:
>>> x = """
... > From: =?utf-8?Q?z...@redacted.com.cn=E3=82=86=E2=86=91=E3=82=86?=
... =?utf-8?Q?=E3=82=83=E3=82=85=E3=81=87=E3=8
R. David Murray added the comment:
Maybe we'll be luck and Maciej will still be interested :)
--
nosy: +maciej.szulik
___
Python tracker
<https://bugs.python.org/issue34
R. David Murray added the comment:
Would you care to propose a patch? That's likely the only way this is going to
get fixed, unfortunately, as currently we have no one on the core team
interested in imaplib. Which means it is also going to be hard to come up with
someone to do the review
R. David Murray added the comment:
It looks like the virus checkers are not doing robust decoding that the email
RFCs recommend, and that thunderbird is. This is obviously a bug in the virus
scanners. By default, like thunderbird, the email library does its best to
decode attachments
R. David Murray added the comment:
This appears to be a bug in pip or the ansible-lint package, similar, and
possibly identical, to issue 31361. I believe None is being passed in as the
argument to feed_parser.feed, which is an invalid use of that API and so
correctly results in an error
R. David Murray added the comment:
The default maximum line length is indeed supposed to be 78 (characters..and I
can't now remember whether I implemented it in terms of characters or octets),
that's per RFC 5322. What is wrong is that content encoded text is supposed to
use a max line
R. David Murray added the comment:
OK. Finding a solution for this (other than never raising samefile on such
systems and documenting it as a limitation) may be difficult.
--
___
Python tracker
<https://bugs.python.org/issue33
R. David Murray added the comment:
That patch would cause references to the same file on a google drive to report
that the files were different.
I'd say this is a bug in Google Drive's posix emulation.
I'm not sure there's a good answer here, because even if every other element of
the stat
R. David Murray added the comment:
This is still a duplicate issue, though, you are just arguing for a different
resolution of the other one :)
--
nosy: +r.david.murray
___
Python tracker
<https://bugs.python.org/issue33
R. David Murray added the comment:
IIUC that error message came from pypy, not CPython. If you have a reproducer
for CPython, you can open a new issue with a request to fix the error message.
--
nosy: +r.david.murray
___
Python tracker
<ht
R. David Murray added the comment:
I think we should get one or more of the core devs who were involved in the
changes that added that parameter to sign off on whether this is a good idea or
not (I have no opinion at the moment). You should be able to find them via git
blame and looking
R. David Murray added the comment:
I think it might be OK to document what goes in to the signature, but probably
in a footnote, as it is somewhat of an implementation detail and could
conceivably change. We could then also add a caution about mtime imprecision
being a particular risk
Change by R. David Murray :
--
versions: +Python 2.7
___
Python tracker
<https://bugs.python.org/issue33896>
___
___
Python-bugs-list mailing list
Unsubscribe:
R. David Murray added the comment:
For your problem, just don't use the default shallow setting :)
--
___
Python tracker
<https://bugs.python.org/issue33
R. David Murray added the comment:
I understand your concern, but this is working as designed and documented.
Using st_ino would mean you would return true if and only if it was the *same*
file. That is not the intent. See issue 27396 for some background discussion.
--
nosy
R. David Murray added the comment:
I would still like to see the legacy tex markup removed from the docstrings, so
I think closing this issue is not appropriate, but it's not a big enough deal
that I'll push for it if Raymond wants to keep it closed
R. David Murray added the comment:
No, it is (somewhat) unique to tex. If you write `word' tex would turn that
into a pair of opposing quotes in the typeset document, as opposed to 'word'
(the convention in regular text/emails/posts/etc) where you'd just see ascii
quotes. tex would render
R. David Murray added the comment:
By the way, in case anyone is curious, I'm pretty sure that markup is left over
from the days when tex/latex was what docs were *written* in.
--
___
Python tracker
<https://bugs.python.org/issue28
R. David Murray added the comment:
Right, my opinion is that we shouldn't be putting markup in docstrings. They
are (from our point of view) pure text.
I don't know if discussion on python-dev is warranted, it seems like a fairly
uncontroversial change, since it brings the docstrings
R. David Murray added the comment:
I didn't think to look at the standards for the auth mechanisms, I only looked
at the smtp standards. So, if the standard says utf-8, then we should use
that. But we should still support bytes passwords so that an application could
work around issues
R. David Murray added the comment:
zsh lets you edit multiline shell commands as a unit. If you up-arrow, you get
all the lines of the block popped up, with the cursor on the last line.
Further arrow keys will navigate within the multiline text block, with an
up-arrow from the first line
R. David Murray added the comment:
Thanks for coming back to this.
We're accepting PRs via github now, so the next step now would be to make it
into a PR.
Sometimes things just get forgotten and you have to nudge them to get them
moving (see the devguide for guidelines about when
R. David Murray added the comment:
Sorry, but these paths are not equal in in any sense that Python by itself can
determine. Support for doing this kind of comparison would have to come from
MingGW or cygwin, and even if a python library exposed those capabilities, it
would be via some new
R. David Murray added the comment:
We must continue to support at least ascii strings, for backward compatibility
reasons. We can certainly improve the error messages, but the goal of this
issue is to add support for bytes passwords. I lean toward continuing to only
support ascii strings
R. David Murray added the comment:
I thought there was a more general issue for the 'in' operator itself, but
perhaps the issue you found was indeed the one I was thinking of. This one
certainly seems to be a duplicate of that one ;) If you've a mind to, you
could turn the patch
Change by R. David Murray :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
R. David Murray added the comment:
For the web cases I presume you also set the password using the web interface,
so that doesn't really tell us anything useful. Did you use thunderbird to
access the mailbox that you set up via gmail and/or sogo? That would make what
thunderbird does
R. David Murray added the comment:
While you are correct that latin1 may be common in this situation, I think it
may still be better to have utf-8 be the default, since that is the (still
emerging? :) standard. However, you are correct to call for examples: if in
the *majority* of the real
R. David Murray added the comment:
We don't generally do type checks like that. This is a specific case of a
general issue with binary operators and mismatched string/bytes types. I
thought there was an open issue for it, but I haven't found it yet.
--
nosy: +r.david.murray
R. David Murray added the comment:
It doesn't look like this has anything to do with Python. This sounds like a
question more appropriate for an Excel help forum.
--
nosy: +r.david.murray
___
Python tracker
<https://bugs.python.org/issue33
R. David Murray added the comment:
Message/EmailMessage are intentionally mimicing the full dictionary API, not
just the Mapping API (with a couple exceptions and several extensions). But it
is important to mention that it is ordered, both for the reason INADA stgtes,
and because the text
Change by R. David Murray :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue33835>
___
___
Python-bugs-list mailing list
Unsubscrib
R. David Murray added the comment:
Thanks, Zachery.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
R. David Murray added the comment:
New changeset bbbc3d99dca41bc95a9402d702f6ab833d3003c7 by R. David Murray (Miss
Islington (bot)) in branch '3.6':
bpo-30820: Remove incorrect docs for email.contentmanager.raw_data_manager
(GH-7631) (#7634)
https://github.com/python/cpython/commit
R. David Murray added the comment:
New changeset b06fc2d244f95f8a497cbcdc6e2fbeb9b8133ca3 by R. David Murray (Miss
Islington (bot)) in branch '3.7':
bpo-30820: Remove incorrect docs for email.contentmanager.raw_data_manager
(GH-7631) (#7633)
https://github.com/python/cpython/commit
R. David Murray added the comment:
New changeset 2c071cebe67f517f191f4074757a79b0f597d886 by R. David Murray
(Zackery Spytz) in branch 'master':
bpo-30820: Remove incorrect docs for email.contentmanager.raw_data_manager
(#7631)
https://github.com/python/cpython/commit
Change by R. David Murray :
--
stage: -> needs patch
versions: +Python 3.8 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue29750>
___
___
Python-
R. David Murray added the comment:
Note: it is definitely the case, regardless of what the RFC says, that binary
passwords need to be supported. utf-8 should probably be used as the default
encoding for string passwords, rather than ascii. See also #33741
Change by R. David Murray :
--
nosy: +JustAnother1, giampaolo.rodola, taleinat
___
Python tracker
<https://bugs.python.org/issue29750>
___
___
Python-bugs-list m
R. David Murray added the comment:
Duplicate of #29750. TLDR: smtplib needs to be fixed to handle binary
passwords, and probably to use utf-8 as the default encoding for unicode
passwords.
--
nosy: +r.david.murray
resolution: -> duplicate
stage: -> resolved
status: open -&g
R. David Murray added the comment:
I think that would move it even more into the realm of a bugfix, then, since
code that cared about specific binascii exceptions could be looking for that
one already.
--
___
Python tracker
<ht
Change by R. David Murray :
--
nosy: +benjamin.peterson, stutzbach
___
Python tracker
<https://bugs.python.org/issue28557>
___
___
Python-bugs-list mailin
R. David Murray added the comment:
To clarify: don't call open again *on that telnetlib.Telnet object*. You can
certainly have more than one open connection using different telnetlib.Telnet
instances, though it might be a bit challenging to manage them
Change by R. David Murray :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
R. David Murray added the comment:
telnetlib provides a low level interface to the telnet protocol. The dialog
you mention appears to be transmitted on the telnet connection, so it is
unlikely there is any bug or missing feature in telnetlib that would affect
your problem.
The sentence
R. David Murray added the comment:
I like it, myself, though there is some danger in promoting the idea that this
is a "safe" operation. It theoretically should be, but it increases the attack
surface slightly if you actually use it (that is, using shell=False is always
safer, b
R. David Murray added the comment:
The email module uses it, so I would object to its being removed. It may not
be used often (probably only when working with old email archives), but there's
no good reason I can see to break something that currently works.
--
nosy: +r.david.murray
R. David Murray added the comment:
Agreed that this should be documented.
--
nosy: +r.david.murray, rhettinger
stage: -> needs patch
title: Improve doc of @lru_cache to avoid misuse and confusion -> Document that
@lru_cache caches based on exactly how the function arg
R. David Murray added the comment:
I agree, but that would be a separate enhancement PR. The email library would
use that capability if it existed...currently it adds padding in a loop trying
to do the decode if it gets the invalid padding message. Which of course is
going to fail
R. David Murray added the comment:
I always assumed that any string composed of valid base64 characters could be
decoded to *something* if you added some padding characters, but apparently
that was an invalid assumption. I agree that the message is incorrect for this
case.
--
nosy
Change by R. David Murray :
--
resolution: -> not a bug
stage: test needed -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by R. David Murray :
--
superseder: -> can cmd.py's API/docs for the use of an alternate stdin be
improved?
___
Python tracker
<https://bugs.python.org/issu
R. David Murray added the comment:
This is a duplicate of 2571 and 10396. As I commented in 10396, if you want to
work on an enhancement request (for cmd) that improves the situation, it will
be welcome; but as you observed what to do isn't immediately obvious, so
discussion before
R. David Murray added the comment:
That's presumably due to the compile-time constant-expression optimization.
Have you tried bytes(0x100)? I don't think that gets treated as a constant
by the optimizer (but I could be wrong since a bunch of things ahve been added
to it lately
R. David Murray added the comment:
I seem to recall that this ValueError behavior was discussed at some length and
it is the desired behavior. (At some previous point I think everything after
the NUL was ignored.) I'm not really sure why it needs to be documented
either, NULs are invalid
Change by R. David Murray :
--
resolution: -> not a bug
___
Python tracker
<https://bugs.python.org/issue33690>
___
___
Python-bugs-list mailing list
Un
R. David Murray added the comment:
It would be odd to do that, since blank values are kept by default.
--
___
Python tracker
<https://bugs.python.org/issue33
R. David Murray added the comment:
Vladimir, please open a new issue for this feature request. This issue is
closed.
--
nosy: +r.david.murray
___
Python tracker
<https://bugs.python.org/issue29
R. David Murray added the comment:
Sounds reasonable to me.
--
___
Python tracker
<https://bugs.python.org/issue22021>
___
___
Python-bugs-list mailin
R. David Murray added the comment:
If a sequence as a value means repeated instances of a key with each value from
the list, then logically an empty list means no instances of the key, as
documented. Blank values aren't really part of the standard (such as it is):
the absence
Change by R. David Murray :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> Python unittest.mock.mock_calls stores references to arguments
instead of their values
___
Python tracker
<https://
Change by R. David Murray <rdmur...@bitdance.com>:
--
versions: -Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
R. David Murray <rdmur...@bitdance.com> added the comment:
That is not kwargs, that's a passing a dict. Which is what you would want,
since the strings you want to replace might not be valid identifiers, and so
couldn't be passed as keyword arguments.
I think I'm -0.5 on this. I don't
R. David Murray <rdmur...@bitdance.com> added the comment:
I wrote up a response before Mark closed the issue, so despite his excellent no
discussion suggestion I'm going to post it for the edification of anyone
reading the issue later rather than waste the work :)
Nathan: this is
R. David Murray <rdmur...@bitdance.com> added the comment:
smtplib doesn't define any behavior for messages. I presume you are talking
about the email library?
Vis the print behavior, dict-style lookup is defined to return the first
matching header. If you want to see all of them, y
R. David Murray <rdmur...@bitdance.com> added the comment:
I think Ronald is correct.
The priority argument for enter would apply if you called enter twice with two
different delays, but they happen to end up pointing to the same moment in time
from the scheduler's point of view.
How
R. David Murray <rdmur...@bitdance.com> added the comment:
json keys *are* strings, so the fact that we support other object types as keys
and coerce them to strings is an "extra feature" of python, and is actually a
somewhat questionable feature. The reproducible us
R. David Murray <rdmur...@bitdance.com> added the comment:
I'm fairly certain (though not 100%, obviously :) that coercing first and then
sorting would be accepted if someone wants to create a PR for this.
--
nosy: +r.david.murray
versions: +Pyth
R. David Murray <rdmur...@bitdance.com> added the comment:
As I understand it, we don't control or know what that list is, it depends on
each distribution's policies.
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.or
R. David Murray <rdmur...@bitdance.com> added the comment:
Yes, you are substantially correct. A subtlety that may enhance your
understanding (if it doesn't instead totally confuse you :) is that __init__ is
simply the most straightforward way to affect the module namespace. You woul
R. David Murray <rdmur...@bitdance.com> added the comment:
It's the same answer. __init__ *is* the package namespace, so you are setting
the value of 'func' in the package (.) namespace, and what import is doing is
correct.
I know this is confusing. I banged my head against it
R. David Murray <rdmur...@bitdance.com> added the comment:
It's importing 'a' from '.', which I guess in this context means from the
current namespace (__main__), and a is 7. You'll note that 'b' did get
repointed, but it got repointed to what 'a' points to, instead of to 5. If it
R. David Murray <rdmur...@bitdance.com> added the comment:
Please post an example, and not a zip file. Given your description (which
indeed is not enough to understand what you think the problem is by itself), I
think you should be able to post a few lines of python code into the
R. David Murray <rdmur...@bitdance.com> added the comment:
Oh, and the empty tuple is a specific syntactic construct that really is the
empty parenthesis, so that's consistent with the language definition.
--
___
Python tracke
Change by R. David Murray <rdmur...@bitdance.com>:
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
R. David Murray <rdmur...@bitdance.com> added the comment:
No, the parenthesis are never part of the tuple itself, even if you can't write
syntactically correct code without them. They just syntactically group the
expression list to isolate it from the surrounding context. It's th
R. David Murray <rdmur...@bitdance.com> added the comment:
Oh, interesting.
I could argue that that's a missing feature in Python's slice handling. The
value of text_space at that point is '+inf', and I obviously incorrectly
assumed that slicing would treat that as if i
R. David Murray <rdmur...@bitdance.com> added the comment:
On the other hand, that section does reference the ABC directly, so I can see
the point of your question. So I guess I'm not sure what the answer is...I
don't think copy is an essential part of the ABC, but I'm no
R. David Murray <rdmur...@bitdance.com> added the comment:
The ABCs are different from the standard types provided by python itself. The
former are a minimal subset of the methods provided by the latter. So I think
the answer is neither.
--
nosy: +r.david.
R. David Murray <rdmur...@bitdance.com> added the comment:
I should have just deleted the table, actually.
The only important info in it is that per RFC '=', '=\n', and '= \n' all ought
to become '='. But I don't think we should make that change, I think we should
continue to turn
R. David Murray <rdmur...@bitdance.com> added the comment:
OK, I've finally gotten around to looking at this. It looks like quopri and
binascii are not stripping trailing whitespace.
quoprimime binascii quopri preferred
b'=' '' b''
R. David Murray <rdmur...@bitdance.com> added the comment:
The fix is mostly likely correct, so we need a PR for this that includes tests.
--
keywords: +easy
stage: -> test needed
versions: +Python 3.7, Python 3.8
___
Python tra
Change by R. David Murray <rdmur...@bitdance.com>:
--
type: crash -> behavior
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
R. David Murray <rdmur...@bitdance.com> added the comment:
These are actually reasonable requests, and in fact have been brought up before
and implemented:
>>> x =
>>> urlparse('http://me:myp...@example.com:800/foo;key1=value1?key2=value2#key3=value3#key4=value4')
R. David Murray <rdmur...@bitdance.com> added the comment:
Yes, we are one of those projects that wants it to be possible to build python
without having the tools that generate build artifacts. You will note that we
also check in build artifacts that are produced by our own python s
R. David Murray <rdmur...@bitdance.com> added the comment:
Thanks for wanting to improve Python.
Your PR seems to contain quite a few changes that aren't obviously related to
your topic.
As for the topic, I know there are at least some cases where we really do have
to *run* the code to
Change by R. David Murray <rdmur...@bitdance.com>:
--
nosy: +lukasz.langa
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33481>
___
R. David Murray <rdmur...@bitdance.com> added the comment:
In PEP 8 'CapWords" does not refer to the capwords function, as is fairly clear
from context. A big clues is that it is not spelled 'capwords', and case
matters in python function names :) I can understand your getti
R. David Murray <rdmur...@bitdance.com> added the comment:
Hmm. OK, I didn't think that's how we'd defined those terms, but then I don't
actually work with the parser much myself :) However, generator expressions
are clearly called out as a separate thing. All of the other display typ
R. David Murray <rdmur...@bitdance.com> added the comment:
That's a generator expression, just like [x for x in ramge(3)] is a list
comprehension, not a list display. And yes, in a number of circumstances
parenthesis are required to delimit the tuple display and disambiguate the
R. David Murray <rdmur...@bitdance.com> added the comment:
Nope, a tuple display is not equal to a parenthesized list. For example, in:
x = 1, 2, 3
1, 2, 3 is a tuple display. The parenthesis are optional in that case (in the
general case it is the comma that makes the
R. David Murray <rdmur...@bitdance.com> added the comment:
Ah, I see. Yes, those strings are actually hardcoded in the documentation
source instead of being references. You are correct, they should be fixed.
Note, however, that Charset is part of the legacy API and isn't actuall
R. David Murray <rdmur...@bitdance.com> added the comment:
Can you provide an example of where this occurs in the docs?
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
R. David Murray <rdmur...@bitdance.com> added the comment:
It's not immediately obvious what benefits this provides over the existing
sqlite-native repl and the python repl. Can you expand a bit on the use case?
Also, I seem to remember that Catherine Devlin had at one point thought
R. David Murray <rdmur...@bitdance.com> added the comment:
I vote -1. It's cute, but I'd much rather have a consistently ascii
representation of something that is easily represented in ascii.
--
nosy: +r.david.murray
___
Python tracke
R. David Murray <rdmur...@bitdance.com> added the comment:
Functions/methods should be immutable, so yes, I think it is a safe assumption
that they should be hashable, and a bug if they are not. I seem to vaguely
recall that there is some other part of the cpython machinery that
R. David Murray <rdmur...@bitdance.com> added the comment:
Ah, in the absence of a traceback I think I misunderstood the problem (I failed
to actually look at the code :)
Given what you say about the slotwrapper, I'm not sure, but I'm guessing that
that means cython isn't
201 - 300 of 10417 matches
Mail list logo