[issue23517] datetime.utcfromtimestamp parses timestamps incorrectly
Timothy Cardenas added the comment: We are seeing this behavior influencing other libraries in python 3.4. This should never fail if timestamp and fromtimestamp are implemented correctly: from datetime import datetime t = datetime.utcnow().timestamp() t2 = datetime.utcfromtimestamp(t) assert t == t2, 'Moving from timestamp and back should always work' -- nosy: +trcarden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23517 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24512] multiprocessing should log a warning when forking multithreaded process
New submission from Timothy Cardenas: We were tracking down a bug the other day that was rather hard to find involving a forking a process that had both a primary thread and a logging thread. The docs clearly state that forking a multithreaded process is problematic https://docs.python.org/3.4/library/multiprocessing.html#contexts-and-start-methods However given that it is very simple to check if the process currently has multiple threads at the time of the forking operation and that its almost never safe to do so with multiple running threads I was wondering if it made sense to add a message that warned that a unsafe operation (forking a multithreaded process without the forkserver option) was occurring. -- components: Library (Lib) messages: 245825 nosy: trcarden priority: normal severity: normal status: open title: multiprocessing should log a warning when forking multithreaded process type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24183] ABCMeta classes do not support the **kwargs standard class interface
New submission from Timothy Cardenas: Summary: Any class that derives from the ABCMeta class doesn't support keyword variable arguments as defined here :https://www.python.org/dev/peps/pep-3115/. Expected: If i define a simple class that derives from ABCMeta that has a kwarg the class should be created (see below from collections import UserDict class MyDict(UserDict, bar='baz'): pass dictionary = MyDict() # Expect this to create a new instance of MyDict. Actual: from collections import UserDict class MyDict(UserDict, bar='baz'): pass dictionary = MyDict() # This call fails because UserDict inherits from ABCMeta Traceback (most recent call last): File abc_meta.py, line 4, in module class MyDict(UserDict, bar='baz'): -- components: Library (Lib) files: abc_meta.py messages: 243130 nosy: trcarden priority: normal severity: normal status: open title: ABCMeta classes do not support the **kwargs standard class interface type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39364/abc_meta.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24183 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24183] ABCMeta classes do not support the **kwargs standard class interface
Timothy Cardenas added the comment:
Hmm Ok. You are right i can do the following:
from collections import UserDict
from abc import ABCMeta
class MetaMyDict(ABCMeta):
@classmethod
def __prepare__(cls, name, bases, **kwargs):
return {}
def __new__(mcls, name, bases, namespace, **kwds):
return super().__new__(mcls, name, bases, namespace)
def __init__(cls, name, bases, namespace, **kargs):
return super().__init__(name, bases, namespace)
class MyDict(UserDict, metaclass=MetaMyDict, bar='baz'):
pass
dictionary = MyDict()
But I guess i would have expected a core lib library to be consistent with the
data model
https://docs.python.org/3.4/reference/datamodel.html#preparing-the-class-namespace.
As it stands an end user can't get a subclass of ABCMeta to work with the same
**kwargs interface without creating a custom metaclass that strips it out
before passing to ABCMeta.
Wouldn't it be much easier and technically correct for the core ABCMeta library
to adopt the same interface contract for class creation introduced in python3?
--
resolution: not a bug - remind
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24183
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24183] ABCMeta classes do not support the **kwargs standard class interface
Timothy Cardenas added the comment: Ahhh i see now. Even the simple case class Foo(bar='baz'): pass fails. I misunderstood the documentation then. I thought that python 3 introduced a new interface for all classes when it actually just introduced the option to add keyword arguments to your own metaclasses but didn't alter the base level class interface. I wanted a bit more background around the object.__init__ and found this ticket: http://bugs.python.org/issue1683368. While this is probably not the only place where this comes up I see the tact that the python core team took and understand your reference more completely now. I thank both of you for your help and quick responses. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24183 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
