Changes by R. David Murray <rdmur...@bitdance.com>:
--
resolution: fixed -> third party
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
R. David Murray added the comment:
Yes, but we try to make it not possible to segfault the interpreter with pure
python code that isn't intentionally mucking with C-level stuff, so this is a
bug we would like to fix.
--
nosy: +r.david.murray
R. David Murray added the comment:
Can you provide a reproducer, please?
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
Actually, the API discussion may be short: we already have a 'validate' option,
whose spirit matches with this, so adding the check for the padding issue to
that of the non-alphabet characters check would seem to me to be quite
reasonable
R. David Murray added the comment:
Not only is it conforming, it is required, since the primary use (originally)
of the base64 module was in the email package, where generous interpretation of
the input is the standard.
This does not mean that adding a strict mode would be out of line
Changes by R. David Murray <rdmur...@bitdance.com>:
--
stage: -> needs patch
type: -> behavior
versions: +Python 3.6, Python 3.7 -Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
R. David Murray added the comment:
replace_header has a different semantic than del-and-set (replace_header leaves
the header in the same location in the list, rather than appending it to the
end...that's it's purpose). If replace_header is throwing a key error, then I
guess we need a look
R. David Murray added the comment:
As I mentioned on the PR I think it should be a ValueError, and that the PR
also needs tests.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
Thank you for linking to that Xiang. I had a vague memory of that discussion
but couldn't find it.
No, there is no bug here, but there is a question of whether or not there
*should* be a bug here (that is, is there a design bug) and if so how/where to
fix
R. David Murray added the comment:
That's actually a very good question. hasattr returns False, but is it
supposed to be an invariant that if dir returns a string hasattr should return
True and getattr should not return AttributeError? (Well, it might raise
AttributeError from inside
R. David Murray added the comment:
Can you provide actual code that demonstrates the issue you are talking about?
--
nosy: +r.david.murray
versions: -Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
In other words, this was a major standards screwup and we get to deal with the
consequences :(
All right, since I'm hardly likely to have time to deal with it anyway, we'll
just say that email isn't going to handle unicode domain names until *someone
R. David Murray added the comment:
The email package currently forces explicit IDNA use currently. The new
policies are supposed to support it automatically but I they currently don't.
I'm not sure we should add it to the old interface (parseaddr/formataddr) any
longer, but I don't object
R. David Murray added the comment:
If I'm interpreted what the OP wrote correctly, he wanted the help text to not
show that the option takes an argument, but instead rely on the help text to
show that. That works for the option text, but it doesn't work for the
synopsis (the synopsis is just
Changes by R. David Murray <rdmur...@bitdance.com>:
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
R. David Murray added the comment:
Pinging the issue is exactly what you needed to do :) As I said on the PR, I'm
not set up to do backports yet so hopefully you or someone else will do those.
--
stage: -> backport needed
versions: +Python 3.5, Python 3.6, Python
R. David Murray added the comment:
New changeset a083c8ee6cb89ca573fe10c4c1922e2fa69ceaa3 by R. David Murray
(jugglinmike) in branch 'master':
bpo-30160: Clarify intended usage of wfile (gh-1300)
https://github.com/python/cpython/commit/a083c8ee6cb89ca573fe10c4c1922e2fa69ceaa3
R. David Murray added the comment:
Duh. (Smacks self on forehead).
Nevermind.
I'll approve the patch as is, since I can't see any good way to test it.
(I suppose that we could factor the __init__ method contents out into something
we could test, but I'm not going to push for that kind
R. David Murray added the comment:
It would be a white-box test, which I don't like, but it might be worth it to
write a test that would check that .sock is None, indicating that
close was called. You really can't check for no warning because when the
warning gets generated is effectively
R. David Murray added the comment:
I'm not entirely sure why some of the conversions are done they way they are,
but I do know that one goal is to make all of the line endings consistent,
whatever may be the case on disk. If you aren't modifing the mailbox, nothing
should happen. If you
Changes by David Rothera <david.roth...@gmail.com>:
--
nosy: +David Rothera
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30395>
___
R. David Murray added the comment:
It's not the PSF, it's the dev team, and it is "just" a matter of tooling.
Which means help improving the tooling is welcome :)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
David K. Hess added the comment:
Pushed more commits so here's a branch compare:
https://github.com/python/cpython/compare/master...davidkhess:fix-issue-4963
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
David K. Hess added the comment:
Ok, I followed @r.david.murray's advice and decided to take a shot at this.
First, I noticed that I couldn't reproduce the non-deterministic behavior that
I reported above on the latest code (i.e. pre-3.7). After doing some research
it appears
R. David Murray added the comment:
I think we are leaning strongly toward making no change here.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
Ah, yes, that's a bug in our workflow we'll need to fix. The CLA signed on the
bug tracker is the ultimate authority, so we need some way to manually bypass
the bot for cases like this.
A committer should be able to bypass the problem and get the patch
R. David Murray added the comment:
Our tooling and workflow is indeed dependent on github. We should repurpose
the current 'remote hg repo' to allow the entry of a non-github git repo, but
someone will have to write that code. In the meantime, if you upload a patch
generated from your
David Heffernan added the comment:
Erik,
As you can no doubt guess, this is related to the questions I have been asking
on SO that you have so expertly been answering. Thank you!
When I solved the latest problem, getting at the internal buffer of a
bytearray, I used the code in my previous
David Heffernan added the comment:
I just ran into this issue. I'm trying to write code like this:
(ctypes.c_char*bufferLen).from_buffer(buffer)
where buffer is a bytearray. When bufferLen is greater than 2GB I fail foul of
this code in _ctypes.c
long length;
length
Changes by R. David Murray <rdmur...@bitdance.com>:
--
stage: test needed -> needs patch
versions: +Python 3.6, Python 3.7 -Python 2.7, Python 3.2, Python 3.3, Python
3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
R. David Murray added the comment:
@dhess: do you want to work on the OrderedDict + correctly ordered hardcoded
lists solution?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
R. David Murray added the comment:
I don't do much with the C API, but since your goal is to remove them from the
PyMODINIT_FUNC, I would think you could replace those entries with calls to
wrapper functions that issue the deprecation and then call the real function
David Hess added the comment:
And the underlying problem causing this:
$ python -c 'import
mimetypes;print(mimetypes.guess_all_extensions("image/jpeg"))'
['.jpeg', '.jpg', '.jpe']
$ python -c 'import
mimetypes;print(mimetypes.guess_all_extensions("image/jpeg"))'
['.
David Hess added the comment:
Concur with @sivert – the result of guess_extension() is non-deterministic
between mimetypes module initialization.
$ python
Python 3.4.3 (default, Nov 17 2016, 01:08:31)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or
R. David Murray added the comment:
That sounds reasonable, if the debug output doesn't pollute the test run output.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
They are not part of the API, that is why they are not documented. The
convention of "always" using _ prefixed names for non-API stuff is (relatively)
recent. It used to be we just didn't document the non-API stuff.
Your second argument
R. David Murray added the comment:
No, I'm arguing purely from a generic backward compatibility perspective.
There does not seem to be me be sufficient benefit to removing them to justify
doing it.
--
___
Python tracker <rep...@bugs.python.
R. David Murray added the comment:
If it is there for debugging, why would we want to remove it?
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
That's the same motivation, not a new one :) Someone somewhere may be using
them for something, they've been around for a long time. I hope not, though.
--
___
Python tracker <rep...@bugs.python.org>
R. David Murray added the comment:
To clarify my question, I don't think it is a bug, but the fact that you do
might mean there needs to be a doc clarification. Or it might not. Or, there
might be a desirable enhancement here, maybe relating to the pathlike protocol
R. David Murray added the comment:
Why do you think this is a bug?
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
Sorry, by "real motivation" I meant something beyond just cleaning up the
API...that's a real motivation, it may just not be enough.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
R. David Murray added the comment:
If these objects have been exposed in the past, we won't simply delete them.
At a minimum there would need to be a deprecation period, but is there a real
motivation for deleting them?
--
nosy: +r.david.murray
David Bolen added the comment:
In running the test under a local build, the issue is very repeatable, but I
believe it's actually due to slow process startup rather than a quick exit.
That is, adding a brief sleep after process creation and just before the
Request() call seems to fix
David Bolen added the comment:
Hmm, I wonder if this is another race condition similar to issue 8458?
I think that was thought to be related to the subprocess exiting quickly, in
which case the question might be why that might happen more so than the actual
descriptor error.
BTW, Victor
david-cpi added the comment:
Hello Victor,
in 3.6.1 the test passes but it's because on sub-test was removed.
The one generating the issue is NetworkedBIOTests which is not found in 3.6.1.
in 3.5.2:
if support.is_resource_enabled('network'):
tests.append(NetworkedTests
david-cpi added the comment:
Hi Victor,
I will try during the day and get back with the logs.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
Not only is not something to be surprised about, it would be surprising for it
to be absent. So the user cognitive overhead of removing it is quite possibly
higher than that of it being there.
--
nosy: +r.david.murray
R. David Murray added the comment:
Yes, and I'm saying his example doesn't work on Windows (on windows, it does
not accomplish his goal). So I'm not sure it is a use case appropriate for the
standard library. I'm not saying it definitely isn't, I'm just raising a doubt
R. David Murray added the comment:
You are depending on a non-portable feature of os.rename there, so I'm not
convinced this makes a good use case for the Python stdlib.
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
New submission from david-cpi:
To make the test pass, I added the following try statement:
try:
sock.sendall(buf)
except:
pass
--
components: Tests
files: test.log
messages: 292608
nosy: david-cpi
priority: normal
severity: normal
Changes by David Haney <david.ha...@gmail.com>:
--
pull_requests: +1463
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30183>
___
R. David Murray added the comment:
I think Benjamin is the only one who has done any work on it so far. I think
you'd ask the infrastructure team for access if you want to do so.
--
___
Python tracker <rep...@bugs.python.org>
R. David Murray added the comment:
We generally don't do this kind of type checking in the standard library. The
message may not be clear, but it is accurate and decipherable, especially given
the fact that the write parameter name is 'buffer'. I don't think anything
should be done here
David Bolen added the comment:
Yeah, there were a few transient build errors while I was getting the buildbot
back online. My initial attempt to fix this ticket involved using the VS 2015
installer which turned out very badly, so I had to fall back to an older VM
image and start over
David Bolen added the comment:
Ok, I believe I've got the latest ucrtbased now on the Win7 buildbot
(validate_ucrtbase.py reports it as 10.0.15063.137).
It appears as if my Win8 and Win10 buildbots also have the older dll, so I'm
guessing they're just fast enough or lucky enough not to run
R. David Murray added the comment:
Indeed, it sounds like wine is claiming to be Windows 7 but then implementing
(as not implemented) later-than-windows-7 apis. That definitely sounds like a
bug in wine.
--
nosy: +r.david.murray
___
Python tracker
R. David Murray added the comment:
I suppose someone could propose a set of tests that an implementation of an ABC
type should pass, to complement the stdlib type tests. There would probably be
a lot of bikeshedding involved in such tests though, so I don't hold out great
hope anything would
R. David Murray added the comment:
For backward compatibility reasons, history will win.
I'm not sure if documenting the additional restrictions of the concrete stdlib
types in the ABC docs makes sense, either, since the ABCs are intentionally the
minimal requirements for a concrete type
R. David Murray added the comment:
Setting up an imap server on pythontest is the "right" answer. Somebody has to
do the work, though :)
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
David Haney added the comment:
> It seems like gethrtime() is the right function to be used on HP-UX.
> https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/gethrtime.3C.html
Thanks, I'll work on getting a patch that leverages gethrtime() tested and
submitted for
R. David Murray added the comment:
My impression is that the sentence is there because you are acting directly on
the raw byte stream, which you are not in the other cases. (Well, rfile, but
that's reading, so what you do there doesn't affect the wire protocol you send
R. David Murray added the comment:
Considering that in the cpython test suite we avoid using docstrings in
unittests because of this "feature" of unittest, I doubt anyone on the core
team is going to be motivated to fix this :) That doesn't mean we won't accept
a PR, but if we d
New submission from David Haney:
When compiling on HP-UX with the native cc compiler, the following compilation
error occurs in pytime.c
cc -Ae -c -O -O -I. -I./Include-DPy_BUILD_CORE -o
Python/pytime.o Python/pytime.c
"Python/pytime.c", line 723: error #2020:
R. David Murray added the comment:
If it is a bug that indicates there is at least one missing unit test :) Maybe
the OP will contribute a test.
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
You've closed stderr.
--
nosy: +r.david.murray
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
R. David Murray added the comment:
I would like to say that the latter interpretation is "obviously" correct,
except that it clearly wasn't obvious to you. The fact that it "contains the
output stream" I would have thought was pretty clear: if you are writing to it,
R. David Murray added the comment:
re.escape was escaping too much previously, and this has been fixed in 3.7 (and
only 3.7, because it may cause testing issues such as you have observed). See
issue 29995.
A note needs to be added to the 'porting' section of whats new covering
R. David Murray added the comment:
You don't appear to have successfully attached the script. Can you try again
please?
The patching in the issue you point to does not patch __and__, it just sets it
equal to __rand__.
--
nosy: +r.david.murray
R. David Murray added the comment:
Then you have a broken copy of 3.5.1. There is nothing OS-specific about that
file.
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
Good point, re.escape is for literal text you want to insert into a matching
pattern, but the replacement template isn't a matching pattern. Do we need a
different escape function? I guess the function solution is enough
David Bolen added the comment:
Ok, this should be resolved. I opted to be a bit more conservative and only
upgraded to sqlite3 3.8.3.1, which is the oldest version still in use for the
dmg installer packages (for 2.7). I restarted the most recent 3.x build and
while it's not completely done
R. David Murray added the comment:
I think you are missing a re.escape around text. Text is otherwise not a valid
replacement pattern.
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
David Bolen added the comment:
The test appears to pass against a local test build of sqlite3 3.18.0, so I'll
probably just plan on updating the slave to that later tonight. Unless anyone
is interested in figuring out why it fails with 3.6.11 and not 3.18.0 (e.g.,
does the test have a higher
David Bolen added the comment:
No recent changes to the buildbot (I think the last was in September to bump
the local python used to run the slave/build installer to 2.7).
The default system sqlite (/usr/lib) is 3.0.8.6, so extremely old, but 3.6.11
is in /usr/local/{lib,include} from early
R. David Murray added the comment:
Yes, please do provide an example. Your final words do not make a convincing
case that this is a problem in python3 :)
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
R. David Murray added the comment:
Also, please review the (newly rewritten) section in the devguide about PRs. I
see now that there were changes made from the original here already, but I
don't see the commits that made those changes. The history of changes should
be kept during PR
R. David Murray added the comment:
To be clear: backport PRs should be created only after a PR has been approved.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
Please close the redundant PRs. I've commented on pr1228.
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by R. David Murray <rdmur...@bitdance.com>:
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> keyword module missing async and await keywords
___
Python tracker <rep...@b
R. David Murray added the comment:
Well, part of the point of the tests is to make sure the module's behavior
doesn't change when doing the conversion to argparse. But "behavior changing"
doesn't extend to the exact format of the output...that can change, as long as
what the mo
R. David Murray added the comment:
Numpy is not part of the Python standard library. You'll need to engage with
the numpy community on this question. (I say engage with them on the question,
not report a bug to them, because I highly doubt this is a bug...there's
probably some way to do
Changes by R. David Murray <rdmur...@bitdance.com>:
--
type: behavior -> enhancement
versions: +Python 3.7 -Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by R. David Murray <rdmur...@bitdance.com>:
--
components: +Library (Lib) -Extension Modules
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
R. David Murray added the comment:
I don't think your specialized error message adds anything. The the most
common mistake, IMO, is going to be not realizing that run_coroutine_threadsafe
don't return one of the acceptable types. So being told that
concurrent.future.Future is not acceptable
R. David Murray added the comment:
Right. Which is why you get an error if you try to use an empty directory as
if it was a maildir :)
create=True creates the *directory* and initializes it. That seems clear to
me, and exactly what I would expect. "The mailbox" is the
R. David Murray added the comment:
Just create a subdirectory inside the tempdir to hold your Maildir folder. I
think it is not worth complicating the API for this use case, since it does
have a simple solution.
--
versions: -Python 2.7, Python 3.5, Python 3.6
Changes by R. David Murray <rdmur...@bitdance.com>:
--
resolution: -> not a bug
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
R. David Murray added the comment:
If there is a way to resolve the lock issue we can consider it. But (without
looking at the code again) I suspect the locking is too deeply embedded in the
mbox logic for this to be a safe change.
--
___
Python
R. David Murray added the comment:
The support. ClawsMail is broken, IMO.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
Woops, cut and paste error, there should have been an "echo $2" line in that
script as well.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
R. David Murray added the comment:
Note the subtlety here on unix:
rdmurray@pydev:~/python/p36[3.6]>cat temp.sh
#!/bin/bash
echo $0
echo $1
>>> subprocess.call(['./temp.sh', 'spam', 'eggs'], shell=True)
./temp.sh
0
>>> subprocess.call(['./temp.sh $0 $1', 'spam'
R. David Murray added the comment:
Honestly, given the open questions my inclination would be to reject this.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
R. David Murray added the comment:
Because passing a sequence to shell=True won't work on unix. It only works
more-or-less by accident on windows, even though the current docs kind of
encourage it. Yes, I think it would be good if these sentences were clarified.
See also issue 7839
R. David Murray added the comment:
Agreed that it looks like another example line should be added to the help for
this case.
--
nosy: +r.david.murray
stage: -> needs patch
versions: +Python 3.7 -Python 3.3, Python 3.4, Python 3.5
___
Python trac
R. David Murray added the comment:
I thought something like that might be the problem with your attempt to
suppress the warnings. A library really should not call a global state
function such as filterwarnings, that should be done only by the application.
You might want to file a bug report
R. David Murray added the comment:
Yes, but the way deprecation warnings work is that there is a stacklevel
specified, and the line reported in the error is that number of steps back up
the call stack from where the warning was actually issued. The json module
doesn't natively handle
R. David Murray added the comment:
As for the filterwarnings, If you can come up with a demonstration of a problem
that does not involve third party code, please open a new issue with the
reproducer.
--
___
Python tracker <rep...@bugs.python.
R. David Murray added the comment:
I don't believe that warning message is generated by the python standard
library. I can't find it in the codebase, and I can't think of any context in
which we'd have a reason to generate that message
R. David Murray added the comment:
The python standard library makes extensive use of duck typing. Duck typing is
a pretty fundamental part of the design of Python, IMO. Even the ABC module
does a bunch of duck typing, rather than requiring strict subclassing or
registration.
I think
1501 - 1600 of 12771 matches
Mail list logo
