New submission from Vitaly:
Python 2.6.7 on Mac OS 10.7.4 running on MacBookPro laptop.
run attachment as: python test_pipe_error.py
The test() function makes multiple calls to _execute_child() in a loop. Every
other call to _execute_child() fails with:
=
os.read(3, 1048576) self pid
Vitaly added the comment:
Per Charles-François Natali (neologix), I tried the following:
1. Reduce the initial read size argument (rSize in my code snippet) from
1048576 (1MB, the same amount as used by subprocess.Popen._executeChild) to
100: the problem appears to go away (could be just
Changes by Vitaly :
Added file: http://bugs.python.org/file27170/test_fork_pipe_error.py
___
Python tracker
<http://bugs.python.org/issue15896>
___
___
Python-bugs-list m
Vitaly added the comment:
os.read() must also be allocating the read buffer in addition to calling the
system read() function. I just uploaded a new test script
"test_fork_pipe_error.py" that iterates in increasing or decreasing order over
initial pipe read sizes and accumulates f
Vitaly added the comment:
I wrote a C-language program to reproduce this issue on Mac OS without Python.
It reproduces the issue in both increasing and decreasing order of initial read
sizes, and it reliably reproduces it for each KB from 128KB to 1024KB ; the
Python version reproduced the
Vitaly added the comment:
The C-language program for reproducing the same issue is attached as
test_fork_pipe_error.cpp
--
___
Python tracker
<http://bugs.python.org/issue15
Vitaly added the comment:
I used g++ to compile test_fork_pipe_error.cpp on both Mac OS and on Linux.
EINVAL showed up only on Mac OS.
--
___
Python tracker
<http://bugs.python.org/issue15
Vitaly added the comment:
By the way, the existing code in subprocess.Popen (at least on 2.6.7) reads the
pipe incorrectly: It doesn't loop to read all the data until EOF -- it only
loops over EINTR until it gets a single successful os.read() call. However,
since this is a pipe read (
Vitaly added the comment:
I filed this issue with apple: Problem ID: 12274650:
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/64/wo/VE1RGG9qEL5OS9KdzFSDHw/19.66
--
___
Python tracker
<http://bugs.python.org/issue15
Vitaly added the comment:
Apple bug report URL correction:
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/64/wo/VE1RGG9qEL5OS9KdzFSDHw/17.66
--
___
Python tracker
<http://bugs.python.org/issue15
Vitaly added the comment:
Sorry, I don't know why the URL comes out all messed up. I can't seem to find
the correct syntax for this.
--
___
Python tracker
<http://bugs.python.o
New submission from Vitaly:
subprocess.Popen (at least on 2.6.7) reads the pipe incorrectly: It doesn't
loop to read all the data until EOF -- it only loops over EINTR until it gets a
single successful os.read() call. However, since this is a pipe read (not a
real file read), the s
Vitaly added the comment:
Filed http://bugs.python.org/issue15918 for the incorrect pipe read logic in
subprocess.Popen.
--
___
Python tracker
<http://bugs.python.org/issue15
Vitaly added the comment:
> What's wrong with working around this bug by reading a smaller amount? How
> much data is there supposed to be?
This makes sense for working around the issue. Even in the blocking-read case,
such as in subprocess.Popen, attempting to read a 1MB chunk o
Vitaly added the comment:
Also, attempting to read a 1MB chunk of data in a single os.read call forces
os.read() to unnecessarily allocate a huge !MB buffer (even if only for a short
lifetime). Using something like 4KB read calls in a loop is more practical
(and looping is necessary anyway
Changes by Vitaly :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue15896>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vitaly added the comment:
My bug report refers to the following code block in subprocess.py. The problem
is the same in 2.6.7 and 2.7.3:
=== From subprocess.py in Python 2.7.3 Source Distribution:
# Wait for exec to fail or succeed; possibly raising exception
Vitaly added the comment:
Sorry, there is no traceback. The issue was identified in code review.
'man 2 read' states:
===
The system guaran-
tees to read the number of bytes requested if the descriptor references a
normal file that has that many bytes left before the e
Vitaly added the comment:
The prior 'man 2 read' quote was from Mac OS X;
On amazon (centos) Linux, 'man 2 read' makes the same claim, albeit in
different verbiage:
===
It is not an error if this number is smaller than the number of bytes
requested; this may happen for e
Vitaly added the comment:
> In practice I doubt this matters much as this error string is likely to be
> less than one page (depends on pathnames involved) but it is still
technically incorrect as written.
Agreed. Thank you.
--
___
Python t
Vitaly added the comment:
In the work-around, we need to watch out for what 'man 2 read' on Mac OS refers
to as "normal file":
==
Upon successful completion, read(), readv(), and pread() return the number of
bytes actually read and placed in the buffer. *The system
Vitaly added the comment:
> Nothing, except that there are probably other places in the stdlib
> where we can get bitten by this bug. Note that this should eventually
> be done for another reason, see http://bugs.python.org/issue15918
For greatest benefit, I think that the work-around
Vitaly added the comment:
> The workaround should not be implemented in os.read because it is a very thin
> wrapper around the system call and should stay that way.
Although this issue was initially filed as "Sporadic EINVAL in nonblocking pipe
os.read when forked child fails on M
Vitaly added the comment:
> And what kind of workaround do you propose?
[os.read(fd, buffersize)]
I am thinking about these options:
Option 1:
Fix breakages as they are discovered at higher level (above os.read) as needed
in places where usage semantics are known, and address the issue
Vitaly added the comment:
> It's not Python's job to workaround stupid platform bugs...
> So I'd suggest closing this, and urge people to complain to the OS-X folks
After digesting the postings, I've come around to this point of view as well,
so closing as &quo
Changes by Vitaly :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15896>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Vitaly:
_connect_unixsocket() (see below) does not use socktype value that was passed
into SysLogHandler.__init__():
def _connect_unixsocket(self, address):
self.socket = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
# syslog may require either DGRAM
Vitaly added the comment:
SOCK_DGRAM causes log messages larger than about 2000 bytes to be dropped
altogether on MacOS X 10.7.5 and to be truncated to 2081 bytes on Linux (tested
with Amazon's linux, which is based on centos). This is quite unfortunate,
since many exception traceback
Vitaly added the comment:
Is this issue fixed in python 2.7.10? I am experiencing strange race conditions
in code that combines threads with multiprocessing pool, whereby a thread is
spawned by each pool worker. Running on latest Mac OS X.
--
nosy: +vitaly
New submission from Vitaly:
Python 2.7 documentation is VERY misleading about the functionality of
assertItemsEqual. The implementation only compares item counts, but the
documentation actually claims to compare not only the counts, but the actual
sorted elements themselves. This
Changes by Vitaly :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue27060>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Vitaly :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issue27060>
___
___
Py
Vitaly added the comment:
Python 2.7 documentation is VERY misleading about the functionality of
assertItemsEqual. It actually claims to compare not only the counts, but the
actual sorted elements themselves. This documentation mislead my group to use
this method for comparing the elements
Vitaly added the comment:
I opened http://bugs.python.org/issue27060 regarding the erroneous
documentation of assertItemsEqual in python 2.7.
--
___
Python tracker
<http://bugs.python.org/issue17
Vitaly added the comment:
According to comment http://bugs.python.org/issue17866#msg188052 in #17866, the
maintainers renamed `assertItemsEqual` to `assertCountEqual` somewhere in the
3.x development timeframe. They apparently latched on to the implementation of
`assertItemsEqual` in 2.7.x
Vitaly added the comment:
Thanks Terry, your assessment is correct. The maintainers appear to have drawn
the wrong conclusion in #17866, which mislead me about the existing
assertItemsEqual in 2.7, which appears to work correctly after all!
import unittest as u
class Test(u.TestCase):
def
Vitaly added the comment:
I think that we can close this as not a bug, as concerning 2.7. However, I
think that 3.x made the wrong decision when it renamed assertItemsEqual with
assertCountEqual, which now misleads users into thinking that it compares
counts
Vitaly added the comment:
Folks, assertCountEqual sounds like a really bad name. It misleads users into
thinking that it only compares the number of elements in each sequence, whereas
it actually asserts that equivalent items are present in both sequences,
regardless of order. The original
New submission from Vitaly:
Somewhere in 3.x assertItemsEqual was renamed to assertCountEqual.
assertCountEqual sounds like a really inappropriate, misleading name for what
it does. It misleads users into thinking that it only compares the number of
elements in each sequence, whereas it
Vitaly added the comment:
Yes, this caused me to examine Counter, which I had not used before, and now I
understand it, too. However, the new name by itself does not sufficiently
reflect the subtlety of element-by-element counts, which does a disservice to
the readability of test code
Vitaly added the comment:
... and an unnecessary incompatibility between 2.7 and 3.x
--
___
Python tracker
<http://bugs.python.org/issue27060>
___
___
Python-bug
Vitaly added the comment:
The new name by itself does not sufficiently reflect the subtlety of
element-by-element counts, which does a disservice to the readability of test
code. And it's also an unnecessary incompatibility between 2.7 an
Vitaly added the comment:
As far as I can tell, issue #10242 deals with the renaming. I think that the
arguments for the new name are flawed (sorry to be so blunt, but I don't know
how else to express it).
Regardless of whether it's Count or Counts, to most people it sounds like i
Vitaly added the comment:
If there really is a good systemic reason why names like assertItemsEqual and
assertElementsEqual are flawed, then assertFrequencyCountsEqual might be a
less-ambiguous alternative.
--
___
Python tracker
<h
Vitaly added the comment:
Gentlemen, the point is that the name of a function should be all that is
necessary to unambiguously understand what this method does without having to
know that it's implemented in terms of collections.Counter or any other
internal detail like that. That&#x
Vitaly added the comment:
By leaps and bounds, I like assertUnorderedEqual versus assertCountEqual, which
is terribly misleading. The first, and simplest, thing that comes to my mind
from the word Count by itself is the count of all elements in a sequence (i.e.,
its length), certainly not
Vitaly added the comment:
When I read "Unordered", it makes me think of collections, including sequences
and sets.
--
___
Python tracker
<http://bugs.python.o
Vitaly added the comment:
Why do you say that "we aren't dealing with python sets"? Try:
import unittest as u
class Test(u.TestCase):
def test_equal_count_of_same_elements(self):
self.assertItemsEqual(set([1,2,3]), set([1,2,3]))
def test_equal_count_of_differen
Vitaly added the comment:
$ python assert_items_equal_test.py
FF.
==
FAIL: test_different_count (__main__.Test)
--
Traceback (most recent call last):
File
Vitaly added the comment:
The preceding results are via Python 2.7.10
--
___
Python tracker
<http://bugs.python.org/issue27071>
___
___
Python-bugs-list mailin
Vitaly added the comment:
Same results on Python.org's Python 3.5.1 shell:
>>> class Test(u.TestCase):
... def test_equal_count_of_same_elements(self):
... self.assertCountEqual(set([1,2,3]), set([1,2,3]))
... def test_equal_count_of_different
Vitaly added the comment:
With missing last line, this time:
==
FAIL: test_equal_count_of_different_elements (__main__.Test)
--
Traceback (most recent call
Vitaly added the comment:
I think that assertUnorderedEqual would contrast nicely with assertSequenceEqual
--
___
Python tracker
<http://bugs.python.org/issue27
Vitaly added the comment:
assertSequenceEqualUnordered is not a good fit, because it doesn't follow the
de facto naming convention, whereby "Equal" should be the suffix.
Also assertSequenceEqualUnordered would be considered an oxymoron, since the
word "Sequence&quo
New submission from Vitaly Kruglikov :
assertCountEqual is a horribly misleading name because it misleads the
programmer and reader of the test code into thinking that it only compares the
counts of the elements.
It's name misrepresents what it does in a really ba
Change by Vitaly Zdanevich :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue39518>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Vitaly Zdanevich :
Please save our eyes. And batteries. Do not ignore this property of useragent
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme
--
assignee: docs@python
components: Documentation
messages: 361177
nosy: Vitaly Zdanevich
Vitaly Zdanevich added the comment:
Added bug report to their repo
https://github.com/python/python-docs-theme/issues/43
--
___
Python tracker
<https://bugs.python.org/issue39
Change by Vitaly Kruglikov :
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue38240>
___
___
Python-bugs-list mailing list
Unsubscrib
Vitaly Kruglikov added the comment:
Reopened per request from ammar2
--
___
Python tracker
<https://bugs.python.org/issue38240>
___
___
Python-bugs-list mailin
Vitaly Kruglikov added the comment:
Re-opened, thanks!
On Fri, Sep 20, 2019 at 3:01 PM Ammar Askar wrote:
>
> Ammar Askar added the comment:
>
> Hey Vitaly, not sure if you're the author of the original bug here:
> https://bugs.python.org/issue27071
>
> Cou
Vitaly Kruglikov added the comment:
Well, when you do tab-completion in unit tests on `self.` and
`assertCountEqual` pops up, it sure sounds a lot like it's going to compare
just the count of the items. The point is that the name of the function is
not self-documenting, hence "misle
New submission from Vitaly Kruglikov :
```
import copy
import ssl
copy.copy(ssl.create_default_context())
```
results in
`TypeError: can't pickle SSLContext objects`
This prevents me from being able to `copy.deepcopy()` an object that references
`ssl.SSLContext`.
The apparent root cau
Change by Vitaly Kruglikov :
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issue33023>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Vitaly Kruglikov :
--
assignee: -> christian.heimes
components: +SSL
nosy: +christian.heimes
___
Python tracker
<https://bugs.python.org/issu
New submission from Vitaly Kruglikov :
`asyncio.WriteTransport.set_write_buffer_limits()` uses an unintuitive order of
the args (high, low). I would expect `low` to be the first arg, especially
since `asyncio.WriteTransport.get_write_buffer_limits()` returns them in the
opposite order. This
New submission from Vitaly Kruglikov :
```
In [9]: from urllib.parse import urlencode, parse_qs
In [10]: import ast, ssl
In [11]: d = dict(cert_reqs=ssl.CERT_NONE)
In [12]: urlencode(d)
Out[12]: 'cert_reqs=VerifyMode.CERT_NONE'
In [25]: parse_qs('cert_reqs=VerifyMode.CER
Vitaly Kruglikov added the comment:
Hi Christian, thank you for following up. Here is my use case, and perhaps you
can suggest something else that will work:
I am refactoring the transport layer in the Pika AMQP client library. The user
provides an ssl.SSLContext instance for connecting to
Vitaly Kruglikov added the comment:
Also, updating ssl.SSLContext documentation about intentional inability to copy
generically and suggestion how to go about it if you need to obtain a clone or
similar would be terrific and save developers time so they won't run into this
gotcha
Vitaly Kruglikov added the comment:
> What would those side-effects be?
Christian Heimes suggested that
> A context contains elements that can't be cloned easily, e.g. session
> resumption tickets.
My concern then would be potential side-effects from such session resumptio
New submission from Vitaly Kruglikov :
I need to write a test for my client to make sure it's non-blocking ssl
interactions are able to survive SSL renegotiation. However, I can't seem to
find anything in our python ssl API that calls `SSL_renegotiate()` in order to
force ren
Vitaly Kruglikov added the comment:
> By the way, renegotiation is a problematic and has been replaced by rekeying
> in TLS 1.3
How can I trigger rekeying via python ssl? Many thanks.
--
___
Python tracker
<https://bugs.python.org/i
Vitaly Kruglikov added the comment:
> For extra fun, openssl itself doesn't fully support renegotiation on duplex
> connections ...
The necessitated modification to the application protocol on that thread sounds
like an OpenSSL cop-out. There is no good reason that OpenSSL should
New submission from Vitaly Kruglikov :
There doesn't appear to be an ordained mechanism for getting notified when a
Transport's (or WriteTransport's) write buffer drains to zero (i.e., all output
data has been transferred to socket). I don't want to hijack
`set_write_buffe
Vitaly Kruglikov added the comment:
Thank you for following up. My use case is this:
In the Pika AMQP client package, we have a blocking AMQP connection adapter -
`BlockingConnection` - wrapped around an asynchronous AMQP connection adapter.
Presently, BlockingConnection is wrapped around
Vitaly Kruglikov added the comment:
... or `events.AbstractEventLoop.run_one_iteration()`.
--
___
Python tracker
<https://bugs.python.org/issue33118>
___
___
Vitaly Kruglikov added the comment:
> 'events.AbstractEventLoop.run_one_step()'
> This is highly unlikely to ever happen.
Sure, I can see how that could be a problem with other underlying
implementations, such as Twisted reactor. Just
Vitaly Kruglikov added the comment:
I'll have to settle for `set_write_buffer_limits(0, 0)` for my blocking wrapper
case.
I think that 'write_buffer_drained' callback is a good idea, though.
--
___
Python tracker
<https
Vitaly Kruglikov added the comment:
Yet another paradigm is the likes of `GSource` in gnome's glib. GSource "tasks"
added to the event loop are polled by the event loop for readiness before the
event loop blocks on select/epoll/etc.. The ones that are ready are removed
fr
Vitaly Kruglikov added the comment:
It would be very helpful to make a statement in SSLContext's documentation to
the effect that it's not copyable. This is frankly the first time I run into a
non-copyable object.I spend quite a bit of time researching this after
implementing
Vitaly Kruglikov added the comment:
Thank you, I'll consider myself having been warned :)
On Sat, Mar 24, 2018, 7:28 AM Christian Heimes
wrote:
>
> Christian Heimes added the comment:
>
> Serhiy,
> I don't understand what you are trying to tell me. "cannot se
New submission from Vitaly Kruglikov :
I see this exception on the terminal:
```
exception calling callback for
Traceback (most recent call last):
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/concurrent/futures/_base.py",
li
New submission from Vitaly Kruglikov :
I am seeing this with `socket.AF_INET6` on Windows running python 2.7.14
```
[00:02:33] File "C:\projects\pika\pika\adapters\host_tcp_connector.py", line
153, in _check_already_resolved
[00:02:33] socket.inet_pton(socket.AF_INET6, 'loc
Change by Vitaly Kruglikov :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue33206>
___
___
Python-bugs-list mailing list
Unsubscrib
Vitaly Kruglikov added the comment:
This behavior goes against the socket documentation
https://docs.python.org/2/library/socket.html which states "Supported values
for address_family are currently AF_INET and AF_INET6. If the IP address string
ip_string is invalid, *socket.error* wi
Vitaly Kruglikov added the comment:
Zachary, thank you for noticing that Twisted is involved. inet_pton definitely
exists on Windows 2.7.14, but it turns out that Twisted monkey-patches it if
`socket.inet_pton(socket.AF_INET6, "::")` fails.
Aha! - but this suggests that Windo
Vitaly Kruglikov added the comment:
Indeed, confirmed no `inet_pton()` on Windows in Python 2.7 :(.
--
___
Python tracker
<https://bugs.python.org/issue33
Vitaly Murashev added the comment:
Guys, a couple questions ...
I want to suggest new patches for python3.7 and python2.7 with regression tests
included
What is proper way to do it now, in year 2018 ?
May I do it on github.com ? Should I submit new issue for that there ?
Or am I still supposed
Vitaly Murashev added the comment:
> Vitaly, in the future please use gender-neutral words
Mariatta, OK, got it, I am sorry for that. I am not a native speaker.
--
___
Python tracker
<https://bugs.python.org/issu
Change by Vitaly Murashev :
--
versions: +Python 2.7, Python 3.7, Python 3.8 -Python 3.3, Python 3.4
___
Python tracker
<https://bugs.python.org/issue18
Vitaly Murashev added the comment:
Pull-requests for 2.7, 3.7 and master submitted on github,
all tests look passed, so
Python dev-team,
please, take a look.
--
___
Python tracker
<https://bugs.python.org/issue18
Vitaly Murashev added the comment:
> Only a PR for master is needed.
Serhiy Storchaka, thanks for advice,
I cancelled unnecessary PRs.
--
___
Python tracker
<https://bugs.python.org/issu
New submission from Vitaly Murashev:
Recently I found out that it not possible to debug python code if it is a part
of zip-module.
Python version being used is 3.3.0
Well known GUI debuggers like Eclipse+PyDev or PyCharm are unable to start
debugging and give the following warning:
---
pydev
New submission from Vitaly Murashev:
Cannot compile _ssl module when openssl version > 1.0 and it is configured with
turned on macro OPENSSL_NO_DEPRECATED
Everything looks like in recent versions of openssl routine
'CRYPTO_set_id_callback' has gone away.
Pa
Vitaly Murashev added the comment:
unit-test attached.
There are 3 tests inside it: 2 failed, 1 succeeded.
According to this test results it becomes clear that specified issue is
reproduced only with zip modules which contain precompiled bytecode inside
(pyc-files)
--
Added file
New submission from Vitaly Murashev:
When I use 'zip' command-line tool on my Ubuntu 10.04 to pack a directory in
zip-archive, it internally assigns '0x41ed0010' attributes for it.
0x41ed0010 = 0x41ed << 0xfff + 0x0010
Where:
0x41ed - unix attributes (40755)
New submission from Vitaly Isaev:
RPM Subpackages are very useful when you maintain the big project on the
RHEL-kind Linux distro and you need to sparse the project into several
differing packages (for instance - , -libs, -devel, -debuginfo).
It would be convenient to do the same in a purely
Vitaly Murashev added the comment:
patch suggested (over 3.3.0 code base).
Without patch test fails, with patch - passed
--
components: -Library (Lib)
keywords: +patch
Added file: http://bugs.python.org/file31781/zipimport.diff
___
Python tracker
Vitaly Isaev added the comment:
I confirm the urgent need in this feature.
--
nosy: +vitalyisaev2
___
Python tracker
<http://bugs.python.org/issue20337>
___
___
Vitaly Babiy added the comment:
Why not just remove the removal of the timeout.
--
nosy: +vbabiy
___
Python tracker
<http://bugs.python.org/issue5103>
___
___
1 - 100 of 120 matches
Mail list logo
