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
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
Change by Vitaly Kruglikov :
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue38240>
___
___
Python-bugs-list mailing list
Unsubscrib
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 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
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
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
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
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:
> 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
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 Kruglikov added the comment:
Indeed, confirmed no `inet_pton()` on Windows in Python 2.7 :(.
--
___
Python tracker
<https://bugs.python.org/issue33
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:
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
Change by Vitaly Kruglikov :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue33206>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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
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
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:
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:
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:
> '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:
... or `events.AbstractEventLoop.run_one_iteration()`.
--
___
Python tracker
<https://bugs.python.org/issue33118>
___
___
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
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:
> 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
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
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:
> 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
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:
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
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
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
Change by Vitaly Kruglikov :
--
assignee: -> christian.heimes
components: +SSL
nosy: +christian.heimes
___
Python tracker
<https://bugs.python.org/issu
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
Vitaly Murashev added the comment:
> And why not open MS_WIN64 to any Windows compiler
It would be very good idea
Patches suggested here are just the drafts which just work.
Actually I don't believe they will be accepted, so just dropped here for
Vitaly Murashev added the comment:
We (crystax.net) are building Python for Windows completely by cmake and MinGW
using PC/pyconfig.h without any configure scripts
--
___
Python tracker
<http://bugs.python.org/issue28
Changes by Vitaly Murashev :
Added file: http://bugs.python.org/file44814/callproc.c.2.7.mingw.patch
___
Python tracker
<http://bugs.python.org/issue28271>
___
___
Pytho
New submission from Vitaly Murashev:
Structured exception handling not supported by MinGW,
and as a result file 'Modules/_ctypes/callproc.c' is not compilable by MinGW
without patching
As I know the patch was initially introduced in Google's repo,
and fixed file 'callproc
New submission from Vitaly Murashev:
'posixmodule.c' is written pretty well, but some important MinGW realated macro
are missed.
And as a result an attempt to complile Modules/posixmodule.c by MinGW fails.
So suggested patch (for 3.5.2 and 2.7.12)
just turns on missed MinGW rel
Changes by Vitaly Murashev :
Added file: http://bugs.python.org/file44812/posixmodule.c.2.7.mingw.patch
___
Python tracker
<http://bugs.python.org/issue28270>
___
___
Changes by Vitaly Murashev :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue28267>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Vitaly Murashev :
--
type: -> compile error
___
Python tracker
<http://bugs.python.org/issue28269>
___
___
Python-bugs-list mailing list
Unsubscrib
Vitaly Murashev added the comment:
Patch suggested here is actually the most trivial as it could be.
And at the same time we (crystax.net) can prove that after this patch Python
being compiled by MInGW for 64-bit Windows actually works well. There are other
minor fixes but this one is the
Changes by Vitaly Murashev :
Added file: http://bugs.python.org/file44809/dynload_win.c.2.7.mingw.patch
___
Python tracker
<http://bugs.python.org/issue28269>
___
___
New submission from Vitaly Murashev:
Attempt to complile Python/dynload_win.c by MinGW fails
due to static reimplementation of strcasecmp function in this file:
---
/* Case insensitive string compare, to avoid any dependencies on particular
C RTL implementations */
static int strcasecmp
Changes by Vitaly Murashev :
Added file: http://bugs.python.org/file44806/pyconfig.h.2.7.mingw.patch
___
Python tracker
<http://bugs.python.org/issue28267>
___
___
Pytho
New submission from Vitaly Murashev:
Hi,here the issue:
We (crystax.net) use custom builds of cpython,
which for windows are compiled by MinGW with pyconfig.h taken from PC/pyconfig.h
And for 32-bit Windows everything works well, but for 64-bit Windows - doesn't.
The root cause of this iss
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
Vitaly added the comment:
I think that assertUnorderedEqual would contrast nicely with assertSequenceEqual
--
___
Python tracker
<http://bugs.python.org/issue27
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:
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:
The preceding results are via Python 2.7.10
--
___
Python tracker
<http://bugs.python.org/issue27071>
___
___
Python-bugs-list mailin
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:
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:
When I read "Unordered", it makes me think of collections, including sequences
and sets.
--
___
Python tracker
<http://bugs.python.o
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:
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:
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:
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:
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:
... and an unnecessary incompatibility between 2.7 and 3.x
--
___
Python tracker
<http://bugs.python.org/issue27060>
___
___
Python-bug
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
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:
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
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:
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:
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:
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:
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
Changes by Vitaly :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issue27060>
___
___
Py
Changes by Vitaly :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue27060>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
New submission from Vitaly Belman:
Possibly related to: http://bugs.python.org/issue18264
The following code:
>>> import IntEnum from enum
>>> from enum import IntEnum
>>> class a(IntEnum): a=0
>>> json.loads(json.dumps({"x": a.a}))
Produces
Vitaly Belman added the comment:
Note: Using pip library enum34
--
___
Python tracker
<http://bugs.python.org/issue25281>
___
___
Python-bugs-list mailin
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 Murashev:
Current time on my machine with Windows7x64 is set to year 2045 for test
purposes.
Since Python3.5(amd64) I have an OverflowError when I am trying to call
datetime.datetime.now()
It looks like a regress since there was no such error on Python3.4.3
Could
Changes by Vitaly Murashev :
--
title: [VS2013] Py_InitializeEx causes fatal error being from winnt-service ->
[VS2013] Py_InitializeEx causes fatal error being called from winnt-service
___
Python tracker
<http://bugs.python.org/issu
Vitaly Murashev added the comment:
patch suggested
--
keywords: +patch
Added file: http://bugs.python.org/file39854/pythonrun.c.diff
___
Python tracker
<http://bugs.python.org/issue24
Vitaly Murashev added the comment:
More details:
previously Python3.4.3 was compiled in my environment using compiler from
VisualStudio-2005 and everything worked well. The crash has come right after
changing compiler to the one from VisualStudio-2013
So something definitely changed inside
New submission from Vitaly Murashev:
[Affects Windows only]
Brief description (after analysis in debugger):
Py_InitializeEx fails inside internal call:
1.
if (initstdio() < 0)
Py_FatalError(
"Py_Initialize: can't initialize sys standard streams");
2
Vitaly Isaev added the comment:
I confirm the urgent need in this feature.
--
nosy: +vitalyisaev2
___
Python tracker
<http://bugs.python.org/issue20337>
___
___
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
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)
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 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:
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
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
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
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
Changes by Vitaly :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15896>
___
___
Python-bugs-list mailing list
Unsubscri
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
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:
> 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:
> 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:
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:
> 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
1 - 100 of 120 matches
Mail list logo
