[issue11979] Minor improvements to the Sockets readme: typos, wording and sphinx features usage
Roundup Robot devnull@devnull added the comment: New changeset 4081f326e46c by Ezio Melotti in branch '2.7': #11979: improve wording and markup in sockets howto. Patch by Xavier Morel. http://hg.python.org/cpython/rev/4081f326e46c New changeset 85b9ad8b219b by Ezio Melotti in branch '3.1': #11979: improve wording and markup in sockets howto. Patch by Xavier Morel. http://hg.python.org/cpython/rev/85b9ad8b219b New changeset bc251b65de1d by Ezio Melotti in branch '3.2': #11979: merge with 3.1. http://hg.python.org/cpython/rev/bc251b65de1d New changeset 4b122cac7ac5 by Ezio Melotti in branch 'default': #11979: merge with 3.2. http://hg.python.org/cpython/rev/4b122cac7ac5 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11979 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11979] Minor improvements to the Sockets readme: typos, wording and sphinx features usage
Ezio Melotti ezio.melo...@gmail.com added the comment: Fixed, thanks for the patches! -- assignee: docs@python - ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11979 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9516] sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now 10.3 but 10.5 during configure
Ronald Oussoren ronaldousso...@mac.com added the comment: Attached the backport to 2.7 for my v2 patch. -- Added file: http://bugs.python.org/file21997/issue9516-v2-python2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6191] HTMLParser attribute parsing - 2 test cases when it fails
Ezio Melotti ezio.melo...@gmail.com added the comment: What I described in my previous message is what Firefox does. If you think this should be changed, I suggest you to open another issue, possibly attaching a test case with the desired behavior and a patch to change it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11981] dupe self.fp.tell() in zipfile.ZipFile.writestr
Ezio Melotti ezio.melo...@gmail.com added the comment: I double checked the code on py3k and I think the second occurrence can be removed. -- nosy: +alanmcintyre versions: +Python 3.3 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11981 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12075] python3.2 memory leak when setting integer key in dictionary
New submission from kai zhu kai...@ugcs.caltech.edu:
i'm using the latest debian unstable python3.2 build on colinux (2011, may, 14)
## leak.py
## import imp, leak; imp.reload(leak)
## will leak ~2.5mb per reload
## on i386 debian unstable machine (according to top).
## in my real world app (an automatic build system),
## i run out of memory after a number reloads :(
class Foo(object): pass
Foo.leaky_dictionary = {}
for aa in range(256):
for bb in range(256):
Foo.leaky_dictionary[(bb 8) | aa] = None
$ python3.2
Python 3.2.1a0 (default, May 5 2011, 00:47:12)
[GCC 4.6.1 20110428 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
import imp, leak; imp.reload(leak) ## 11mb
module 'leak' from 'leak.py'
import imp, leak; imp.reload(leak) ## 13mb
module 'leak' from 'leak.py'
import imp, leak; imp.reload(leak) ## 16mb
module 'leak' from 'leak.py'
import imp, leak; imp.reload(leak) ## 19mb
module 'leak' from 'leak.py'
--
messages: 135961
nosy: kaizhu
priority: normal
severity: normal
status: open
title: python3.2 memory leak when setting integer key in dictionary
type: resource usage
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12075
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana
Charles-François Natali neolo...@free.fr added the comment: This makes sense. I was suspecting a system limit exhaustion, maybe OOM or maximum number of threads, something like that. But at least on Linux, in OOM condition, the process would either get nuked by the OOM-killer, or pthread_create would bail out with ENOMEM (when allocating the stack for example), so we would be able to - somewhat - catch the error and get an exception (well, OOM condition is also often a sort of undefined behaviour, so we can't really make a guarantee on the state of the interpreter when it's hit). Out of curioisity, could you try the attached test to see how it behaves on your VM? Usage: ./test_thread_oom number of threads to create On Linux it fails with ENOMEM Resource temporarily unavailable. -- Added file: http://bugs.python.org/file21998/test_thread_oom.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12071 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12075] python3.2 memory leak when setting integer key in dictionary
Ezio Melotti ezio.melo...@gmail.com added the comment: I think this has to do with class attributes and reload(): wolf@hp:~/dev/py/py3k$ cat leak.py class Foo: pass Foo.l = list(range(65535)) wolf@hp:~/dev/py/py3k$ ./python Python 3.3a0 (default:4b122cac7ac5+, May 14 2011, 10:01:13) [GCC 4.5.2] on linux2 Type help, copyright, credits or license for more information. import imp, leak; imp.reload(leak) module 'leak' from 'leak.py' [189091 refs] imp.reload(leak) module 'leak' from 'leak.py' [254649 refs] imp.reload(leak) module 'leak' from 'leak.py' [320207 refs] imp.reload(leak) module 'leak' from 'leak.py' [385765 refs] import gc; gc.collect() 28 [123927 refs] However calling gc.collect() explicitly seems to fix the problem. -- nosy: +ezio.melotti versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12075] python3.2 memory leak when setting integer key in dictionary
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: It's simply because all classes form a cycle (Foo - Foo.__mro__ - Foo) A class and class attributes can only be freed with gc.collect(). Did you disable the garbage collector? -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12075 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6721] Locks in python standard library should be sanitized on fork
Charles-François Natali neolo...@free.fr added the comment: Hello Steffen, First, thanks for testing this on OS-X: I only have access to Linux systems (I tested both the semaphore and the emulated semaphore paths). If I understand correctly, the patch works fine with the default build option on OS-X. Then, you're saying that OS-X doesn't have POSIX unnamed semaphores: this means that the default build uses the mutex+condition variable version. Am I correct? But I don't understand the last part of your message. Do you mean that you implemented your own version of the semaphore path using named semaphores, and that it fails with my patch (well, your adapted version of it) ? If yes, then you'll understand that I can't comment on this, since it's not my code :-) But after a quick look at the code you posted, I think that your acquire code is broken: sem_timedwait(timeout) if not the same as trying sem_trywait multiple times until timeout expires: in case of contention, this will fail. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12076] IDLE v.3.2 crashing randomly on MacOSX 10.6.7
New submission from Chris Paton chrispaton2...@gmail.com: I don't know much about Python (in fact, I'm a noob) so not understanding much of the technical lingo. I've installed Python 3.2, and Active TCL 8.5.9 on my machine. IDLE crashes at random points - compiling, saving, loading or even just typing! Why is this? What can i do to get it working? There is no error message, I just get my spinning beach ball and then I have to force quit the program, so it doesn't seem to be anything official. Any help at all would be great, I really need to get this going for my thesis project! -- components: IDLE messages: 135966 nosy: Chris.Paton priority: normal severity: normal status: open title: IDLE v.3.2 crashing randomly on MacOSX 10.6.7 type: crash versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12076] IDLE v.3.2 crashing randomly on MacOSX 10.6.7
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Hello, The Python issue tracker is not here to get help. You will have better answers from friendly people if you ask your question on the comp.lang.python newsgroup, or the python-list mailing list: http://www.python.org/community/lists/ -- nosy: +amaury.forgeotdarc resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly
Charles-François Natali neolo...@free.fr added the comment: Indeed, it isn't, Pipe objects are not meant to be safe against multiple access. Queue objects (in multiprocessing/queues.py) use locks so they are safe. But if the write to the Pipe is not atomic, then the select isn't safe. select will return as soon as some data is available for reading. So let's say this happens: parent process waiting inside Connection.recv() on poll(): def recv(self, sentinels=None): if sentinels: self._poll(-1.0, sentinels) buf = self._recv_bytes() return pickle.loads(buf.getbuffer()) worker process, inside Connection.send(): def send_bytes(self, buf): n = len(buf) self._send(struct.pack(=i, len(buf))) [crash] # The condition is necessary to avoid broken pipe errors # when sending a 0-length buffer if the other end closed the pipe. if n 0: self._send(buf) In the parent process, _poll() will return self._handle as readable as soon as len(buf) has been sent by the worker process. Thus, Connection.recv_bytes() will be called: def _recv_bytes(self, maxsize=None): buf = self._recv(4) size, = struct.unpack(=i, buf.getvalue()) if maxsize is not None and size maxsize: return None return self._recv(size) The first _recv() will succeed, since the length is in the Pipe. The second one, however, will remain stuck on the read from the pipe/unix socket, because there's no more data. This can be reproduced easily by adding a short sleep right after the sending of the length of the buffer inside send_bytes(), and then sending a SIGKILL to a worker process. (Also, I now remember why I made the comment about the handle being read after the select, I spotted this earlier but completely forgot about it afterwards...). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7960] test.support.captured_output has invalid docstring example
Roundup Robot devnull@devnull added the comment: New changeset ec35f86efb0d by Ezio Melotti in branch 'default': Merge with 3.2 and also remove captured_output from __all__ (see #7960). http://hg.python.org/cpython/rev/ec35f86efb0d -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7960 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7960] test.support.captured_output has invalid docstring example
Changes by Ezio Melotti ezio.melo...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7960 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12050] unconsumed_tail of zlib.Decompress is not always cleared on decompress() call
Roundup Robot devnull@devnull added the comment: New changeset 6a45567c7245 by Nadeem Vawda in branch '3.1': Issue #12050: zlib.decompressobj().decompress() now clears the unconsumed_tail http://hg.python.org/cpython/rev/6a45567c7245 New changeset 49c998a88777 by Nadeem Vawda in branch '3.2': Merge: #12050: zlib.decompressobj().decompress() now clears the unconsumed_tail http://hg.python.org/cpython/rev/49c998a88777 New changeset 088e5d705171 by Nadeem Vawda in branch 'default': Merge: #12050: zlib.decompressobj().decompress() now clears the unconsumed_tail http://hg.python.org/cpython/rev/088e5d705171 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12050 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12050] unconsumed_tail of zlib.Decompress is not always cleared on decompress() call
Roundup Robot devnull@devnull added the comment: New changeset 24543f7a87ce by Nadeem Vawda in branch '2.7': Issue #12050: zlib.decompressobj().decompress() now clears the unconsumed_tail http://hg.python.org/cpython/rev/24543f7a87ce -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12050 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12050] unconsumed_tail of zlib.Decompress is not always cleared on decompress() call
Nadeem Vawda nadeem.va...@gmail.com added the comment: The code has been fixed. Once again, thanks for the bug report. -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12050 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: Is there anything preventing this patch from being merged? -- nosy: +Darren.Dale ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12077] Harmonizing descriptor protocol documentation
New submission from Davide Rizzo sor...@gmail.com: There are three sources of information for the descriptor protocol: - Data model reference (Doc/reference/datamodel.rst) - Descriptor HowTo guide (Doc/howto/descriptor.rst) - PEP 252 A developer who already knows descriptor tipically reads the first one: object.__get__(self, instance, owner) ... owner is always the owner class ... Reading a bit further there are the ways a descriptor can be called, and the direct call is x.__get__(a). That is, without the third argument (owner) specified. The how-to definition is slightly different: descr.__get__(self, obj, type=None) -- value Here the arguments have different names (type shadowing the type bultin) and it seems to be implied that the third argument is optional. The ClassMethod example at the end of the document seems to confirm this: def __get__(self, obj, klass=None): (though another example doesn't). And the method contains an explicit check on klass being None. Also it could be confusing that through the examples in the same document many different names are used for the same argument (type, objtype, klass), and all different than the name used in the reference. Lastly the PEP is more explicit: __get__(): a function callable with one or two arguments. [...] When X is None, the optional second argument, T, should be meta-object. [...] When both X and T are specified ... One more quirk: the reference explains the distinction between data and non-data descriptors, though says nothing about __set__ raising AttributeError for read-only data descriptors. My proposal: - use the same names for __get__ arguments throughout the documentation (both the reference and the tutorial), e.g. __get__(self, instance, owner) - decide whether the third argument should be optional, or state the common usage in the reference, and fix accordingly the examples in the howto - explain data, non-data and read-only descriptors in the __set__ reference, or more simply, how the defintion of __set__ affects these things. -- assignee: docs@python components: Documentation messages: 135974 nosy: davide.rizzo, docs@python priority: normal severity: normal status: open title: Harmonizing descriptor protocol documentation versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12077 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12078] re.sub() replaces only several matches
Changes by Andriy Rysin ary...@gmail.com: -- components: Regular Expressions files: repl.sh nosy: arysin priority: normal severity: normal status: open title: re.sub() replaces only several matches versions: Python 3.1 Added file: http://bugs.python.org/file21999/repl.sh ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12078] re.sub() replaces only several matches
Changes by Andriy Rysin ary...@gmail.com: Added file: http://bugs.python.org/file22000/repl.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12078] re.sub() replaces only several matches
Changes by Andriy Rysin ary...@gmail.com: Added file: http://bugs.python.org/file22001/test.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12078] re.sub() replaces only several matches
New submission from Andriy Rysin ary...@gmail.com: When trying to replace strings with parenthesis (in the given example - alternative writing of the words in Ukrainian) the sed replace performs correctly replacing all occurrences, while python3 re.sub() function replaces only first two -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5231] Change format of a memoryview
Changes by Mark Dickinson dicki...@gmail.com: -- assignee: mark.dickinson - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5231] Change format of a memoryview
Mark Dickinson dicki...@gmail.com added the comment: Unassigning. Sorry; no time for this at the moment. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10581] Review and document string format accepted in numeric data type constructors
Mark Dickinson dicki...@gmail.com added the comment: I find it convenient to use int(), float() etc. for data validation. Me too. This is why I'd still be happiest with int and float not accepting non-ASCII digits at all. (And also why the recent suggestions to allow extra underscores in int and float input make me uneasy.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10581 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: Is there anything preventing this patch from being merged? I have to make time to think about the API a bit more. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12042] What's New multiprocessing example error
Changes by Jordan Stadler jordan.stad...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file22002/issue12042_2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12042] What's New multiprocessing example error
Jordan Stadler jordan.stad...@gmail.com added the comment: Patch is up for 2.7, minor change in the documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12078] re.sub() replaces only several matches
Matthew Barnett pyt...@mrabarnett.plus.com added the comment: Argument 4 of re.sub is the maximum number of replacements, NOT flags: Help on function sub in module re: sub(pattern, repl, string, count=0, flags=0) Return the string obtained by replacing the leftmost non-overlapping occurrences of the pattern in string by the replacement repl. repl can be either a string or a callable; if a string, backslash escapes in it are processed. If it is a callable, it's passed the match object and must return a replacement string to be used. re.I is 2, so you're telling it to perform at most 2 replacements. -- nosy: +mrabarnett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8809] smtplib should support SSL contexts
Kasun Herath kasun...@gmail.com added the comment: I added a test to smtpnet and submitting a separate patch for it as my test_smtpnet.py file was old and could have had conflicts. I didn't use keys and certificates for the SSLContext as those would have to be shipped with the source. Looking forward for reviews and suggestions. -- Added file: http://bugs.python.org/file22003/smtp_sslcontext_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 12:20 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: Is there anything preventing this patch from being merged? I have to make time to think about the API a bit more. Ok. Maybe you will come up with another alternative that hadn't occurred to me. But I have given this issue quite a bit of thought, considered several alternatives, and felt fortunate to find a solution that preserves backwards compatibility, supports the property decorator syntax, and meshes well with the existing syntax for abstract methods. Perhaps, if you shared your concerns, I could help address them and maybe save you some time. Darrren -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11949] Make float('nan') unorderable
Mark Dickinson dicki...@gmail.com added the comment:
It seems we're getting a bit off-topic for the issue title; the discussion
about cleaning up test_math (which I agree would be a good thing to do) should
probably go into another issue.
On the issue itself, I'm -1 on making comparisons with float('nan') raise: I
don't see that there's a real problem here that needs solving.
Note that the current behaviour does *not* violate IEEE 754, since there's
nothing anywhere in IEEE 754 that says that Python's operation should raise
for comparisons involving NaNs: all that's said is that a conforming language
should provide a number of comparison operations (without specifying how those
operation should be spelt in the language in question), including both a
operation that's quiet (returning a false value for comparison with NaNs) and a
operation that signals on comparison with NaN. There's nothing to indicate
definitively which of these two operations '' should bind to in a language.
It *is* true that C chooses to bind '' to the signalling version, but that
doesn't automatically mean that we should do the same in Python.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6721] Locks in python standard library should be sanitized on fork
Nir Aides n...@winpdb.org added the comment: I think that generally it is better to deadlock than corrupt data. 2) acquiring locks just before fork is probably one of the best way to deadlock (acquiring a lock we already hold, or acquiring a lock needed by another thread before it releases its own lock). Apart from adding dealock avoidance/recovery mechanisms - which would be far from trivial - I don't see how we could solve this, given that each library can use its own locks, not counting the user-created ones a) We know the correct locking order in Python's std libraries so the problem there is kind of solved. b) We can put the burden of other locks on application developers and since currently no one registers atfork handlers, there is no problem there yet. 4) Python locks differ from usual mutexes/semaphores in that they can be held for quite some time (for example while performing I/O). Thus, acquiring all the locks could take a long time, and users might get irritated if fork takes 2 seconds to complete. We only need a prepare handler to acquire locks that protect data from corruption. A lock synchronizing IO which is held for long periods may possibly be initialized in child without being acquired in a prepare handler; for example, a lock serializing logging messages. In other cases or in general an atfork handler may reset or reinitialize a library without acquiring locks in a prepare handler. 5) Finally, there's a fundamental problem with this approach, because Python locks can be released by a thread other than the one that owns it. Imagine this happens: T1 T2 lock.acquire() (do something without releasing lock) fork() lock.release() This is perfectly valid with the current lock implementation (for example, it can be used to implement a rendez-vous point so that T2 doesn't start processing before T1 forked worker processes, or whatever). But if T1 tries to acquire lock (held by T2) before fork, then it will deadlock, since it will never be release by T2. I think we do not need to acquire rendezvous locks in a prepare handler. Initializing locks in child after fork without acquiring them before the fork may result in corrupted program state and so is probably not a good idea. Yes, but in practise, I think that this shouldn't be too much of a problem. Also note that you can very well have the same type of problem with sections not protected explicitely by locks: for example, if you have a thread working exclusively on an object (maybe part of a threadpool), a fork can very well happen while the object is in an inconsistent state. Acquiring locks before fork won't help that. I think a worker thread that works exclusively on an object does not create the problem: a) If the fork thread eventually needs to read the object then you need synchronization. b) If the worker thread eventually writes data into file or DB then that operation will be completed at the parent process. To summarize I think we should take the atfork path. An atfork handler does not need to acquire all locks, but only those required by library logic, which the handler is aware of, and as a bonus it can be used to do all sort of stuff such as cleaning up, reinitializing a library, etc... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11949] Make float('nan') unorderable
Mark Dickinson dicki...@gmail.com added the comment: Therefore making , , etc. raise on NaN while keeping the status quo for != and == would bring Python floats closer to compliance with IEEE 754. Not so. Either way, Python would be providing exactly 10 of the 22 required IEEE 754 comparison operations (see sections 5.6.1 and 5.11 of IEEE 754-2008 for details). If we wanted to move closer to compliance with IEEE 754, we should be providing all 22 comparisons. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11949] Make float('nan') unorderable
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
On the issue itself, I'm -1 on making comparisons
with float('nan') raise: I don't see that there's
a real problem here that needs solving.
Note that the current behaviour does *not* violate IEEE 754, ...
I agree with Mark. Am closing this feature request which is both ill-conceived
and likely to cause more harm than good (possibly breaking code that currently
does not fail).
the discussion about cleaning up test_math
(which I agree would be a good thing to do)
should probably go into another issue.
I agree.
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8650] zlibmodule.c isn't 64-bit clean
Roundup Robot devnull@devnull added the comment: New changeset 850624632e9a by Nadeem Vawda in branch '3.1': Issue #8650: Backport 64-bit safety fixes for compress() and decompress(). http://hg.python.org/cpython/rev/850624632e9a New changeset 99a3ce22c1ff by Nadeem Vawda in branch '3.2': Null merge (#8650): zlib.compress() and .decompress() are already 64-bit safe. http://hg.python.org/cpython/rev/99a3ce22c1ff New changeset dea5fcdc9ecd by Nadeem Vawda in branch 'default': Null merge (#8650): zlib.compress() and .decompress() are already 64-bit safe. http://hg.python.org/cpython/rev/dea5fcdc9ecd -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. This is true today in =python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? Darren -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. I'm not suggesting that it tag methods it receives as abstract. @getter/setter/deleter would still act the same. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. Why not? You could set the __abstractmethod__ attribute in abstractgetter(). This is true today in =python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? I find it produces a rather unfortunate ordering dependency for the decorators which is hard to remember. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. I'm not suggesting that it tag methods it receives as abstract. @getter/setter/deleter would still act the same. I wasn't talking about @getter/setter/deleter. I tried to be clear that I was talking about the abstractproperty() constructor. It doesn't currently tag the methods it receives as abstract, and to change this would be a backward incompatible change. Therefore, @abstractmethod should be used to tag methods as abstract before passing them to the abstractproperty() constructor, and the abc documentation should be changed to reflect this. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. Why not? You could set the __abstractmethod__ attribute in abstractgetter(). I was not talking about decorating before passing @abstractgetter. I was talking about decorating before passing to the abstractproperty() constructor. This is true today in =python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? I find it produces a rather unfortunate ordering dependency for the decorators which is hard to remember. Why is it difficult to remember that you need to tag a method as abstract before passing it to the property? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12078] re.sub() replaces only several matches
Ezio Melotti ezio.melo...@gmail.com added the comment: See #11957. -- nosy: +ezio.melotti resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - re.sub confusion between count and flags args ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: Okay: how about this. We retain the passing of @abstractmethod to abstractpropert(), but @abstractgetter decorates the method for you. 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. I'm not suggesting that it tag methods it receives as abstract. @getter/setter/deleter would still act the same. I wasn't talking about @getter/setter/deleter. I tried to be clear that I was talking about the abstractproperty() constructor. It doesn't currently tag the methods it receives as abstract, and to change this would be a backward incompatible change. Therefore, @abstractmethod should be used to tag methods as abstract before passing them to the abstractproperty() constructor, and the abc documentation should be changed to reflect this. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. Why not? You could set the __abstractmethod__ attribute in abstractgetter(). I was not talking about decorating before passing @abstractgetter. I was talking about decorating before passing to the abstractproperty() constructor. This is true today in =python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? I find it produces a rather unfortunate ordering dependency for the decorators which is hard to remember. Why is it difficult to remember that you need to tag a method as abstract before passing it to the property? I don't think the common case should be passing things to abstractproperty(), rather using the decorator. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate Python interpreter (so 3.1's idle.bat does not accidently use python26.exe)
Roundup Robot devnull@devnull added the comment: New changeset 536ec6206584 by Kurt B. Kaiser in branch '3.1': Issue #6378: Further adjust idle.bat to start associated Python http://hg.python.org/cpython/rev/536ec6206584 New changeset cd55c6960d86 by Kurt B. Kaiser in branch '3.2': Merge from 3.1 http://hg.python.org/cpython/rev/cd55c6960d86 New changeset ec3e73a25d84 by Kurt B. Kaiser in branch 'default': Merge from 3.2 http://hg.python.org/cpython/rev/ec3e73a25d84 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12078] re.sub() replaces only several matches
Andriy Rysin ary...@gmail.com added the comment: Ahh, I guess I should have read the docs. But then looks like I am not the fist or only one so it's not as embarrassing. :) I would support the proposal in #11957 to make re flags non-int object -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: Okay: how about this. We retain the passing of @abstractmethod to abstractpropert(), but @abstractgetter decorates the method for you. That can work, although I would advise against it. I find it strange that we would use @abstractmethod sometimes and not others. If that is what it takes to get the patch accepted, so be it. But since I don't understand the motivation behind this approach, I won't be the one to document the special cases of when @abstractmethod is required and when it is not. 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 5:17 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 4:28 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: I still dislike the reduntancy of having abstractmethod and abstractproperty on a method. I think a better idea is having abstractproperty.abstract(getter/setter/deleter). Right, but I explained why the redundancy is necessary in order to preserve backwards compatibility. If the abstractproperty constructor were changed to tag methods it receives as abstract, it would be a backwards-incompatible change in behavior with potential consequences for consumers of abstractproperty. I'm not suggesting that it tag methods it receives as abstract. @getter/setter/deleter would still act the same. I wasn't talking about @getter/setter/deleter. I tried to be clear that I was talking about the abstractproperty() constructor. It doesn't currently tag the methods it receives as abstract, and to change this would be a backward incompatible change. Therefore, @abstractmethod should be used to tag methods as abstract before passing them to the abstractproperty() constructor, and the abc documentation should be changed to reflect this. abstractproperty.abstract(getter/setter/deleter) could be implemented, but it still wouldn't change the fact that if a getter/setter is intended to be abstract, it needs to be decorated with @abstractmethod before being passed to the abstractproperty() constructor. Why not? You could set the __abstractmethod__ attribute in abstractgetter(). I was not talking about decorating before passing @abstractgetter. I was talking about decorating before passing to the abstractproperty() constructor. This is true today in =python-3.2: its not mentioned in the documentation, but the behavior exists all the same. Properties are composite objects, their behavior is defined by it is the setters/getters/deleters they receive. So its actually a very conceptually clean solution to decorate a method with @abstractmethod, and it fits really nicely with the rest of the abc module. Why does abstractproperty need special abstract(setter/getter/deleter) methods, when the existing methods combine with @abstractmethod in a clean way to produce the exact same result? To save one line of code? I find it produces a rather unfortunate ordering dependency for the decorators which is hard to remember. Why is it difficult to remember that you need to tag a method as abstract before passing it to the property? I don't think the common case should be passing things to abstractproperty(), rather using the decorator. It definitely is a common case, and always will be. You can't begin using abstractproperty.abstract(getter/setter/deleter) until you have an abstract property, which requires passing a (potentially abstract) method to the constructor. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 5:55 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: Okay: how about this. We retain the passing of @abstractmethod to abstractpropert(), but @abstractgetter decorates the method for you. That can work, although I would advise against it. I find it strange that we would use @abstractmethod sometimes and not others. If that is what it takes to get the patch accepted, so be it. But since I don't understand the motivation behind this approach, I won't be the one to document the special cases of when @abstractmethod is required and when it is not. It would just be a convenience. It definitely is a common case, and always will be. You can't begin using abstractproperty.abstract(getter/setter/deleter) until you have an abstract property, which requires passing a (potentially abstract) method to the constructor. What about @abstractproperty def something(): pass @abstractproperty.setter def set(): pass @abstractproperty.deleter def delete: pass requires you to pass a method (explicitly) to a constructor? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8650] zlibmodule.c isn't 64-bit clean
Roundup Robot devnull@devnull added the comment: New changeset 0b5211d19a14 by Nadeem Vawda in branch '3.1': Issue #8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean. http://hg.python.org/cpython/rev/0b5211d19a14 New changeset 3ff862d05d18 by Nadeem Vawda in branch '3.2': Merge: #8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean. http://hg.python.org/cpython/rev/3ff862d05d18 New changeset f86a22b6ab58 by Nadeem Vawda in branch 'default': Merge: #8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean. http://hg.python.org/cpython/rev/f86a22b6ab58 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11957] re.sub confusion between count and flags args
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12059] hashlib does not handle missing hash functions correctly
Roundup Robot devnull@devnull added the comment: New changeset 572fbd9ca28f by Gregory P. Smith in branch '2.7': Fixes Issue #12059: Properly handle missing hash functions even when http://hg.python.org/cpython/rev/572fbd9ca28f New changeset ad9249f35914 by Gregory P. Smith in branch '3.2': Fixes Issue #12059: Properly handle missing hash functions even when http://hg.python.org/cpython/rev/ad9249f35914 New changeset 29fd46b0 by Gregory P. Smith in branch 'default': Fixes Issue #12059: Properly handle missing hash functions even when http://hg.python.org/cpython/rev/29fd46b0 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: On Sat, May 14, 2011 at 6:24 PM, Benjamin Peterson rep...@bugs.python.org wrote: Benjamin Peterson benja...@python.org added the comment: 2011/5/14 Darren Dale rep...@bugs.python.org: Darren Dale dsdal...@gmail.com added the comment: It definitely is a common case, and always will be. You can't begin using abstractproperty.abstract(getter/setter/deleter) until you have an abstract property, which requires passing a (potentially abstract) method to the constructor. What about @abstractproperty def something(): pass @abstractproperty.setter def set(): pass @abstractproperty.deleter def delete: pass requires you to pass a method (explicitly) to a constructor? @abstractproperty def something(): pass takes the something function and passes it to the abstractproperty() constructor. It doesn't appear that you are familiar with how the decorator syntax works for properties. Here is how your example should probably look: @abstractproperty def something(): pass @something.setter def something(): pass @something.deleter def something(): pass -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12059] hashlib does not handle missing hash functions correctly
Changes by Gregory P. Smith g...@krypto.org: -- assignee: - gregory.p.smith resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12059 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12060] Python doesn't support real time signals
Gregory P. Smith g...@krypto.org added the comment: if you used the pipe approach you'd need to deal with the case of the write blocking (or failing if nonblocking) when the pipe buffer is full. also you'd need to block signals around a fork and reinitialize the pipe in the child before reenabling signals. i think all of this is overkill. as said, this isn't a real problem. -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8650] zlibmodule.c isn't 64-bit clean
Nadeem Vawda nadeem.va...@gmail.com added the comment: Fixed in 3.1, 3.2 and 3.3. 2.7 no longer has this problem -- the fix for issue8651 ensures that the functions cannot receive inputs large enough to be problematic (since we don't define PY_SSIZE_T_CLEAN). -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed versions: +Python 3.1, Python 3.2, Python 3.3 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6721] Locks in python standard library should be sanitized on fork
Charles-François Natali neolo...@free.fr added the comment: a) We know the correct locking order in Python's std libraries so the problem there is kind of solved. I think that you're greatly under-estimating the complexity of lock ordering. If we were just implementing a malloc implementation protected with a single mutex, then yes, it would be simple. But here, you have multiple libraries with each their own locks, locks at the I/O layer, in the socket module (some name resolution libraries are not thread-safe), and in many other places. And all those interact. For example, buffered I/O objects each have their own lock (Antoine, correct me if I'm wrong). It's a common cause of deadlock. Now imagine I have a thread that logs information to a bz2 stream, so that it's compressed on-the-fly. Sounds reasonable, no? Well, the lock hierarchy is: buffered stream lock bz2-level lock logging object I/O lock Do you still think that getting the locking order right is easy? Another example, with I/O locks (and if you're concerned with data corruption, those are definitely the one you would want to handle with atfork): I have a thread blocking on a write (maybe the output pipe is full, maybe it's a NFS file system and the server takes a long time to respond, etc. Or maybe it's just waiting for someone to type something on stdin.). Another thread forks. The atfork-handler will try to acquire the buffered I/O object's lock: it won't succeed until the other threads finally manages to write/read. It could take seconds, or forever. And there are many other things that could go wrong, because contrarily to a standalone and self-contained library, Python is made of several components, at different layers, that can call each other in an arbitrary order. Also, some locks can be held for arbitrarily long. That's why I still think that this can be fully handled by atfork handlers. But don't get me wrong: like you, I think that we should definitely have an atfork mechanism. I just think it won't be able to solve all the issues, and that I can also bring its own set of troubles. Concerning the risk of corruption (invariant broken), you're right. But resetting the locks is the approach currently in use for the threading module, and it seems to work reasonably well there. Finally, I'd just like to insist on a point: In a multi-threaded program, between fork and exec, the code must be async-safe. This means that in theory, you can't call pthread_mutex_release/pthread_mutex_destroy, fwrite, malloc, etc. Period. This means that in theory, we shouldn't be running Python code at all! So if we really wanted to be safe, the only solution would be to forbid fork() in a multi-threaded program. Since it's not really a reasonable option, and that the underlying platform (POSIX) doesn't allow to be safe either, I guess that the only choice left is to provide a bet-try implementation, knowing perfectly that there will always be some corner cases that can't be handled. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6721 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12060] Python doesn't support real time signals
Charles-François Natali neolo...@free.fr added the comment: if you used the pipe approach you'd need to deal with the case of the write blocking (or failing if nonblocking) when the pipe buffer is full. Well, a pipe is 64K on Linux (4K on older kernels). Given that each signal received consumes one byte, I'd be pretty surprised if we managed to fill the pipe before Py_CheckSignals() gets called. i think all of this is overkill. as said, this isn't a real problem. Definitely. Do you think this can be closed as wont fix ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12060] Python doesn't support real time signals
Gregory P. Smith g...@krypto.org added the comment: if someone comes up with a situation where this is a real problem, feel free to reopen it. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Darren Dale dsdal...@gmail.com added the comment: It just occurred to me, there is a potential problem with abstractproperty and the decorator syntax in my patch: class Foo: @abstractproperty def p(self): pass # p is abstract, but has no abstract methods @p.setter def p(self, val): pass # p has no abstract properties, at this point it becomes an instance # of property, not abstractproperty @p.deleter @abstractmethod def p(self): pass # the deleter was tagged as abstract, but p was already a # regular property. There is no way to turn a regular # property into an abstractproperty, so the abstractedness # of the deleter is not respected. Really, the ideal approach is the original one: provide the builtin property with an __isabstractmethod__ attribute, which is set to True if the property has any abstract methods, and False otherwise. (My C is probably too weak to modify the property builtin on my own). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11610] Improving property to accept abstract methods
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- nosy: +stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11610 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12038] assertEqual doesn't display newline differences quite well
Gregory P. Smith g...@krypto.org added the comment: We should ensure that the first differing character in the string is always included in what is displayed as a diff. if we're going to shorten a string we should elide something that matches. -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12038 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1615158] POSIX capabilities support
Ross Lagerwall rosslagerw...@gmail.com added the comment: Adding this to the posix module would enforce linking with lcap and lattr always. The development headers for these are not installed by default on some distributions. I think it would be better if they are added to a separate module (especially since all the functions are prefixed with cap_, it is like they are in their own namespace) which means that the module is optional for people that don't have/want to build the functionality. What are your thoughts? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1615158 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
