[issue1731717] race condition in subprocess module
red added the comment: I'm using an old Plone/Zope Product, PHParser, that uses the popen2 call ... same problem for me. Is there a thread-safe alternative to execute subprocesses in threads? I need a patch!!! thanks in advance!!! -- nosy: +shaphiro ___ Python tracker <http://bugs.python.org/issue1731717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37859] time.process_time() constant / erratic on Windows
New submission from Red Glyph : Tested with - Python 3.7.4, 64-bit, Windows version (installer version) - python-3.8.0b3-embed-amd64.zip - python-3.7.2.post1-embed-amd64.zip on Windows 7 x64 Professional time.process_time() always returns the same value. If I check the value of time.process_time_ns(), sometimes it is constant, sometimes I observe a few changes, then it becomes constant too. Here is a log of an example session, I'm waiting at least 1-2 seconds between each command: Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license()" for more information. >>> import time >>> time.process_time() 0.1092007 >>> time.process_time() 0.1092007 >>> time.process_time_ns() 109200700 >>> time.process_time_ns() 124800800 >>> time.process_time_ns() 124800800 >>> time.process_time() 0.1248008 >>> time.process_time() 0.1248008 >>> time.process_time() 0.1248008 >>> time.process_time_ns() 124800800 >>> time.process_time_ns() 124800800 >>> time.process_time_ns() 124800800 >>> time.process_time_ns() 124800800 >>> time.clock() Warning (from warnings module): File "__main__", line 1 DeprecationWarning: time.clock has been deprecated in Python 3.3 and will be removed from Python 3.8: use time.perf_counter or time.process_time instead 77.006126126 >>> time.clock() 79.245575778 >>> time.clock() 80.801103036 >>> time.process_time() 0.1248008 >>> -- components: Library (Lib), Windows messages: 349745 nosy: Red Glyph, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: time.process_time() constant / erratic on Windows type: behavior versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue37859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37859] time.process_time() constant / erratic on Windows
Change by Red Glyph : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37859] time.process_time() constant / erratic on Windows
Red Glyph added the comment: I see that now. The behaviour was different in Linux, though, I suppose it may benefit from a more precise counter, but since in Windows it also has a precise counter with time.perf_counter_ns(), I was expecting to see that value change, but it was mainly a confusion with the older time.clock(). Thanks! -- ___ Python tracker <https://bugs.python.org/issue37859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41874] datetime.strptime raises error if date is before 1900
New submission from Red Rooster :
This fails, because the date is before 1900:
d = datetime.strptime("28. Februar 1899", '%d. %B %Y')
But the opposite conversion direction works:
d=datetime(1899,2,28)
d.strftime('%d. %B %Y')
prints out "28. Februar 1899" as it should be.
--
components: Library (Lib)
messages: 377592
nosy: redrooster
priority: normal
severity: normal
status: open
title: datetime.strptime raises error if date is before 1900
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41874>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41874] datetime.strptime raises error if date is before 1900
Red Rooster added the comment: The issue is not that the date is before 1900, the issue are german month names. That strptime understands them, first set the locale like that: locale.setlocale(locale.LC_TIME, "de_DE") -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21475] Support the Sitemap extension in robotparser
Lady Red added the comment: I wrote a test for this as it seems to have been abandoned, and opened a PR. https://github.com/python/cpython/pull/6878 -- nosy: +mcsc...@gmail.com ___ Python tracker <https://bugs.python.org/issue21475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21475] Support the Sitemap extension in robotparser
Lady Red added the comment: Sorry, wrong PR number. it is 6883, and attached to this ticket -- ___ Python tracker <https://bugs.python.org/issue21475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33667] Mock calls on mutable objects
Lady Red added the comment: To have the behavior that you are expecting, I believe the mock would have to store a deep copy of every mutable object that is passed in to any of it's calls, in case that object later mutates. That would really expand the memory and time footprint of working with a Mock object. The mock object would grow with every call to. (This is already true, as it's adding to it's mock_calls list... but it would grow much more. ) I'm also not sure about the safety of trying to deepcopy all objects passed in. I think that in addition to the safety and memory/performance issues that I've highlighted, deepcopying all objects would lead to it's own unintuitive behaviors. Objects you get back from mock_call wouldn't be the objects that it was actually called with, they would be copies. I am attaching a file that illustrates this last point. -- nosy: +mcsc...@gmail.com Added file: https://bugs.python.org/file47622/unintuitive_side_effect.py ___ Python tracker <https://bugs.python.org/issue33667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
