[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
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 "misleading". A better name could be `assertItemsEqual` or `assertCountAndItemsEqual` On Sat, Sep 5, 2020 at 1:02 PM Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > This should stay closed as a duplicate. > > If you must, reopen of the original 27071, but it was closed for a > reason. The majority of respondents voted for the status quo. Each > alternative that was considered had its own share of problems. > > BTW, it is hyperbolic to call the name "horribly misleading". The method > literally runs Counter and checks for equality. The docstring is clear > about this: > > def assertCountEqual(self, first, second, msg=None): > """Asserts that two iterables have the same elements, the same > number of > times, without regard to order. > > self.assertEqual(Counter(list(first)), > Counter(list(second))) > > Example: > - [0, 1, 1] and [1, 0, 1] compare equal. > - [0, 0, 1] and [0, 1] compare unequal. > > """ > > -- > nosy: +rhettinger > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue38240> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
Vitaly Kruglikov added the comment: Reopened per request from ammar2 -- ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
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 > > Could you re-open that so the discussion is kept in one place. > > -- > nosy: +ammar2 > > ___ > Python tracker > <https://bugs.python.org/issue38240> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
Change by Vitaly Kruglikov : -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39518] Dark theme
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/issue39518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39518] Dark theme
Change by Vitaly Zdanevich : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue39518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39518] Dark theme
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, docs@python priority: normal severity: normal status: open title: Dark theme ___ Python tracker <https://bugs.python.org/issue39518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38240] assertCountEqual is horribly misleading, sounds like only counts are being compared
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 bad way. -- components: Tests messages: 352901 nosy: vitaly.krug priority: normal severity: normal status: open title: assertCountEqual is horribly misleading, sounds like only counts are being compared versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev <murashev_vit...@mail.ru> added the comment: > Only a PR for master is needed. Serhiy Storchaka, thanks for advice, I cancelled unnecessary PRs. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev <murashev_vit...@mail.ru> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Change by Vitaly Murashev <murashev_vit...@mail.ru>: -- versions: +Python 2.7, Python 3.7, Python 3.8 -Python 3.3, Python 3.4 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev <murashev_vit...@mail.ru> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
Vitaly Murashev <murashev_vit...@mail.ru> 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 to attach new patches here - on bugs.python.org ? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: Indeed, confirmed no `inet_pton()` on Windows in Python 2.7 :(. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 Window's Python 2.7.14 implementation of `socket.inet_pton()` has a bug in that it fails to recognize '::' as the the IPv6 unspecified address 0:0:0:0:0:0:0:0, so `socket.inet_pton(socket.AF_INET6, "::")` fails. I wonder if this exists on Windows Python3 implementations? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Vitaly Kruglikov <vitaly.k...@gmail.com> 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* will be raised." -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
Change by Vitaly Kruglikov <vitaly.k...@gmail.com>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33206] Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError instead of socket.error
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
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, 'localhost')
[00:02:33] File "C:\Python27\lib\site-packages\twisted\python\compat.py",
line 68, in inet_pton
[00:02:33] raise ValueError("Illegal characters: %r" % (''.join(x),))
[00:02:33] ValueError: Illegal characters: 't'
```
With `socket.AF_INET`, `socket.inet_pton(socket.AF_INET, 'localhost')` raises
`socket.error` as expected.
For comparison, with Python 2.7.10 running on OS X, both AF_INET and AF_INET6
raise `socket.error`.
--
components: Library (Lib), Windows
messages: 314814
nosy: paul.moore, steve.dower, tim.golden, vitaly.krug, zach.ware
priority: normal
severity: normal
status: open
title: Windows inet_pton(socket.AF_INET6, 'localhost') raises ValueError
instead of socket.error
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33206>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33148] RuntimeError('Event loop is closed') after cancelling getaddrinfo and closing loop
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
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",
line 324, in _invoke_callbacks
callback(self)
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/futures.py",
line 414, in _call_set_state
dest_loop.call_soon_threadsafe(_set_state, destination, source)
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py",
line 620, in call_soon_threadsafe
self._check_closed()
File
"/usr/local/Cellar/python/3.6.4_3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py",
line 357, in _check_closed
raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
```
When executing this code:
```
import asyncio
while True:
loop = asyncio.new_event_loop()
coro = loop.getaddrinfo('www.google.com', 80)
task = asyncio.ensure_future(coro, loop=loop)
task.cancel()
loop.call_soon_threadsafe(loop.stop)
loop.run_forever()
loop.close()
```
Shouldn't a cancelled operation go away (or at least pretend to go away)
cleanly?
--
components: asyncio
messages: 314484
nosy: asvetlov, vitaly.krug, yselivanov
priority: normal
severity: normal
status: open
title: RuntimeError('Event loop is closed') after cancelling getaddrinfo and
closing loop
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33148>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: Thank you, I'll consider myself having been warned :) On Sat, Mar 24, 2018, 7:28 AM Christian Heimes <rep...@bugs.python.org> wrote: > > Christian Heimes <li...@cheimes.de> added the comment: > > Serhiy, > I don't understand what you are trying to tell me. "cannot serialize '%s' > object" is used all over the interpreter, e.g. io, pickle, etree, and more. > I feel it's the standard message. > > Vitaly, > A lot of objects can't be copied. It's the general case for all kinds of > objects that hold operating system resources (files, sockets) or wrap > external C libraries (bz2, lzma, sqlite, ssl). We generally don't document > that an object cannot be pickled, serialized, or copied. If documentation > doesn't state that an object is copy-able or doesn't provide a dedicated > copy method, than it can't be copied. > > -- > > ___ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue33023> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 a copying strategy that failed. It would have saved me (and others...) so much time is there was a warning in SSLContext documentation about not being able to serialize/copy/deepcopy by design! Also, making that exception message more generic (ha, I wasn't pickling anything?!) as Serhiy Storchaka suggested would be a welcome addition, but not replacement for documentation. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 from the loop and their callbacks are dispatched. I suppose that it would also be difficult to get buy-in for a feature like this from the different frameworks? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 wishful thinking :). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov <vitaly.k...@gmail.com> added the comment: ... or `events.AbstractEventLoop.run_one_iteration()`. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 the asynchronous `SelectConnection` which has a home-grown proprietary IOLoop. I would like to switch BlockingConnection to use an asyncio-based adapter when running on Python3. SelectConnection's proprietary IOLoop provides a single-stepping run function (poll with a timeout as normally determined by pending callbacks, timers, etc., process all ready events/timers/callbacks, and return). When BlockingConnection needs to send something to the AMQP broker and/or wait for an expected reply, it sends the request (which typically gets queued up in a write buffer) and then runs the proprietary IOLoop's single-stepping method in a loop (thus blocking efficiently on I/O); each time after the single-stepping IOLoop method returns, BlockingConnection checks whether the conditions of interest have been satisfied (e.g., the write buffer size being zero and AMQP Channel.OpenOk has been received). So, another way that asyncio could help, and certainly simplest for me and my use case, is by providing a single-stepping function in the event loop implementations, such as the single-stepping method that I described at the top of the previous paragraph. E.g., `events.AbstractEventLoop.run_one_step()`. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33118] No clean way to get notified when a Transport's write buffer empties out
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>: 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_buffer_limits()` for this purpose, because that would preclude me from using it for its intended purpose. I see that transport in selector_events.py has a private method `_make_empty_waiter()`, which is along the lines of what I need, but it's private and is used by `BaseSelectorEventLoop._sendfile_native()`. Just like `BaseSelectorEventLoop._sendfile_native()`, my app needs equivalent functionality in order to be able to run the loop (`run_until_complete()`) until the transport's write buffer empties out. -- components: asyncio messages: 314236 nosy: asvetlov, vitaly.krug, yselivanov priority: normal severity: normal status: open title: No clean way to get notified when a Transport's write buffer empties out type: enhancement versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 shouldn't be able to cache incoming application data during the client-initiated handshake just as it does at other times. It should be able to cache the incoming pre-negotiation records, decoding them. The pending() check would inform the client that they need to reap the incoming data during the handshake too. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33062] ssl_renegotiate() doesn't seem to be exposed
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>: 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 renegotiation. -- assignee: christian.heimes components: SSL messages: 313706 nosy: christian.heimes, vitaly.krug priority: normal severity: normal status: open title: ssl_renegotiate() doesn't seem to be exposed type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 resumption tickets and anything else that one connection attempt might save/change within an SSL Context that might have an undesirable side-effect on the follow-on connection attempts. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 when designing and implementing solutions. Many thanks! -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Vitaly Kruglikov <vitaly.k...@gmail.com> 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 an AMQP broker (e.g., RabbitMQ). Pika will resolve the hostname via getaddrinfo and make attempts to establish TCP and AMQP connection to the candidate IP addresses until one succeeds in establishing an AMQP connection over SSL. Each connection attempt will require a fresh unadulterated clone of the ssl.SSLContext instance provided by user to avoid any side-effects from prior connection attempts. How can I obtain this pristine clone cleanly for each new connection attempt? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33025] urlencode produces bad output from ssl.CERT_NONE and friends that chokes decoders
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>:
```
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.CERT_NONE')
Out[25]: {'cert_reqs': ['VerifyMode.CERT_NONE']}
In [29]: ast.literal_eval('VerifyMode.CERT_NONE')
Traceback (most recent call last)
...
ValueError: malformed node or string: <_ast.Attribute object at 0x105c22358>
```
This used to work fine and produce `'cert_reqs=0'` on Python 2.7, allowing it
to be decoded properly downstream. However, `'cert_reqs=VerifyMode.CERT_NONE'`
can't be decoded generically. So, something it's that used to work in prior
python versions that is breaking now.
Additional information. json.dumps() actually dumps that value as a number
instead of 'VerifyMode.CERT_NONE'.
It appears that urlencode doesn't work properly with enums, where I would
expect it to emit the numeric value of the enum.
--
assignee: christian.heimes
components: Library (Lib), SSL
messages: 313424
nosy: christian.heimes, vitaly.krug
priority: normal
severity: normal
status: open
title: urlencode produces bad output from ssl.CERT_NONE and friends that chokes
decoders
type: crash
versions: Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33025>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33024] asyncio.WriteTransport.set_write_buffer_limits orders its args unintuitively and inconsistently with its companion function's return value
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>: `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 ordering and inconsistency with the companion function's return value is error-prone. See https://docs.python.org/3/library/asyncio-protocol.html#asyncio.WriteTransport.set_write_buffer_limits -- components: asyncio messages: 313423 nosy: asvetlov, vitaly.krug, yselivanov priority: normal severity: normal status: open title: asyncio.WriteTransport.set_write_buffer_limits orders its args unintuitively and inconsistently with its companion function's return value type: behavior versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Change by Vitaly Kruglikov <vitaly.k...@gmail.com>: -- assignee: -> christian.heimes components: +SSL nosy: +christian.heimes ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
New submission from Vitaly Kruglikov <vitaly.k...@gmail.com>: ``` 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 cause is apparently that `ssl.SSLContext` passes an extra arg to its `__new__` method, but doesn't implement the method `__getnewargs__` that would let `copy` extract the extra arg. -- messages: 313422 nosy: vitaly.krug priority: normal severity: normal status: open title: Unable to copy ssl.SSLContext versions: Python 2.7, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33023] Unable to copy ssl.SSLContext
Change by Vitaly Kruglikov <vitaly.k...@gmail.com>: -- type: -> crash ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
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 history -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28270] [MinGW] Can't compile Modules/posixmodule.c by MinGW - several macro are missed
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 <rep...@bugs.python.org> <http://bugs.python.org/issue28270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28271] [MinGW] Can't compile _ctypes/callproc.c - SEH not supported by MinGW
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: Added file: http://bugs.python.org/file44814/callproc.c.2.7.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28271] [MinGW] Can't compile _ctypes/callproc.c - SEH not supported by MinGW
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.c' now can be found here https://android.googlesource.com/platform/external/python/+/upstream-2.7/Modules/_ctypes/callproc.c Since I am sure that it is waste of time to wait while Googe suggest the patch in cpython upstream, I'm just injected Google's patch to the recent python version. So suggested patch (for 3.5.2 and 2.7.12) is just an adoption of Google's patch to the recent cpython versions. -- components: Build, ctypes files: callproc.c.3.5.mingw.patch keywords: patch messages: 277370 nosy: vmurashev priority: normal severity: normal status: open title: [MinGW] Can't compile _ctypes/callproc.c - SEH not supported by MinGW type: compile error Added file: http://bugs.python.org/file44813/callproc.c.3.5.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28270] [MinGW] Can't compile Modules/posixmodule.c by MinGW - several macro are missed
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 related macro -- components: Build files: posixmodule.c.3.5.mingw.patch keywords: patch messages: 277367 nosy: vmurashev priority: normal severity: normal status: open title: [MinGW] Can't compile Modules/posixmodule.c by MinGW - several macro are missed type: compile error Added file: http://bugs.python.org/file44811/posixmodule.c.3.5.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28270] [MinGW] Can't compile Modules/posixmodule.c by MinGW - several macro are missed
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: Added file: http://bugs.python.org/file44812/posixmodule.c.2.7.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: -- type: -> crash ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28269] [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: -- type: -> compile error ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
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 most important and again - is really trivial -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28269] [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: Added file: http://bugs.python.org/file44809/dynload_win.c.2.7.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28269> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28269] [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp
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 (char *string1, char *string2)
{
int first, second;
do {
first = tolower(*string1);
second = tolower(*string2);
string1++;
string2++;
} while (first && first == second);
return (first - second);
}
---
And this reimplementation clashed with native declaration of strcasecmp()
which one is a part of MinGW runtime
So suggested patch (for 3.5.2 and 2.7.12)
just disables static reimplementation of strcasecmp for MinGW
--
components: Build
files: dynload_win.c.3.5.mingw.patch
keywords: patch
messages: 277362
nosy: vmurashev
priority: normal
severity: normal
status: open
title: [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp
Added file: http://bugs.python.org/file44808/dynload_win.c.3.5.mingw.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28269>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
Changes by Vitaly Murashev <murashev_vit...@mail.ru>: Added file: http://bugs.python.org/file44806/pyconfig.h.2.7.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h
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 issue is actauly very simple: Python code for windows is very sensitive on properly defined macro MS_WIN32/MS_WIN64 And while MS_WIN32 is predefined unconditionally in PC/pyconfig.h, the MS_WIN64 is defined only in conjunction with _MSC_VER, like #ifdef _MSC_VER ... #ifdef _WIN64 #define MS_WIN64 #endif ... #endif /* _MSC_VER */ So suggested patch (for 3.5.2 and 2.7.12) just appropriately define MS_WIN64 for MinGW -- components: Build, Windows files: pyconfig.h.3.5.mingw.patch keywords: patch messages: 277352 nosy: paul.moore, steve.dower, tim.golden, vmurashev, zach.ware priority: normal severity: normal status: open title: [MinGW] Crash at start when compiled by MinGW for 64-bit Windows using PC/pyconfig.h Added file: http://bugs.python.org/file44805/pyconfig.h.3.5.mingw.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
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" implies ordered, while "Unordered" is the opposite. It's like saying "ordered unordered collection". My vote (if I had one) is still with assertUnorderedEqual. I think that from the word "Unordered" it's a reasonable leap that it refers to an unordered collection of elements, and it would be easy to remember. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: I think that assertUnorderedEqual would contrast nicely with assertSequenceEqual -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: With missing last line, this time: == FAIL: test_equal_count_of_different_elements (__main__.Test) -- Traceback (most recent call last): File "", line 5, in test_equal_count_of_different_elements AssertionError: Element counts were not equal: First has 1, Second has 0: 3 First has 0, Second has 1: 4 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
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_elements(self): ... self.assertCountEqual(set([1,2,3]), set([1,2,4])) ... def test_different_count(self): ... self.assertCountEqual(set([1,2,3]), set([1,2,3,4])) ... >>> u.main() FF. == FAIL: test_different_count (__main__.Test) -- Traceback (most recent call last): File "", line 7, in test_different_count AssertionError: Element counts were not equal: First has 0, Second has 1: 4 == FAIL: test_equal_count_of_different_elements (__main__.Test) -- Traceback (most recent call last): File "", line 5, in test_equal_count_of_different_elements AssertionError: Element counts were not equal: First has 1, Second has 0: 3 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: The preceding results are via Python 2.7.10 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: $ python assert_items_equal_test.py FF. == FAIL: test_different_count (__main__.Test) -- Traceback (most recent call last): File "assert_items_equal_test.py", line 12, in test_different_count self.assertItemsEqual(set([1,2,3]), set([1,2,3,4])) AssertionError: Element counts were not equal: First has 0, Second has 1: 4 == FAIL: test_equal_count_of_different_elements (__main__.Test) -- Traceback (most recent call last): File "assert_items_equal_test.py", line 8, in test_equal_count_of_different_elements self.assertItemsEqual(set([1,2,3]), set([1,2,4])) AssertionError: Element counts were not equal: First has 1, Second has 0: 3 First has 0, Second has 1: 4 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
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_different_elements(self): self.assertItemsEqual(set([1,2,3]), set([1,2,4])) def test_different_count(self): self.assertItemsEqual(set([1,2,3]), set([1,2,3,4])) u.main() -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Vitaly added the comment: When I read "Unordered", it makes me think of collections, including sequences and sets. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
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 frequency count. I am also happy with the status quo of assertItemsEqual, but I have to agree that assertUnorderedEqual removes any ambiguity that assertItemsEqual purportedly suffers from. Thank you for suggesting assertUnorderedEqual. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
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's not a good strategy for picking names in computer programming. The name of a function should certainly not be tied to an internal implementation detail (use Counter to implement, so let's name it "Count"?). Something that asserts the equality of two collections of elements is not rocket science and does not deserve an ambiguous name. "Count" is simply too ambiguous in this case. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
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 <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
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 it's going to compare just the simple counts of the elements (i.e., lengths of the sequences). Ask yourself the questions: 1. What is the element count in sequence S? Reasonable answer: len(S). 2. What are the element counts of sequences Q and S? Reasonable answer len(Q) and len(S). Those are the most straightforward, non-nuanced answers you would get from most people IMHO. With ambiguous names like these, readability of the code is greatly diminished. When I review code, a name like assertCountEqual tells me (and likely most other reviewers) that it's comparing lengths of the sequences, and I have no reason to resort to the documentation. A well-named function should do what its name says, and its name should say what it does. assertCountEqual doesn't pass that test, unless you read the documentation, and apply the nuanced interpretation that is biased by the documentation. assertElementCountsEqual is in the same category, I am afraid :) The straightforward interpretation of these names is misleading at worst and ambiguous at best. I think that the authors of the new name assertCountEqual were thinking along the lines of "assert frequency counts equal", which might lead to the arguably unambiguous name assertFrequencyCountsEqual, but but all that sounds more complicated than it needs to be. Personally, something like assertElementsEqual seems to me to capture the spirit of the assertion better and is easier for most people to grasp. It doesn't imply order as it emphasizes the elements (vs. assertSequenceEqual, which emphasizes sequence), and it doesn't imply uniqueness. I like assertElementsEqual more than assertItemsEqual, but then again, assertElementsEqual is not sufficiently better than assertItemsEqual to warrant a backward-incompatible name change in my opinion. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
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 and 3.x. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
Vitaly added the comment: ... and an unnecessary incompatibility between 2.7 and 3.x -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
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. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
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 actually asserts that equivalent items are present in both sequences, regardless of order. The original name from 2.7 assertItemsEqual was so much more meaningful. -- components: Library (Lib) messages: 265980 nosy: vitaly priority: normal severity: normal status: open title: unittest.TestCase.assertCountEqual is a very misleading name versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3
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 name from 2.7 assertItemsEqual was so much better and more meaningful. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
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. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
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 test_equal_count_of_same_elements(self): self.assertItemsEqual([1,2,3], [1,2,3]) def test_equal_count_of_different_elements(self): self.assertItemsEqual([1,2,3], [1,2,4]) def test_different_count(self): self.assertItemsEqual([1,2,3], [1,2,3,4]) u.main() $ python assert_items_equal_test.py --verbose test_different_count (__main__.Test) ... FAIL test_equal_count_of_different_elements (__main__.Test) ... FAIL test_equal_count_of_same_elements (__main__.Test) ... ok == FAIL: test_different_count (__main__.Test) -- Traceback (most recent call last): File "assert_items_equal_test.py", line 12, in test_different_count self.assertItemsEqual([1,2,3], [1,2,3,4]) AssertionError: Element counts were not equal: First has 0, Second has 1: 4 == FAIL: test_equal_count_of_different_elements (__main__.Test) -- Traceback (most recent call last): File "assert_items_equal_test.py", line 8, in test_equal_count_of_different_elements self.assertItemsEqual([1,2,3], [1,2,4]) AssertionError: Element counts were not equal: First has 1, Second has 0: 3 First has 0, Second has 1: 4 -- Ran 3 tests in 0.001s FAILED (failures=2) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
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, which compares counts only, rather than its documentation. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3
Vitaly added the comment: I opened http://bugs.python.org/issue27060 regarding the erroneous documentation of assertItemsEqual in python 2.7. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3
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. See https://hg.python.org/cpython/file/d9921cb6e3cd/Doc/library/unittest.rst: .. method:: assertItemsEqual(actual, expected, msg=None) Test that sequence *expected* contains the same elements as *actual*, regardless of their order. When they don't, an error message listing the differences between the sequences will be generated. Duplicate elements are *not* ignored when comparing *actual* and *expected*. It verifies if each element has the same count in both sequences. It is the equivalent of ``assertEqual(sorted(expected), sorted(actual))`` but it works with sequences of unhashable objects as well. -- nosy: +vitaly ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17866> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
Changes by Vitaly <vitaly.krugl.nume...@gmail.com>: -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
Changes by Vitaly <vitaly.krugl.nume...@gmail.com>: -- versions: +Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27060] Documentation of assertItemsEqual in unittest is VERY misleading in 2.7
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 documentation mislead my group to use this method for comparing the elements. See https://hg.python.org/cpython/file/d9921cb6e3cd/Doc/library/unittest.rst, which is what appears on https://docs.python.org/2.7/library/unittest.html#unittest.TestCase.assertItemsEqual: .. method:: assertItemsEqual(actual, expected, msg=None) Test that sequence *expected* contains the same elements as *actual*, regardless of their order. When they don't, an error message listing the differences between the sequences will be generated. Duplicate elements are *not* ignored when comparing *actual* and *expected*. It verifies if each element has the same count in both sequences. It is the equivalent of ``assertEqual(sorted(expected), sorted(actual))`` but it works with sequences of unhashable objects as well. -- messages: 265889 nosy: vitaly priority: normal severity: normal status: open title: Documentation of assertItemsEqual in unittest is VERY misleading in 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25281] Incorrect enum behavior during json.dumps serialization
Vitaly Belman added the comment: Note: Using pip library enum34 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25281> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25281] Incorrect enum behavior during json.dumps serialization
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:
ValueError: No JSON object could be decoded
Which makes sense because the json dumps function produces is: {"x": a.a}
--
messages: 251945
nosy: Vitaly Belman
priority: normal
severity: normal
status: open
title: Incorrect enum behavior during json.dumps serialization
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25281>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
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 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1731717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25155] datetime.datetime.now() raises
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 anyone please give me a note, whether it would be reasonable for me to wait for a patch in Python3.5.x, or such behavior is common since 3.5 and should not use it in my 'strange' case at all ? A bit of details: Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.datetime.now() Traceback (most recent call last): File "", line 1, in OverflowError: timestamp too large to convert to C _PyTime_t >>> Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.datetime.now() datetime.datetime(2045, 4, 2, 2, 42, 8, 359375) >>> -- components: Interpreter Core, Windows messages: 250914 nosy: paul.moore, steve.dower, tim.golden, vmurashev, zach.ware priority: normal severity: normal status: open title: datetime.datetime.now() raises type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24561] [VS2013] Py_InitializeEx causes fatal error being from winnt-service
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. inside initstdio():
if (!is_valid_fd(fd)) {
std = Py_None;
Py_INCREF(std);
}
else {
// === is_valid_fd() passed and we come here
std = create_stdio(iomod, fd, 0, stdin, encoding, errors);
if (std == NULL)
goto error; // === this goto leads to fatal error
3.
is_valid_fd(int fd) /// = JFI: fd=0
{
int dummy_fd;
if (fd 0 || !_PyVerify_fd(fd))
return 0;
dummy_fd = dup(fd); /// == dup() WORKS well
if (dummy_fd 0)
return 0;
close(dummy_fd);
return 1;
}
4.
Let's Look whats going in create_stdio():
Modules\_io\fileio.c
static int
fileio_init(PyObject *oself, PyObject *args, PyObject *kwds)
{ ...
if (fd = 0) {
if (check_fd(fd))
goto error;/// = fail is here
5. Let's have a look at check_fd():
static int
check_fd(int fd)
{
#if defined(HAVE_FSTAT) /// = yes, it is defined for Windows
struct stat buf;
if (!_PyVerify_fd(fd) || (fstat(fd, buf) 0 errno == EBADF)) {
PyObject *exc;
char *msg = strerror(EBADF);
exc = PyObject_CallFunction(PyExc_OSError, (is),
EBADF, msg);
PyErr_SetObject(PyExc_OSError, exc);
Py_XDECREF(exc);
return -1;
}
#endif
return 0;
}
--
components: IO, Interpreter Core, Windows
messages: 246199
nosy: paul.moore, steve.dower, tim.golden, vmurashev, zach.ware
priority: normal
severity: normal
status: open
title: [VS2013] Py_InitializeEx causes fatal error being from winnt-service
type: crash
versions: Python 3.4, Python 3.5, Python 3.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24561
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24561] [VS2013] Py_InitializeEx causes fatal error being from winnt-service
Vitaly Murashev added the comment: patch suggested -- keywords: +patch Added file: http://bugs.python.org/file39854/pythonrun.c.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24561] [VS2013] Py_InitializeEx causes fatal error being called from winnt-service
Changes by Vitaly Murashev murashev_vit...@mail.ru: -- title: [VS2013] Py_InitializeEx causes fatal error being from winnt-service - [VS2013] Py_InitializeEx causes fatal error being called from winnt-service ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24561] [VS2013] Py_InitializeEx causes fatal error being from winnt-service
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 Microsoft runtime implementation. For unknown reason when winnt-service is running, its std file handles 0,1,2 can be duplicated using dup() but fstat() fails -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20337] bdist_rpm should support %config(noreplace)
Vitaly Isaev added the comment: I confirm the urgent need in this feature. -- nosy: +vitalyisaev2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20337 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21453] Support of RPM subpackages in distutils
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 - main_package, -libs, -devel, -debuginfo). It would be convenient to do the same in a purely Pythonic projects (i mean to place something in setup.py and to obtain the output spec-file with a corresponding number of `%package subpackage_name` sections). I didn't manage to find the code that matches these purposes in the most up-to-date release of the distutils (/usr/lib64/python2.7/distutils/command/bdist_rpm.py). So I would ask to implement this feature. Also I can try to do it on my own in case if the community considers it as a good offer. Thank you. -- components: Distutils messages: 218119 nosy: dstufft, eric.araujo, vitalyisaev2 priority: normal severity: normal status: open title: Support of RPM subpackages in distutils type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21453 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20912] [zipfile.py]: Make zip directory attributes more friendly for MS-Windows
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) 0x0010 - means # MS-DOS directory flag At the same time zipfile.py doesn't provide MS-DOS directory flag. It seems be a good idea to do it. Patch suggested over 3.3.3 code-base. -- components: Library (Lib) files: zipfile.py.diff keywords: patch messages: 213416 nosy: vmurashev priority: normal severity: normal status: open title: [zipfile.py]: Make zip directory attributes more friendly for MS-Windows type: behavior versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34399/zipfile.py.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20912 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
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 rep...@bugs.python.org http://bugs.python.org/issue18307 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
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: http://bugs.python.org/file31451/test_zipimport_co_filename.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18307 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18777] Cannot compile _ssl.c using openssl 1.0
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. Patch suggested. -- components: Build files: ssl.patch keywords: patch messages: 195602 nosy: vmurashev priority: normal severity: normal status: open title: Cannot compile _ssl.c using openssl 1.0 type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file31368/ssl.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18307] Relative path in co_filename for zipped modules
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 debugger: CRITICAL WARNING: This version of python seems to be incorrectly compiled (internal generated filenames are not absolute) pydev debugger: The debugger may still function, but it will work slower and may miss breakpoints. --- So I started my own investigation of this issue and results are the following. At first I took traditional python debugger 'pdb' to analyze how it behaves during debug of zipped module. 'pdb' showed me some backtaces and filename part for stack entries looks malformed. I expected something like 'full-path-to-zip-dir/my_zipped_module.zip/subdir/test_module.py' but realy it looks like 'full-path-to-current-dir/subdir/test_module.py' Source code in pdb.py and bdb.py (which one are a part of python stdlib) gave me the answer why it happens. The root cause are inside Bdb.format_stack_entry() + Bdb.canonic() Please take a look at the following line inside 'format_stack_entry' method: filename = self.canonic(frame.f_code.co_filename) For zipped module variable 'frame.f_code.co_filename' holds _relative_ file path started from the root of zip archive like 'subdir/test_module.py' And as relult Bdb.canonic() method gives what we have - 'full-path-to-current-dir/subdir/test_module.py' --- Looks like it is a bug in: - in python core subsystem which one is responsible for loading zipped modules - or in pdb debugger -- components: Interpreter Core, Library (Lib) messages: 191907 nosy: vmurashev priority: normal severity: normal status: open title: Relative path in co_filename for zipped modules type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18307 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16168] SysLogHandler constructor ignores socktype arg when address refers to a Unix Domain Socket
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 or STREAM sockets try: self.socket.connect(address) except socket.error: self.socket.close() self.socket = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) self.socket.connect(address) -- components: Library (Lib) messages: 172418 nosy: vitaly priority: normal severity: normal status: open title: SysLogHandler constructor ignores socktype arg when address refers to a Unix Domain Socket versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16168 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16168] SysLogHandler constructor ignores socktype arg when address refers to a Unix Domain Socket
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 tracebacks for production apps are larger than 2000 bytes, and it's paramount to capture the entire traceback in order to debug the issue. This limitation can be overcome if _connect_unixsocket() used the socktype arg value that was passed to SysLogHandler constructor. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16168 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
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 Mac OS, the subsequent investigation revealed that this has nothing to do with a forked child failing. Rather, it's a bug in the read() syscall on Mac OS X. What would be a more appropriate place to work around this read() syscall bug than os.read? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
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 via errata documentation (i.e., On Mac OS X, don't make individual pipe read requests that would result in os.read() buffersize arg being above 127KB on non-blocking pipes.); should also check if the same issue occurs with sockets (e.g., socket.socketpair() instead of os.pipe()) to make the errata more complete. This may be perfectly acceptable and how things have worked for a long time. Option 2: Implement a work-around in the lowest common denominator wrapper function, so that anything in Python that needs to call read() and could benefit from this work-around, would call that wrapper instead of read(). The read() work-around might go something like this in *pseudocode*: if running_on_darwin and buffersize 127KB: # fix up buffer size to work around a Mac OS x bug... if stat.S_ISFIFO(os.fstat(fd).st_mode): buffersize = 127KB Then do whatever else the read function is supposed to do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
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 rejected. And, as mentioned earlier, I filed the issue on https://bugreport.apple.com as Problem ID: 12274650. -- resolution: - rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
Changes by Vitaly vitaly.krugl.nume...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
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 guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file*, but in no other case. == I am guessing that fstat() + S_ISREG() can be used to discern normal files from other types of file descriptors. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
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 should be implemented in os.read() -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15896] Sporadic EINVAL in nonblocking pipe os.read when forked child fails on Mac OS
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 issue every 4K and only in decreasing order (probably something related to Python's memory management optimizations). A new caveat: if the read buffer is allocated once before entering the read loop, then we don't get any EINVAL in the entire run; however, if the read buffer is allocated for each read request inside the loop, then we get EINVAL every other time in the range from 128KB and up. I would like to file this issue with apple/Mac OS. What's the appropriate URL for this? -- Added file: http://bugs.python.org/file27172/test_fork_pipe_error.cpp ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
