[issue32291] Value error for string shared memory in multiprocessing
New submission from Marc Guetg :
It seems like sharing a string over processes is not possible.
#!/usr/bin/env python3
import multiprocessing
import threading
import ctypes
def fun(share_c, share_s, set_c, set_s, name):
print(f'{name}: {share_c.value}; {share_s.value}')
share_c.value = set_c
share_s.value = set_s
print(f'{name}: {share_c.value}; {share_s.value}')
if __name__ == '__main__':
share_c = multiprocessing.Value(ctypes.c_wchar, 'a')
share_s = multiprocessing.Value(ctypes.c_wchar_p, 'aa')
print(f'pre_thread: {share_c.value}; {share_s.value}')
thread = threading.Thread(target=fun, args=(share_c, share_s,
'b', 'bb', 'thread'))
thread.start()
thread.join()
print(f'post_thread: {share_c.value}; {share_s.value}')
process = multiprocessing.Process(target=fun, args=(share_c,
share_s, 'c', 'cc', 'process'))
process.start()
process.join()
print(f'post_process: {share_c.value}', end='; ')
print(share_s.value) # <--- Blows here
produces:
pre_thread: a; aa
thread: a; aa
thread: b; bb
post_thread: b; bb
process: b; bb
process: c; cc
post_process: c; Traceback (most recent call last):
File "test2.py", line 30, in
print(share_s.value) # <--- Blows here
File "", line 5, in getvalue
ValueError: character U+ff92f210 is not in range [U+; U+10]
Where the character value in the error message is different every time. To me
this seems like a bug as it is working properly with threads as well as single
characters. (Maybe relevant question also here:
https://stackoverflow.com/questions/47763878/how-to-share-string-between-processes?noredirect=1#comment82492062_47763878)
For the case it matters:
Python 3.6.1 (Anaconda 4.4.0) on RHEL 6
--
components: Library (Lib), Unicode
messages: 308144
nosy: ezio.melotti, magu, vstinner
priority: normal
severity: normal
status: open
title: Value error for string shared memory in multiprocessing
type: crash
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue32291>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29594] implementation of __or__ in enum.auto
Marc Guetg added the comment: @ethan, didn't know about aenum, thanks for showing it to me. However it doesn't seem to support the behavior I'm after (or I'm doing something wrong) import aenum try: class Foo(aenum.Flag): a = aenum.auto() b = a | aenum.auto() except Exception as err: print(err) try: class Bar(aenum.Flag): a = aenum.auto() b = aenum.auto() | a except Exception as err: print(err) results in unsupported operand type(s) for |: 'int' and 'auto' exceptions must derive from BaseException where the latter might be a bug in the implementation. I do realize that I'm stuck with this for the moment. My motivation with opening this thread was that I was wondering if such a feature would be worthwhile for the community. In case there is interest in this feature I would try to run the unit test and follow all the steps to try to push it through. However I save myself the work in case the community decides that the implementation is not worth it. Which would also be fine with me, as I monkey patched it for my code - so no problem on my end. -- ___ Python tracker <http://bugs.python.org/issue29594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29594] implementation of __or__ in enum.auto
Marc Guetg added the comment: One made-up use-case would be: class LogLevel(Flags): start = auto() log1 = start | auto() log2 = start | auto() def fun(flags, *args): if start in flags: # open log file if log1 in flags: # Log important thing 1 if log2 in flags: # Log important thing 2 if start in flags: # close log file Alternatively the same could be achieved using the existing capabilities with: class LogLevel(Flags): start = auto() _log1 = auto() log1 = start | _log1 _log2 = auto() log2 = start | _log2 Which is less clear imho and could potentially a problem if somebody uses LogLevel._log2 Another alternative would be that within the function we would check for all cases. eg: if (start in flags) or (log1 in flags) or (log2 in flags): Which leads to less clear code and makes the code less maintainable when log3 gets introduced. In the existing case we need to remember to change the if clause both when opening and closing the file. After the proposed change we only need to change the enum. I'm sure there are more use-cases for it. The one I'm using it for is a bit more convoluted that's why I'm not presenting it here. -- ___ Python tracker <http://bugs.python.org/issue29594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29594] implementation of __or__ in enum.auto
Changes by Marc Guetg : -- title: implement __or__ in enum.auto -> implementation of __or__ in enum.auto ___ Python tracker <http://bugs.python.org/issue29594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29594] implement __or__ in enum.auto
New submission from Marc Guetg: At the moment it is only possible to combine flags that already exist: from enum import * class Foo(Flag): A = auto() # 1 B = auto() # 2 AB = A | B # 3 (1 | 2) AC = auto() | A # Fails, but should be 5 (1 | 4) ABD = auto() | A | B # Just taking it one step further to make a point, 11 (1 | 2 | 8) It would be nice to have this for cases when C only makes sense in combination with A but not on its own. A solution to achieve this one would need to change two things in ~/cpython/Lib/enum.py First extend class auto by: class auto: """ Instances are replaced with an appropriate value in Enum class suites. """ value = _auto_null or_value = 0 def __or__(self, other): """ Postpone the real or operation until value creation in _EnumDict """ self.or_value |= other return self And second change one line in _EnumDict: value = value.value changes to: value = value.value | value.or_value Some simple tests show the expected results: print(repr(Foo.A)) # A - 1 print(repr(Foo.B)) # B - 2 print(repr(Foo.AB)) # AB - 3 print(repr(Foo.AC)) # AC - 5 print(repr(Foo.A | Foo.AC)) # AC - 5 print(repr(Foo.A & Foo.AC)) # A - 1 print(repr(Foo.ABD))# ABD - 11 Would it make sense to enhance python enums with that functionality? -- components: Library (Lib) files: test.py messages: 288029 nosy: magu priority: normal severity: normal status: open title: implement __or__ in enum.auto type: enhancement versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46646/test.py ___ Python tracker <http://bugs.python.org/issue29594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26514] Object defines '__ne__' as 'not __eq__' if '__ne__' is not implemented
New submission from Marc Guetg: I propose to change __ne__ of `object` in the following form: class NewObject(object): def __ne__(self, other): return not self.__eq__(other) Currently overwriting the `__eq__` method requires also overwriting `__ne__`. In a vast majority of cases this results in some boilerplate code as: (a == b) ^ (a != b) == True to reduce surprises. Changing the default behavior still allows for the limited number of use cases where we want to implement __ne__ differently. In short I propose the same behavior than __str__ and __repr__ have for __eq__ and __ne__. (https://docs.python.org/3/reference/datamodel.html#object.__str__) -- components: Interpreter Core messages: 261385 nosy: Marc Guetg priority: normal severity: normal status: open title: Object defines '__ne__' as 'not __eq__' if '__ne__' is not implemented type: enhancement versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue26514> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
