Serhiy Storchaka added the comment:
Oh, I forgot about this difference. Of course we can convert input arguments to
match new syntax, but trace vinfo and trace info variable return different
results:
% trace add variable foo {read write} {tracer foo}
% trace info variable foo
{{read write}
Changes by Martin Panter vadmium...@gmail.com:
--
nosy: +vadmium
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11429
___
___
Python-bugs-list
Changes by Serhiy Storchaka storch...@gmail.com:
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21580
___
Serhiy Storchaka added the comment:
Yet one incompatibility is that callbacks set but old command are called with
last argument one of 'r', 'w' or 'u', but callbacks set but old command are
called with last argument one of 'read', 'write' or 'unset' (or 'array').
--
Arnaud Fontaine added the comment:
Would it be possible to also backport the changes to httplib.py to support TLS
SNI as many libraries (including setuptools) relies on this module to download
files and some servers reject clients not supporting TLS SNI (such as
cloud.github.com)? I have
Mark Lawrence added the comment:
@Ezio will you be following this up, specifically msg193970 ?
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11955
___
Nick Coghlan added the comment:
Hi Arnaud, such a change is out of scope for PEP 466. To minimise the scale of
the changes in a maintenance release, it was deliberately limited to provide
the core infrastructure, so at least third party libraries like requests can
support SNI in Python 2,
New submission from Clayton Stangeland:
I expect struct.pack_into to work for a memoryview. Currently struct.pack_into
throws an exception.
import struct
buf = bytearray(10)
struct.pack_into(B, buf, 0, 99)
buf[0]
99
view = memoryview(buf)
view.readonly
False
struct.pack_into(B, view, 0,
Stefan Krah added the comment:
This works in Python 3.3+. It is a bug in 2.7, so we have to wait for
someone motivated enough to work on an outdated Python version.
--
components: +Interpreter Core
nosy: +skrah
stage: - needs patch
___
Python
Changes by Martin Panter vadmium...@gmail.com:
--
nosy: +vadmium
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15986
___
___
Python-bugs-list
STINNER Victor added the comment:
This has been fixed in 3.4.2, but shows up in the 3.4.1 documentation.
Well, I didn't want to change Python 3.4.1 documentation, but it looks like
https://docs.python.org/3.4/ is updated after each commit into the 3.4 branch.
For example, new asyncio
New submission from Josh Rosenberg:
To do what?
--
nosy: +josh.rosenberg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15986
___
___
STINNER Victor added the comment:
pymonotonic.patch is large and difficult to review. I prefer to split it into
two parts:
- pytimespec.patch: Change pytime.h to use _PyTimeSpec structure (nanosecond
resolution) instead of _PyTime_timeval structure (microsecond resolution)
-
Changes by STINNER Victor victor.stin...@gmail.com:
Added file: http://bugs.python.org/file36177/pymonotonic-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22043
___
Missy Gomrz added the comment:
Re: is ol
missy orr
--
nosy: +Missy.Gomrz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12312
___
___
STINNER Victor added the comment:
pytimespec.patch removes *private* functions which were exposed in the stable
ABI:
- _PyTime_gettimeofday()
- _PyTime_gettimeofday_info()
It also removes private macros:
- _PyTime_ADD_SECONDS()
- _PyTime_INTERVAL()
In pymonotonic.patch, I reused the same
STINNER Victor added the comment:
Oh, pymonotonic-2.patch didn't get its review link because it depends on
pytimespec.patch which is not merged yet.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22043
Martin Panter added the comment:
This issue was linked from
https://mail.python.org/pipermail/python-dev/2012-September/121781.html. I
was looking for ways to pass read-only memory views into “ctypes” without
copying memory, and came across that thread. Assuming this “buf” attribute
points
Martin Panter added the comment:
For the record, I have been (ab?)using the “c_char_p” type to get the address
of immutable byte strings without copying memory:
from ctypes import *
data = b123\x00abc
pubyte = cast(c_char_p(data), POINTER(c_ubyte))
address = addressof(pubyte.contents)
Drekin added the comment:
I looked to the sourcecode and found the following.
First, the codepath of how interactive loop gets its input follows:
Python/pythonrun.c:PyRun_InteractiveLoopFlags
Python/pythonrun.c:PyRun_InteractiveOneObject
Python/pythonrun.c:PyParser_ASTFromFileObject
Drekin added the comment:
Sorry for formating in the previous message. Repeating…
I looked to the sourcecode and found the following.
First, the codepath of how interactive loop gets its input follows:
Python/pythonrun.c:PyRun_InteractiveLoopFlags
Python/pythonrun.c:PyRun_InteractiveOneObject
New submission from Amrith Kumar:
Environment:
- Linux (Ubuntu 14.04 LTS, x64) running Python 2.7.
- Code uses eventlet.green.subprocess
Code establishes subprocess as:
subprocess.Popen(command,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
Amrith Kumar added the comment:
I'll supply a patch for this proposed change.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22114
___
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22114
___
___
Python-bugs-list
Martin v. Löwis added the comment:
Jonas, why do you say that?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22108
___
___
Python-bugs-list
Martin v. Löwis added the comment:
Installing VS 2010 express was indeed the right solution.
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17371
Drekin added the comment:
Shouldn't there be a Ctrl-C check in Modules/_io/fileio.c:fileio_read*
functions? I think some of these are called by standard sys.stdin.readline().
--
___
Python tracker rep...@bugs.python.org
Akira Li added the comment:
I don't think this is needed nor do I think that it is a good idea to
have a copy() method in the ABCs because they know so little about
their concrete underlying class (perhaps the backing store in the
filesystem or a database). Besides, a user already has
Milan Oberkirch added the comment:
AntoinePitrou: Thanks for the review!
I made the suggested changes and could not resist refactoring the hole thing
(since I plan to spend some time on that file I wanted it to be readable and
pep conform).
--
Added file:
R. David Murray added the comment:
I believe our recent thinking in recent times has been to handle EAGAIN in the
higher level interfaces such as subprocess, not expose them to the caller.
Does python3 have the same problem?
I isn't clear that you have provided enough information to
New submission from Serhiy Storchaka:
Command used to monitor Tcl variable access (trace variable, trace vdelete,
trace vinfo) are deprecated and will likely be removed in a future version of
Tcl. Replacements (trace add variable, trace remove variable, trace info
variable) use slightly
Zachary Ware added the comment:
See also issue20466 (which has a patch for this, but I cannot speak for its
effectiveness).
I'd be in favor of closing that issue and this one as duplicates of #18395, and
noting in #18395 that the embedding example must be updated before that issue
is closed.
Serhiy Storchaka added the comment:
I close this issue because don't want to change topic yet once (and one feature
per issue). Separate issue22115 was opened for adding new trace methods.
--
resolution: - fixed
stage: needs patch - resolved
status: open - closed
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +benjamin.peterson, dw, hynek, kmike, python-dev, scoder, skrah, stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15381
___
Antoine Pitrou added the comment:
ctypes could grow a way to access the Py_buffer API instead.
--
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15986
Serhiy Storchaka added the comment:
Synchronized with tip. Unfortunately there are no common points with recent
issue22003 changes so they should be reverted (except tests).
--
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file36180/bytesio_resized_bytes-4.patch
Antoine Pitrou added the comment:
This sounds like an issue specific to eventlet. There's no reason for the
standard communicate() call to raise EAGAIN, since the created pipes are
blocking.
That said, if the fix is that trivial, I wouldn't be opposed to see it enter
the stdlib (assuming it
STINNER Victor added the comment:
Instead of just catching EAGAIN, you can catch BlockingIOError. In Python 2.7,
it means catching: (EAGAIN, EALREADY, EINPROGRESS, EWOULDBLOCK) errors.
I made a similar change in asyncore recently:
---
changeset: 91833:d422062d7d36
branch: 2.7
parent:
David Beazley added the comment:
There are other kinds of libraries that might want to access the .buf
attribute. For example, the llvmpy extension. Exposing it would be useful.
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Thank you, Milan. The latest patch looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22111
___
Antoine Pitrou added the comment:
Ha, llvmpy... Yes, it could be useful. It's dangerous too, especially since the
buffer isn't necessarily contiguous.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15986
David Beazley added the comment:
Well, a lot of things in this big bad world are dangerous. Don't see how this
is any more dangerous than all of the peril that tools like ctypes and llvmpy
already provide.
--
___
Python tracker
David Beazley added the comment:
One of the other goals of memoryviews is to make memory access less hacky. To
that end, it would be nice to have the .buf attribute available given that all
of the other attributes are already there. I don't see why people should need
to do some even more
Antoine Pitrou added the comment:
Le 31/07/2014 11:24, David Beazley a écrit :
Well, a lot of things in this big bad world are dangerous. Don't see
how this is any more dangerous than all of the peril that tools like
ctypes and llvmpy already provide.
The point of the buffer API is to make
Amrith Kumar added the comment:
I see three comments, one from r.david.murray, one from haypo and one from
pitrou. I'll try and address all three.
r.david.murray:
The code in question is in
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/processutils.py#L177-L189
STINNER Victor added the comment:
However, I submit to you that this is NOT an eventlet issue. (...) capture
all exceptions that would point a user to retry (such as EAGAIN and EINTR)
and mask them and return some EFATAL.
You cannot get EAGAIN on a blocking file descriptor and subprocess
eryksun added the comment:
cast calls ctypes._cast(obj, obj, typ). _cast is a ctypes function pointer
defined as follows:
_cast = PYFUNCTYPE(py_object,
c_void_p, py_object, py_object)(_cast_addr)
Since cast makes an FFI call that converts the first arg to c_void_p,
Shiz added the comment:
After some further investigation it seems the which-clause fails when given a
relative path. Since we should expect $HOSTPYTHON to be present in the first
place, I modified the patch a bit to special-case the $HOSTPYTHON check, and
fall back on the other interpreters
Changes by Amrith Kumar amr...@tesora.com:
--
title: You cannot call communicate() safely after receiving EAGAIN - You
cannot call communicate() safely after receiving an exception (EINTR or EAGAIN)
___
Python tracker rep...@bugs.python.org
Amrith Kumar added the comment:
haypo; no argument from me. I just updated the description to make it more
exact.
I may have received EINTR or EAGAIN.
In either event, I need to debug some more and try and do a clean repro and
then figure out a proper fix.
In the meanwhile, I proposed a fix
Steve Dower added the comment:
At one point the version of OpenSSL on svn.python.org did not have the correct
makefiles for a 64-bit Windows build, but this was resolved. You also don't
need 64-bit Perl to generate these files, and the file has been renamed to
prepare_ssl.py and appears to
R. David Murray added the comment:
By the definition of the (blocking) communicate API, communicate can only be
called once (it feeds in all the input, and reads all the output).
--
___
Python tracker rep...@bugs.python.org
Amrith Kumar added the comment:
r.david.murray, I guess the issue we have is that something (hypothesis:
eventlet) is causing the blocking API to communicate() to throw an EAGAIN.
This (https://bugs.launchpad.net/nova/+bug/1271331) is the bug that was fixed a
while ago in OpenStack that
Zachary Ware added the comment:
The patch applies and compiles cleanly, and I finally tracked down what was
causing the errors I reported yesterday: os_utime_impl was changed to use
Py_RETURN_NONE instead of just setting return_value = Py_None, so Windows
skipped the exit routine and left an
Guido van Rossum added the comment:
asyncio has an explicit exemption from the general rule that bugfixes
should not add new features. This is because of the provisional status of
the PEP. We'll stop doing this once 3.5 is out.
I don't know what's up with the online docs.
On Thu, Jul 31, 2014
Guido van Rossum added the comment:
You need to learn when to give up. :-)
I wasn't the one who added a copy() method to other containers. I personally
despise almost all uses of copying (including the entire copy module, both
deep and shallow copy functionality). I much prefer to write
Daniel Greenfeld added the comment:
First, if there is documentation that says, 3.4.1, doesn't it make sense that
the documentation should only be for 3.4.1? Which means that this create_task
documentation should be reverted in the 3.4.1 documentation to match the 3.4.1
specification.
Second
New submission from Antoine Pitrou:
Currently, it is not possible to take a weakref to a PyCFunction object.
However, those objects already have full GC support, so it wouldn't be silly to
add weakref support to them.
(this came in the context of numba, which generates such C functions
Charles-François Natali added the comment:
Antoine Pitrou added the comment:
Enabling the warnings may be a good incitation for other people to fix them ;)
That was my intention...
Can I push it, and let warnings be fixed on a case-by-case basis?
--
Changes by Serhiy Storchaka storch...@gmail.com:
--
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15862
___
___
Charles-François Natali added the comment:
Closing, since it's likely a kernel bug.
--
resolution: - third party
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19923
Changes by Serhiy Storchaka storch...@gmail.com:
--
components: +Windows
stage: - test needed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19062
___
Charles-François Natali added the comment:
Closing, I haven't seen this in a while.
--
resolution: - out of date
stage: needs patch - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15152
Mark Lawrence added the comment:
Is there anything we can do here, do we close it as out of date or what?
--
nosy: +BreamoreBoy
type: - behavior
versions: +Python 3.4, Python 3.5 -Python 3.3
___
Python tracker rep...@bugs.python.org
Lita Cho added the comment:
Hey! So I have been investigating this bug, but I wanted to know is the issue
the fact that korka wants to create multiple turtles or do you really want to
use multiple threads with Turtle? I feel like this crash is due to Tkinter not
being thread safe and I am not
Lita Cho added the comment:
I also want to note that you can create duplicate turtles by using clone, and I
am not sure why you would use multiple inheritance to draw more than 1 turtle
running around. I didn't think turtle was meant to be used this way. In order
to draw multiple turtles, I
Mark Lawrence added the comment:
Is this still an issue with Python 2.7.8? (I don't have 2.7 or linux to test on)
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17085
Serhiy Storchaka added the comment:
What would you say about multi_nagle_simplify.patch, Antoine?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20540
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: docs@python - haypo
stage: needs patch - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21860
___
Mark Lawrence added the comment:
Couldn't part of the patch be simplified to:-
if basename or os.path.isdir(dirname):
yield pathname
or have I misread it?
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
Mark Lawrence added the comment:
What if anything needs to be done here?
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18004
___
Mark Lawrence added the comment:
Is this still a problem with later versions of Python on this platform?
--
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18188
Charles-François Natali added the comment:
Thanks for the reminder Mark.
Yes, it is probably still an issue with the latest 2.7 release.
There were actually two issues:
- send send()/sendall() call didn't block because the test doesn't write enough
data: we have since added a SOCK_MAX_SIZE
Jonas Jelten added the comment:
Martin, i think the most intuitive and easiest way for working with strings in
C are just char arrays.
Starting with the main() argv being char*, probably most programmers just go
with char* and all the encoding just works.
This is because contact with encoding
Antoine Pitrou added the comment:
Le 31/07/2014 13:51, Charles-François Natali a écrit :
Enabling the warnings may be a good incitation for other people to fix them
;)
That was my intention...
Can I push it, and let warnings be fixed on a case-by-case basis?
+1 from me.
--
Changes by Antoine Pitrou pit...@free.fr:
--
keywords: +easy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22116
___
___
Python-bugs-list mailing
Serhiy Storchaka added the comment:
Next iteration of the patch addressed Victor's and Akira's comments.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21859
___
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file36183/pyio_fileio_5.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21859
___
eryksun added the comment:
Extending byref to support bytes and str objects sounds reasonable.
Here's another workaround to pass a bytes object with an offset:
from ctypes import *
from ctypes.util import find_library
class offset:
def __init__(self, arg, offset):
Roundup Robot added the comment:
New changeset 6b2cafab7a9f by Antoine Pitrou in branch 'default':
Issue #22111: Assorted cleanups in test_imaplib. Patch by Milan Oberkirch.
http://hg.python.org/cpython/rev/6b2cafab7a9f
--
nosy: +python-dev
___
Antoine Pitrou added the comment:
This is now pushed.
--
resolution: - fixed
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22111
___
Roundup Robot added the comment:
New changeset 20fd13242a45 by Antoine Pitrou in branch 'default':
Simplify code in multiprocessing.Connection.send_bytes().
http://hg.python.org/cpython/rev/20fd13242a45
--
___
Python tracker rep...@bugs.python.org
Dan O'Reilly added the comment:
I've attached an updated patch based on your review comments; there's now a
unit test with a non-default chunksize, the chunking algorithm is more
readable, and the same code path is used no matter what chunksize is provided.
I've also updated the test script
Changes by Dan O'Reilly oreil...@gmail.com:
Removed file: http://bugs.python.org/file36065/test_mult.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11271
___
Changes by Dan O'Reilly oreil...@gmail.com:
Added file: http://bugs.python.org/file36185/test_mult.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11271
___
New submission from STINNER Victor:
To prepare Python to add support of monotonic clock in pytime.h, I propose to
rewrite pytime.h to use a new _PyTimeSpec structure which has a resolution of 1
nanosecond on only work on integers.
Currently, pytime.h uses a _PyTime_timeval structure which has
Changes by Antoine Pitrou pit...@free.fr:
--
type: - enhancement
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22117
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +belopolsky, tim.peters
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22117
___
___
Antoine Pitrou added the comment:
Why not simply use $SHELL?
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16255
___
___
Mark Lawrence added the comment:
A different patch is still needed for 3.4.
--
nosy: +BreamoreBoy
type: - behavior
versions: +Python 3.5 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18651
Martin Panter added the comment:
Interesting that “cast” accepts a byte string. If this is intended behaviour,
it would be good to document that. Currently it says it takes “an object that
can be interpreted as a pointer”.
--
___
Python tracker
STINNER Victor added the comment:
pytimespec.patch become too large, I splitted this patch into a new issue:
issue #22117. If this issue is rejected, I will rewrite pymonotonic-2.patch to
use the _PyTime_timeval structure.
--
___
Python tracker
Mark Lawrence added the comment:
Is there any possibility of getting this into 3.5? If it helps I've always got
time on my hands so if nothing else I could do testing on Windows 8.1.
--
nosy: +BreamoreBoy, zach.ware
versions: +Python 3.5 -Python 3.4
Mark Lawrence added the comment:
Following on from msg185817 I'd suggest this is closed.
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7944
___
Mark Lawrence added the comment:
The deprecation warnings are coming from the various os calls so are nothing to
do with test_shutil. I think this can be closed as not a bug.
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
Changes by Brian Curtin br...@python.org:
--
nosy: -brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7944
___
___
Python-bugs-list
Changes by Brian Curtin br...@python.org:
--
nosy: -brian.curtin
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7897
___
___
Python-bugs-list
STINNER Victor added the comment:
Oh, I forgot to mention that the patch of the issue #22043 also changes
_PyTimeSpec_get_time() to use clock_gettime(CLOCK_REALTIME) which has a
resolution of 1 nanosecond.
_PyTimeSpec_get_time() already uses GetSystemTimeAsFileTime() which has a
resolution
STINNER Victor added the comment:
The effective* resolution
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22117
___
___
Python-bugs-list
STINNER Victor added the comment:
What I'd really like to see in CPython is that the internal storage (and the
way it's exposed in the C-API) is just raw bytes (= char*).
Python is portable, we care of Windows. On Windows, wchar_t* is the native type
for strings (ex: command line,
1 - 100 of 111 matches
Mail list logo
