[issue46905] winsound.PlaySound should accept pathlib.Path instances
New submission from Julian : The library function winsound.PlaySound takes a sound parameter. One of the valid arguments is a path to a WAV filename. Since Python 3.4, paths can be cleanly represented with PathLib.Path instances. However, if you pass a Path instance to PlaySound, it responds with: TypeError: 'sound' must be str or None, not 'WindowsPath' This can be quickly fixed in the caller by passing str(the_path_instance) instead, but it would be cleaner if PlaySound accepted Python's preferred method of representing paths. -- components: Library (Lib) messages: 414393 nosy: Julian-O priority: normal severity: normal status: open title: winsound.PlaySound should accept pathlib.Path instances type: enhancement ___ Python tracker <https://bugs.python.org/issue46905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7317] Display full tracebacks when an error occurs asynchronously
Julian added the comment: The formatting isn't very conventional for Python. Why not use the normal format? i.e. Traceback (most recent call last): File "/tmp/bla.py", line 4, in __del__ None.someattr AttributeError: 'NoneType' object has no attribute 'someattr' Why is this more likely to get confused with user input than other unhandled exceptions? If you ARE going to deviate, it may be helpful to have it explain why this exception wasn't caught through the normal channels. Maybe the last line could be: "Failed to raise this exception in __del__/finalizer method." or similar. -- ___ Python tracker <http://bugs.python.org/issue7317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7317] Display full tracebacks when an error occurs asynchronously
Julian added the comment: I wish there was a less instrusive of saying "+1. I'm happy. Thanks." than posting a whole comment, but until then: +1. I'm happy. Thanks. (I haven't inspected the code - just based on the description.) -- ___ Python tracker <http://bugs.python.org/issue7317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12330] Named set methods on collections.Set and dict view objects
New submission from Julian : collections.Set / collections.MutableSet do not provide any of the named set methods, nor do dict view objects (neither as viewkeys and friends create them nor in py3). They obviously implement the operator methods correctly, but besides the fact that they're not fully implementing the set API, .union, .difference, and .intersection, for example, take *args to do arbitrary unions / difference / intersections, so there's at least one functionality gap too (nothing a for loop can't fix but, yeah). I've attached a very quick example diff'ing the methods which I ran on 2.7 and 3.2. In searching around for a reason, or at least some documentation or acknowledgement that this is intentional, I see there's an offhand comment on Issue7771 (I apologize in advance if this didn't deserve its own ticket then). Issue9212 was accepted as "an oversight" and is related, so I hope that it's worth the clarification as to whether 1. we (you :) are planning / willing to do this fix on 2.7, or 3.2, or 2. if this is desired for some reason, in which case consider this simply a documentation request and perhaps a dupe of 7771 then. Now that I've been long winded thanks for your time :). -- components: Library (Lib) files: namedmeths.py messages: 138286 nosy: Julian priority: normal severity: normal status: open title: Named set methods on collections.Set and dict view objects type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file22358/namedmeths.py ___ Python tracker <http://bugs.python.org/issue12330> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12330] Named set methods on collections.Set and dict view objects
Changes by Julian : -- versions: -Python 2.6, Python 3.1 ___ Python tracker <http://bugs.python.org/issue12330> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12330] Named set methods on collections.Set and dict view objects
Julian added the comment: Oh boy. Reading the comment in Issue9212 more carefully now that you said that I see that Mr. Hettinger said exactly that. I apologize for missing it the first time. "Concrete classes are allowed to have more features than the corresponding ABC. The ABCs are not intended to be full-featured; instead, they specify the part of the API that will be guaranteed. For example, the union() method for built-in sets allows two or more set arguments, but the corresponding method for the ABC is limited to two arguments. This was an intentional difference, designed to make it easier for people to implement a Set class." I suppose I should close this, unless there's some hope perhaps of some elaboration on that last line. Why couldn't collections provide the named methods too (in what way is this "easier"?) -- ___ Python tracker <http://bugs.python.org/issue12330> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12330] Named set methods on collections.Set and dict view objects
Changes by Julian : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue12330> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12445] dict view values objects are missing tp_richcmp and tp_as_number
New submission from Julian : dict view values() objects are missing tp_richcmp and tp_as_sequence, and the tests for those were incomplete, which means that on 2.7 and 3.2 (and on current head) viewvalues / values objects don't compare correctly. Without indication, I assume this is not the desired behavior. Looks like the cause is that the dictview_richcompare function was written to expect a set-like object, and nothing was written for values. I've modified it to accept any view object and do the appropriate check. One thing I'm unsure of, which I'm sure one of you will help with, is what the desired behavior is on what values() view objects actually *should* be equal to. Being that there isn't a multiset object, and that I couldn't find any resource, I assumed that they only should be equal to other values() objects, not any of the other (ordered) containers. If that's incorrect, or if I need to discuss that on the mailing list, please let me know. A patch to fix both is attached with the correction to the unit test, hope I did this correctly. I assume this needs to be backported to 2.7, but I figured I'd ask about that first. (Test suite runs without errors on current 3.3 head with this patch for me). dictview_richcompare also needs unit tests for the NotImplemented error that it should return, but I didn't want to convolute this patch, please let me know if I should put that in here, or file another ticket, or neither. Thanks! -- components: Interpreter Core files: viewvalues_compare.patch keywords: patch messages: 139455 nosy: Julian priority: normal severity: normal status: open title: dict view values objects are missing tp_richcmp and tp_as_number type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file22518/viewvalues_compare.patch ___ Python tracker <http://bugs.python.org/issue12445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12445] dict view values objects are missing tp_richcmp and tp_as_number
Julian added the comment: Looking over this again with a clear head, adding the number operators is the incorrect thing to do here I think, since that function was also written assuming we had a set-like view object as input. I am inclined to think that the correct behavior here for those operators is to not change that function, but to not make values objects add-able at all, even with other values objects, which would probably be the only other logical choice, so leaving that as it was before (but still making the equality change). -- ___ Python tracker <http://bugs.python.org/issue12445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12487] urllib2.urlopen() returns object missing context manager
Julian added the comment: You probably should bring this up again on #4972 which is being worked on. (and for the immediate future you have contextlib.closing too in case you hadn't seen it already) -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue12487> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12579] str.format_map raises a SystemError for non-mapping
New submission from Julian :
Attached is just a failing test case (just `print("{}".format_map(12))`),
haven't been able to decipher the chain of calls in the unicodeobject.c code
yet to see where the best place to put the fix would be (inside do_format_map
before the pass back upwards maybe?).
Assuming this should be a TypeError obviously, soon as I can figure out where
to put the fix I'll update the patch.
--
components: Interpreter Core
files: format_map_err.patch
keywords: patch
messages: 140528
nosy: Julian
priority: normal
severity: normal
status: open
title: str.format_map raises a SystemError for non-mapping
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22681/format_map_err.patch
___
Python tracker
<http://bugs.python.org/issue12579>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12579] str.format_map raises a SystemError for non-mapping
Julian added the comment:
Yeah, I saw the line you suggested and didn't think that was it.
To expand on this, perhaps "{foo}".format(12) should raise a TypeError as well?
I'd expect that more than the current behavior which is a KeyError. That
KeyError is getting raised in get_field_object, which is where the fix needs to
be, or at least needs to be changed, I'm just trying not to duplicate code.
--
___
Python tracker
<http://bugs.python.org/issue12579>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12579] str.format_map raises a SystemError for non-mapping
Julian added the comment: Sorry for the double post, meant to say, in line 506. -- ___ Python tracker <http://bugs.python.org/issue12579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12579] str.format_map raises a SystemError for non-mapping
Julian added the comment: Fair enough. I suppose I take .format_map to mean, here is a mapping, call __getitem__ on it for each of the keys inside the format string, to which calling 12["foo"] would get me a TypeError. I suppose I see both as appropriate, but the fact that it's implemented by passing the mapping as kwargs seemed less relevant. Less concerned about that part though I guess. -- ___ Python tracker <http://bugs.python.org/issue12579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12579] str.format_map raises a SystemError for format strings with positional arguments
Julian added the comment: Well you're right :). I appreciate you taking more time to help me with this than you could have yourself. I made the change (and changed the TypeError to a ValueError as per your discovery that this was just a positional value issue, hope you agree with that). Ran the whole test suite, all passes, other than the one test that fails for me without the patch too. I'm not too happy with the wording on the error, "Format string contained positional fields" doesn't sound nearly specific enough, but I was weary to put something specifically referencing str.format_map in a function that handles str.format as well? Anyways, appreciate the help again, please let me know if anything needs fixing :). -- Added file: http://bugs.python.org/file22682/format_map_err.patch ___ Python tracker <http://bugs.python.org/issue12579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12579] str.format_map raises a SystemError for format strings with positional arguments
Changes by Julian : Removed file: http://bugs.python.org/file22682/format_map_err.patch ___ Python tracker <http://bugs.python.org/issue12579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12579] str.format_map raises a SystemError for format strings with positional arguments
Julian added the comment: Added, updated the patch :). Thank you! -- Added file: http://bugs.python.org/file22683/format_map_err.patch ___ Python tracker <http://bugs.python.org/issue12579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12579] str.format_map raises a SystemError for format strings with positional arguments
Changes by Julian : Removed file: http://bugs.python.org/file22681/format_map_err.patch ___ Python tracker <http://bugs.python.org/issue12579> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7317] Display full tracebacks when an error occurs asynchronously
Julian added the comment: Amaury asks: "Is there an already existing flag that could control this behaviour?" I wonder if the warnings module could be used. -- nosy: +oddthinking ___ Python tracker <http://bugs.python.org/issue7317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10306] Weakref callback exceptions should be turned into warnings.
New submission from Julian :
If a weakref callback raises an exception, weakref writes out some text (to
stderr, I think) and ignores it.
I think it would be more appropriate if weakref emitted that text using the
Python warning module, to allow it to be better controlled.
Consider this code with two foolish mistakes in it:
-
import warnings
import weakref
warnings.simplefilter('ignore') # Whoops, ignoring warnings is foolish.
def callback(condemned_object):
raise Exception("Failure") # Whoops, raising an exception in a callback is
foolish.
class RandomObject(object):
pass
strong_ref = RandomObject()
wr = weakref.proxy(strong_ref, callback)
print "Removing the only strong reference"
strong_ref = None
# No guarantee that the garbage collector will trigger
# in practice, in CPython, it does.
print "Shutting down now."
-
When I run this I get:
Removing the only strong reference
Exception Exception: Exception('Failure',) in
ignored
Shutting down now.
The exception text is output even though I don't want it to be. To help me
debug, I want for the exception text to be manageable (not by ignoring it, like
in the example above, but using the other warnings module features.)
--
components: Library (Lib)
messages: 120375
nosy: oddthinking
priority: normal
severity: normal
status: open
title: Weakref callback exceptions should be turned into warnings.
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue10306>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10306] Weakref callback exceptions should be turned into warnings.
Julian added the comment: Thank you, Antoine, you make a good point. In my example, I am suppressing the warning, which, I agree isn't a good idea. In my real life usage, I was getting an unexpected exception in a callback in code written by another person. I wanted not to suppress the warning, but to turn it into an exception to help trace the cause. Thinking about this further, (if it was a warning, as I suggest,) I now believe that would raise that exception into the garbage collector which might have some unpredictable consequences. I have rejected my own Issue for this reason. I maintain that the current solution isn't terribly helpful. Getting this output to stderr is neither helpful to me, in development (i.e. nothing in the error indicated it was related to the weakref functionality) nor my users in production (fortunately the problem was caught before then!) However, I concede my proposal isn't the right solution. Thank you again for your comment. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue10306> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12130] regex 0.1.20110514 findall overlapped not working with 'start of string' expression
New submission from Julian : Trying to use regex 0.1.2011051 with the overlapped=True feature It works great, unless I have the 'start of string' (caret) character in my regular expression: >>> regex.findall(r"a.*b","abadalaba",overlapped=True) ['abadalab', 'adalab', 'alab', 'ab'] >>> regex.findall(r"^a.*b","abadalaba",overlapped=True) ['abadalab'] -- components: Regular Expressions messages: 136405 nosy: jcerruti priority: normal severity: normal status: open title: regex 0.1.20110514 findall overlapped not working with 'start of string' expression versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12130] regex 0.1.20110514 findall overlapped not working with 'start of string' expression
Julian added the comment: Sorry for posting in the wrong tracker. I'm a bit dumb: can you please point me to the right tracker? I know ^ should match the beginning of the string, but there are multiple overlapping matches with the beginning of the string (as the first set of results show). Maybe I'm missing something subtler here? -- ___ Python tracker <http://bugs.python.org/issue12130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12130] regex 0.1.20110514 findall overlapped not working with 'start of string' expression
Julian added the comment: Just in case somebody else stumbles upon this, I ended up posting here: https://code.google.com/p/mrab-regex-hg/issues/detail?id=10 -- ___ Python tracker <http://bugs.python.org/issue12130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10476] __iter__ on a byte file object using a method to return an iterator
New submission from Julian : Iterating over a byte file object using __iter__ is rather useless, and a bit confusing perhaps. It'd be nice to propose two things: 1. Having __iter__ raise an exception if the file was opened with the "b" flag. 2. Adding a new by_bytes() method to file objects, which would return an iterator that yielded the next byte in the file, introducing the ability to write a similar `for byte in byte_file_obj.by_bytes()` that is currently possible when iterating by line over non-byte files. It's quite easy to do (2) currently, obviously, but perhaps it's worthy of consideration for inclusion. -- components: IO messages: 121820 nosy: Julian priority: normal severity: normal status: open title: __iter__ on a byte file object using a method to return an iterator type: feature request versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue10476> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8595] Unexpected default timeout in http-client-related libraries
New submission from Julian : Since Python 2.6, httplib has offered a timeout parameter for fetches. As the documentation explains, if this parameter is not provided, it uses the global default. What the document doesn't explain is httplib builds on top of the socket library. The socket library has a default timeout of None (i.e. forever). This may be an appropriate default for general sockets, but it is a poor default for httplib; typical http clients would use a timeout in the 2-10 second range. This problem is propagated up to urllib2, which sits on httplib, and further obscures that the default might be unsuitable. >From an inspection of the manuals, Python 3.0.1 suffers from the same problem >except, the names have changed. urllib.response sits on http.client. I, for one, made a brutal mistake of assuming that the "global default" would be some reasonable default for fetching web pages; I didn't have any specific timeout in mind, and was happy for the library to take care of it. Several million successful http downloads later, my server application thread froze waiting forever when talking to a recalcitrant web-server. I imagine others have fallen for the same trap. While an ideal solution would be for httplib and http.client to use a more generally acceptable default, I can see it might be far too late to make such a change without breaking existing applications. Failing that, I would recommend that the documentation for httplib, urllib, urllib2, http.client and urllib.request (+ any other similar libraries sitting on socket? FTP, SMTP?) be changed to highlight that the default global timeout, sans deliberate override, is to wait a surprisingly long time. -- assignee: d...@python components: Documentation, Library (Lib) messages: 104763 nosy: d...@python, oddthinking priority: normal severity: normal status: open title: Unexpected default timeout in http-client-related libraries type: behavior versions: Python 2.6, Python 2.7, Python 3.1 ___ Python tracker <http://bugs.python.org/issue8595> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8595] Explain the default timeout in http-client-related libraries
Julian added the comment: @orsenthil: Consider the definition of httplib.HTTPConnection.__init__(), in Python 2.6. def __init__(self, host, port=None, strict=None, timeout=socket._GLOBAL_DEFAULT_TIMEOUT): This could be replaced with: def __init__(self, host, port=None, strict=None, timeout=10): or, perhaps better, def __init__(self, host, port=None, strict=None, timeout=httplib._HTTP_DEFAULT_TIMEOUT): This timeout value is passed to the call in socket.create_connection, so I believe if it is overriden, it only applies to the relevant sockets and not to all sockets globally. Note: I am not arguing here that this SHOULD be done - it would break existing applications, especially those that were written before Python 2.6 - merely that it COULD be done. -- ___ Python tracker <http://bugs.python.org/issue8595> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38895] performance degradation creating a mock object
New submission from Julian : There seems to be a performance issue when creating a Mock() object from unittest module. The performance difference between 3.7.x and 3.8.0 is about 7-8 times slower in 3.8 Heres the smalles sample i could generate: Using python 3.7.5 ``` python3 -m timeit -v --number=10 --setup="from unittest.mock import Mock" "Mock()" raw times: 2.99 sec, 2.96 sec, 3.33 sec, 2.98 sec, 2.92 sec 10 loops, best of 5: 29.2 usec per loop ``` Using python 3.8.0 ``` python3 -m timeit -v --number=10 --setup="from unittest.mock import Mock" "Mock()" raw times: 16.9 sec, 17 sec, 17.7 sec, 18.1 sec, 16.3 sec 10 loops, best of 5: 163 usec per loop ``` I did not find that issue, but a co-worker. -- messages: 357297 nosy: julianhille priority: normal severity: normal status: open title: performance degradation creating a mock object type: performance versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue38895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38895] performance degradation creating a mock object (by factor 7-8)
Change by Julian : -- title: performance degradation creating a mock object -> performance degradation creating a mock object (by factor 7-8) ___ Python tracker <https://bugs.python.org/issue38895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17195] Reading source code from file on exception
New submission from Julian: When an exception occurs and a traceback is printed, the source code is read from the file which leads to confusion when the file has been modified, but the code that produced the exception still had the old code in memory. -- components: Interpreter Core messages: 181971 nosy: Mezgrman priority: normal severity: normal status: open title: Reading source code from file on exception type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue17195> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46253] C API documentation of Py_UNICODE_* character properties macros use Py_UNICODE instead of Py_UCS4
New submission from Julian Gilbey : The documentation at https://docs.python.org/3/c-api/unicode.html?highlight=isalpha#unicode-character-properties lists a series of macros such as Py_UNICODE_ISSPACE(Py_UNICODE ch). However, the input type for these macros was changed from Py_UNICODE to Py_UCS4 in commit 324ac65cebf4b0141b946452a2604715f1ca7010 on Wed Aug 18 20:44:58 2010 +, but it seems that the documentation has never been updated. The fix should be easy; I'll make a PR for it. -- assignee: docs@python components: Documentation messages: 409649 nosy: docs@python, juliangilbey priority: normal severity: normal status: open title: C API documentation of Py_UNICODE_* character properties macros use Py_UNICODE instead of Py_UCS4 versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46253] C API documentation of Py_UNICODE_* character properties macros use Py_UNICODE instead of Py_UCS4
Change by Julian Gilbey : -- keywords: +patch pull_requests: +28595 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30387 ___ Python tracker <https://bugs.python.org/issue46253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Julian Berman added the comment: I was unsuccessful building tip with any of the 3 compilers. Full paste of output from ./configure and make, along with haypo's test file are attached. http://paste.pound-python.org/show/14320/ I'm on 10.7.2, XCode is 4.1 (compiler versions in the paste). Upgrading to XCode 4.2 is undesirable, since it removes vanilla gcc. Myself and a few others are avoiding upgrading until homebrew adds vanilla gcc and / or Apple gets things fully sorted, so, being able to build with this would be nice. -- ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Julian Berman added the comment: Never mind, yes, you're correct, somehow my build dir must have been dirty. Sorry bout that. -- ___ Python tracker <http://bugs.python.org/issue13241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13437] Provide links to the source code for every module in the documentation
New submission from Julian Berman : The documentation occasionally contains a link to the source code for a module in the stdlib. See for instance http://docs.python.org/library/urlparse.html and http://docs.python.org/library/collections.html , or many others. With a quick perusal, I couldn't immediately guess as to which ones managed to have one and which ones don't, but it'd be convenient to have a link in as many places as possible, which is certainly more than we have now. (See e.g. http://docs.python.org/library/json.html and http://docs.python.org/library/itertools.html and many others for examples of pages that lack a link). Perhaps putting it in a more conspicuous but still consistent location would be reasonable (the sidebar?). -- assignee: docs@python components: Documentation messages: 147973 nosy: Julian, docs@python priority: normal severity: normal status: open title: Provide links to the source code for every module in the documentation type: feature request versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13437] Provide links to the source code for every module in the documentation
Julian Berman added the comment: Here's first a quick list from one pass over the docs. I've attempted to limit myself to a few like you've suggested, though I'll wait for confirmation that Raymond is not willing to simply add them to everything once we're at it :). http://docs.python.org/library/difflib.html http://docs.python.org/library/stringio.html http://docs.python.org/library/codecs.html http://docs.python.org/library/stringprep.html http://docs.python.org/library/datetime.html http://docs.python.org/library/math.html http://docs.python.org/library/cmath.html http://docs.python.org/library/decimal.html http://docs.python.org/library/itertools.html http://docs.python.org/library/os.path.html http://docs.python.org/library/csv.html http://docs.python.org/library/configparser.html http://docs.python.org/library/logging.html http://docs.python.org/library/getpass.html http://docs.python.org/library/json.html http://docs.python.org/library/urllib2.html http://docs.python.org/library/unittest.html http://docs.python.org/library/code.html When I hit the docs to diagnose a problem, it's usually to take a quick look, and then to hit the source code to read that too, since most of the stuff that's in general use is common enough for me to know how it works in a general sense, so the source code is typically where I go pretty quickly after reading what the docs have to say. It's not a huge deal obviously, hg.python.com is not the furthest thing away. Just seems convenient, especially since like I said a lot of the other ones I peek at already have links. As for non-python modules, I really would like to say that linking to C source sounds just as reasonable to me, a little C never killed anyone :), but I don't want to push my luck, so I'll stick with whatever I can get here I guess (I know I put some non-python modules on the list). -- ___ Python tracker <http://bugs.python.org/issue13437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13437] Provide links to the source code for every module in the documentation
Julian Berman added the comment: Well, if there's opposition I don't know how strongly I feel about this then, but I generally agree with you Ezio, if there's an occasion where 1) applies fixing the docs is certainly reasonable. If I'm checking the source though, it's not necessarily since the documentation is unclear, just that it's often easier to read code than English. But, I guess if no one else feels it'd be helpful feel free to close this then. -- ___ Python tracker <http://bugs.python.org/issue13437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13523] Python does not warn in module .py files does not exist if there is still a .pyc file
Julian Berman added the comment: I know this is a feature, and on occasion as pointed out a useful one. But in some cases it can be a tad annoying as the OP probably considered it. I had a recent example where a lingering .pyc made my test suite pass (and me nearly push broken code) despite the fact that I'd moved the file away and edited it, with bugs. Obviously I now remember to rebuild and remove all .pyc's before I commit, but it took a near miss to remind me to. Would it be useful to have a command line flag that did something like this (perhaps that test runners could set by default) to prevent others from running into similar situations? -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue13523> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13585] Add contextlib.CleanupManager
Julian Berman added the comment: For reference, the implementation that I posted in the other thread is: @contextlib.contextmanager def maybe(got, contextfactory, *args, checkif=bool, **kwargs): if checkif(got): yield got else: with contextfactory(*args, **kwargs) as got: yield got which produces code like: def fn(input_file=None): with maybe(input_file, open, "/default/input/file/location/"): for line in input_file: print line For the example given here in the OP, since rmtree isn't a contextmanager it'd require wrapping it in one first. I could probably understand if there was desire for these to be a recipe instead. The advantage (if any) of the above over this class is that it keeps context managers sorta looking like context managers. Here if you wanted to write my example it'd require writing code like with ContextManager() as mgr: foo = ctxtmgr() mgr.register(foo.__close__) which doesn't look too great :/ The class though does have wider scope though, since it doesn't necessarily only need a context manager, it can do cleanup for anything, which I guess is nice. -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue13585> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7897] Support parametrized tests in unittest
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue7897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13774] json.loads raises a SystemError for invalid encoding on 2.7.2
New submission from Julian Berman :
>>> import json
>>> json.loads("{}", [1, 2, 3])
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/Cellar/python/2.7.2/lib/python2.7/json/__init__.py", line
339, in loads
return cls(encoding=encoding, **kw).decode(s)
File "/usr/local/Cellar/python/2.7.2/lib/python2.7/json/decoder.py", line
359, in __init__
self.scan_once = scanner.make_scanner(self)
SystemError: NULL result without error in PyObject_Call
Python 3.2 and 2.6 are not affected it'd seem, so it looks to be 2.7 only.
------
components: Library (Lib)
messages: 151100
nosy: Julian
priority: normal
severity: normal
status: open
title: json.loads raises a SystemError for invalid encoding on 2.7.2
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13774>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12236] Tkinter __version__ uses subversion substitution
New submission from Julian Taylor : ./Lib/lib-tk/Tkinter.py:33 has this svn keyword substitution: __version__ = "$Revision$" Due to the change to hg this field is not substituted and makes __version__ quite pointless. This affects the python 2.7.2rc1. -- components: Tkinter messages: 137455 nosy: jtaylor priority: normal severity: normal status: open title: Tkinter __version__ uses subversion substitution type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12236> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12236] Tkinter __version__ uses subversion substitution
Julian Taylor added the comment: matplotlib fails to build due to this with 2.7.2rc1 in ubuntu oneiric (but its seems simple to fix): https://launchpad.net/ubuntu/+source/matplotlib/1.0.1-2ubuntu1/+build/2535369 -- ___ Python tracker <http://bugs.python.org/issue12236> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7946] Convoy effect with I/O bound threads and New GIL
Changes by Julian Mehnle : -- nosy: +jmehnle ___ Python tracker <http://bugs.python.org/issue7946> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7753] newgil backport
Changes by Julian Mehnle : -- nosy: +jmehnle ___ Python tracker <http://bugs.python.org/issue7753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12752] locale.normalize does not take unicode strings
New submission from Julian Taylor : using unicode strings for locale.normalize gives following traceback with python2.7: ~$ python2.7 -c 'import locale; locale.normalize(u"en_US")' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/locale.py", line 358, in normalize fullname = localename.translate(_ascii_lower_map) TypeError: character mapping must return integer, None or unicode with python2.6 it works and it also works with non-unicode strings in 2.7 -- components: Unicode messages: 142118 nosy: jtaylor priority: normal severity: normal status: open title: locale.normalize does not take unicode strings versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12752] locale.normalize does not take unicode strings
Julian Taylor added the comment: this is a regression introduced by fixing http://bugs.python.org/issue1813 This breaks some user code,. e.g. wx.Locale.GetCanonicalName returns unicode. Example bugs: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/824734 https://bugs.launchpad.net/ubuntu/+source/playonlinux/+bug/825421 -- ___ Python tracker <http://bugs.python.org/issue12752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Julian Berman added the comment: A minor documentation error in io.rst line 475 which was changed to: + The *mode* can be ``'c'``, ``'r'``, ``'w'`` or ``'a'`` for reading + (default), writing, or appending. and should have "creating" at the front I assume, like you have it later. -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue12760> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2651] Strings passed to KeyError do not round trip
Changes by Julian Berman : -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue2651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12782] Multiple context expressions do not support parentheses for continuation across lines
New submission from Julian Berman :
Using multiple `with` statements across multiple lines does not support using
parens to break them up:
with (open("a_really_long_foo") as foo,
open("a_really_long_bar") as bar):
pass
Traceback (most recent call last):
File "", line 1, in
File "demo.py", line 19
with (open("a_really_long_foo") as foo,
^
SyntaxError: invalid syntax
Also, without convoluting things, import also does not support doing so, and is
the only other example I can think of of a compound statement that forces you
to either be redundant or bite your teeth and use \, despite the fact that PEP
328 gave us parens for from imports.
(I did not find a discussion as to why import didn't grow it as well, so please
correct me as I'm sure it must have been discussed before).
It's understandably a lot rarer to need multiple lines when importing, but it'd
be nice if all compound statements uniformly allowed the same continuation
syntax.
--
components: Interpreter Core
messages: 142411
nosy: Julian
priority: normal
severity: normal
status: open
title: Multiple context expressions do not support parentheses for continuation
across lines
type: behavior
versions: Python 2.7, Python 3.3
___
Python tracker
<http://bugs.python.org/issue12782>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12782] Multiple context expressions do not support parentheses for continuation across lines
Julian Berman added the comment: > we explicitly advise against importing too many modules in a single import > statement, but importing multiple names from a single location is often a > useful thing to do. Cool. I imagined this had to do with it. > there may be a grammar ambiguity problem in this case, since (unlike > from-import) with statements allow arbitrary subexpressions. Sorry, can you possibly clarify where the ambiguity might come in? -- ___ Python tracker <http://bugs.python.org/issue12782> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12941] add random.pop()
Julian Berman added the comment: Considering this is pretty easily written more or less as r = range(20) r.pop(random.randrange(0, len(r))) is it really worth adding? -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue12941> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Julian Scheid added the comment:
Having this in 2.6/2.7 would be great.
I don't think the ELLIPSIS workaround suggested by Barry works, have you
actually tried it?
Below is an example where ELLIPSIS doesn't seem to help (run in 2.6.5). I have
also tried "...Error:" and "...:", and tried replacing ". . ." by "...", to no
avail.
I'm assuming this has to do with issue #1192554, or am I making a silly mistake?
Otherwise, are there any other workarounds you can suggest?
Without ellipsis the following example works in 2.6 but of course fails in 3.x.
Failed example:
Redacted.from_str('1-7@') #doctest: +ELLIPSIS
Expected:
Traceback (most recent call last):
. . .
...ParserError: :
1-7@
^
expected digit
Got:
Traceback (most recent call last):
ParserError: :
1-7@
^
expected digit
--
nosy: +Julian.Scheid
___
Python tracker
<http://bugs.python.org/issue7490>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Julian Scheid added the comment:
Here's a better example that you can cut and paste.
import optparse
def foo():
"""
>>> foo() #doctest: +ELLIPSIS
Traceback (most recent call last):
. . .
...OptionError: option bar: foo
"""
raise optparse.OptionError('foo', 'bar')
if __name__ == "__main__":
import doctest
doctest.testmod()
--
___
Python tracker
<http://bugs.python.org/issue7490>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Julian Scheid added the comment: Ah, right... so there is no easy workaround at present? -- ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Julian Scheid added the comment: Thank you for the suggestion but in my mind that's not a viable workaround, and not just because of uglyness: I'm using doctest to validate code examples, which are included in the documentation and are meant to be educational. If I'd change my examples to match the pattern you suggest they might still serve their purpose as a test but they'd become useless as an example. So it appears there is no real workaround for this issue. Any chance we can get the patch into 2.7? By the way, I said earlier that Barry suggested the ELLIPSIS workaround but it was actually ncoghlan who did so - apologies for the confusion. -- ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name
Julian Scheid added the comment: Hmm, wait. Here's a variation of your suggestion that works OK-ish even as an example: >>> try: ...# ... code that fails ... ... except mypkg.MyException, e: ...print(str(e)) Expected error message. This works because it omits the exception type in the output. It's still far from ideal, because as an example it's more complicated than it would need to be, but I guess it works as a stop-gap solution. Still, +1 for including the patch. -- ___ Python tracker <http://bugs.python.org/issue7490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37941] python -m and runpy.run_module set different __name__ by default
New submission from Julian Berman :
This seems brutally simple, to the point where I'm concerned I'm missing
something (or have seen this issue filed elsewhere but can't find it), but
`python -m` and `runpy.run_module` don't set the same __name__ -- specifically
`runpy.run_module`, when given a non-package, defaults to setting __name__ to
`mod_name`.
So, given package/foo.py, with the "common"
`if __name__ == "__main__":` check at the bottom, `python -m package.foo`
successfully executes, but `runpy.run_module("package.foo")` exits silently,
unless explicitly passed `runpy.run_module("package.foo", run_name="__main__").
[n.b. pep517.{build,check} is a specific example of such a module that
advertises itself as wanting to be executed via `python -m`]
issue16737 seems related but not exactly the same from what I can tell.
--
messages: 350387
nosy: Julian
priority: normal
severity: normal
status: open
title: python -m and runpy.run_module set different __name__ by default
___
Python tracker
<https://bugs.python.org/issue37941>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37941] python -m and runpy.run_module set different __name__ by default
Julian Berman added the comment: Is there no desire to have an API that works like -m (entirely. In this and any other way)? On Tue, Sep 3, 2019, 09:41 Nick Coghlan wrote: > > Change by Nick Coghlan : > > > -- > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue37941> > ___ > -- ___ Python tracker <https://bugs.python.org/issue37941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37941] python -m and runpy.run_module set different __name__ by default
Julian Berman added the comment: That all makes sense, I understand that in the general case you can't really promise someone that if you mutate global state in-process that the runpy module has any way of preventing that. Except IMO, the module gives exactly the impression you're saying is bad (that you want to use it if you need to do what -m does from Python, assuming you are OK with the constraints there). And then runpy.run_module is a footgun, because it does not in fact do what -m does, so it's hard to imagine the kind of person who *does* want to use runpy -- it's basically "try it on your specific -m, and possibly it works, and then possibly it will continue to work" (to be slightly but hopefully not overwhelmingly facetious). Quoting the docs for it themselves: See also The -m <https://docs.python.org/3/using/cmdline.html#cmdoption-m> option offering equivalent functionality from the command line. >From an external developer's perspective, if some other thing would be necessary tomorrow that would only be for -m, could one rely on it being added to any or all of the functions in the runpy module? That sounds unclear if there isn't a function that represents what -m does and promises to stay that way. It seems to me that either exposing a public API that promises to be -m as much as possible (which means at least if an end-user knows they're just as "clean" as the process that -m will run, you're probably good), or otherwise deprecating the functions in here entirely as public, and just making them all private, would be improvements to being able to understand if someone wants to use this module or not, but I do appreciate you explaining how things got here. -J On Wed, Sep 11, 2019 at 7:03 PM Nick Coghlan wrote: > > Nick Coghlan added the comment: > > There is one, it just isn't public: runpy._run_module_as_main. > > It's a private API that the -m switch implementation calls, and was > introduced after the original runpy.run_module was found not to offer > everything the switch needed. > > It isn't possible to fully emulate -m from Python code though, as the > lifecycle of the real main module is intertwined with the lifecycle of the > underlying interpreter. > > So if folks really want to try to do this, the source code is there to > look at, but we're not giving the false impression that it's easy to do > correctly with no unintended consequences. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue37941> > ___ > -- ___ Python tracker <https://bugs.python.org/issue37941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43742] tcp_echo_client in asyncio streams example does not work. Hangs for ever at reaser.read()
New submission from julian colomina : taking the example verbatim into an ubuntu 20.04 with Python 3.8.5 (default, Jan 27 2021, 15:41:15) [GCC 9.3.0] on linux will hand indefinitely at data = await reader.read(100) changing for data = await asyncio.wait_for(reader.read(100),5) will always leave on timeout. -- components: asyncio messages: 390295 nosy: asvetlov, jcolo, yselivanov priority: normal severity: normal status: open title: tcp_echo_client in asyncio streams example does not work. Hangs for ever at reaser.read() type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22282] ipaddress module accepts octal formatted IPv4 addresses in IPv6 addresses
Change by Julian Berman : -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue22282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
Change by Julian Berman : -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue36384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43742] tcp_echo_client in asyncio streams example does not work. Hangs for ever at reaser.read()
julian colomina added the comment: @jaswdr Thanks for your response. No I did not run the server that you mention. The language made me imply that the same process, in two separate coroutines, would be writing/reading from each end of the tcp connection. One writing to the tcp buffer, the second one draining it. If the intended usage is as you explain, please close the issue. My bad, sorry. JC -- ___ Python tracker <https://bugs.python.org/issue43742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44383] argparse.BooleanOptionalAction interacts poorly with ArgumentDefaultsHelpFormatter
New submission from Julian Gilbey : With code like the following: import argparse parser = argparse.ArgumentParser( description="Test program", formatter_class=argparse.ArgumentDefaultsHelpFormatter, ) parser.add_argument( "--foo", help="Use the foo component.", action=argparse.BooleanOptionalAction, default=True, ) args = parser.parse_args() a call "python prog.py --help" then gives: usage: prog.py [-h] [--foo | --no-foo] Test program optional arguments: -h, --help show this help message and exit --foo, --no-foo Use the foo component. (default: True) (default: True) Note the repeated "(default: True)", one produced by the BooleanOptionalAction class and the other by the ArgumentDefaultsHelpFormatter. It would be good if they didn't both add this helpful information. My suggestion would be that BooleanOptionalAction should not include this information; it is unique in doing so. -- components: Library (Lib) messages: 395559 nosy: juliangilbey priority: normal severity: normal status: open title: argparse.BooleanOptionalAction interacts poorly with ArgumentDefaultsHelpFormatter type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44383] argparse.BooleanOptionalAction interacts poorly with ArgumentDefaultsHelpFormatter
Julian Gilbey added the comment: Yes, this is a duplicate. Marking this report as a duplicate. It's a shame that the other one has a conflict and has been sitting waiting for an update for over a year :-( I'd be happy to help if it is of use. -- resolution: -> duplicate ___ Python tracker <https://bugs.python.org/issue44383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44383] argparse.BooleanOptionalAction interacts poorly with ArgumentDefaultsHelpFormatter
Change by Julian Gilbey : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44994] datetime's C implementation verifies fromisoformat is ASCII, but the pure python implementation does not
New submission from Julian Berman :
This line (which contains a non-ASCII digit):
python3.9 -c "import datetime; datetime.date.fromisoformat('1963-06-1৪')"
raises:
Traceback (most recent call last):
File "", line 1, in
ValueError: Invalid isoformat string: '1963-06-1৪'
under the C implementation of the datetime module, but when the pure Python
implementation is the one imported, succeeds (and produces `datetime.date(1963,
6, 14)`)
The pure Python implementation should instead explicitly check and raise when
encountering a non-ASCII string.
(On PyPy, which always uses the pure-Python implementation, this contributes to
a behavioral difference)
--
components: Library (Lib)
messages: 400235
nosy: Julian, p-ganssle
priority: normal
severity: normal
status: open
title: datetime's C implementation verifies fromisoformat is ASCII, but the
pure python implementation does not
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44994>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44995] "Hide the prompts and output" works abnormal
Change by Julian Berman : -- keywords: +patch nosy: +Julian nosy_count: 2.0 -> 3.0 pull_requests: +26384 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27939 ___ Python tracker <https://bugs.python.org/issue44995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44986] Date formats in help messages of argparse
Julian Berman added the comment: This is documented already I believe: https://docs.python.org/3/library/argparse.html#help > As the help string supports %-formatting, if you want a literal % to appear > in the help string, you must escape it as %%. -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue44986> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45081] dataclasses that inherit from Protocol subclasses have wrong __init__
New submission from Julian Fortune :
I believe [`bpo-44806: Fix __init__ in subclasses of
protocols`](https://github.com/python/cpython/pull/27545) has caused a
regression when using a Dataclass.
In Python `3.9.7`, a `dataclass` that inherits from a subclass of
`typing.Protocol` (i.e., a user-defined protocol), does not have the correct
`__init__`.
### Demonstration
```python
from dataclasses import dataclass
from typing import Protocol
class P(Protocol):
pass
@dataclass
class B(P):
value: str
print(B("test"))
```
In `3.9.7`:
```shell
Traceback (most recent call last):
File "test.py", line 11, in
print(B("test"))
TypeError: B() takes no arguments
```
In `3.9.6`:
```shell
B(value='test')
```
### Affected Projects
- [dbt](https://github.com/dbt-labs/dbt/issues/3843)
--
components: Library (Lib)
messages: 400868
nosy: julianfortune
priority: normal
severity: normal
status: open
title: dataclasses that inherit from Protocol subclasses have wrong __init__
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue45081>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45081] dataclasses that inherit from Protocol subclasses have wrong __init__
Change by Julian Fortune : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45081] dataclasses that inherit from Protocol subclasses have wrong __init__
Julian Fortune added the comment: Ian, `MyProtocol` does not provide an `__init__()`, and thus ``` super().__init__() ``` is calling the `__init__()` from `Protocol`. This results in the `TypeError`. Simply remove `super().__init__()` to resolve your issue. This behavior was changed in https://github.com/python/cpython/pull/27545 (see `Lib/typing.py:1384`); I don't see what you are reporting as a regression, I see it as correct behavior that I would expect. Apologies if you feel differently. Cheers, Julian -- ___ Python tracker <https://bugs.python.org/issue45081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43148] Call sys.unraisablehook in the REPL when sys.excepthook is broken
New submission from Julian Berman : At the REPL, when sys.excepthook is broken (below by setting it to a non-callable), one sees: ``` ⊙ python3.9 julian@Airm Python 3.9.1 (default, Feb 2 2021, 22:54:59) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.excepthook = object(); asdf Error in sys.excepthook: TypeError: 'object' object is not callable Original exception was: Traceback (most recent call last): File "", line 1, in NameError: name 'asdf' is not defined ``` The implementation (https://github.com/python/cpython/blob/5f18c223391eef8c7d01241b51a7b2429609dd84/Python/pythonrun.c#L805-L817) seems to do so by reimplementing something like 3.8+'s sys.unraisablehook (well, technically it predates sys.unraisablehook by quite a while). Seems like now that it exists, that code should now call sys.unraisablehook. -- messages: 386569 nosy: Julian, vstinner priority: normal severity: normal status: open title: Call sys.unraisablehook in the REPL when sys.excepthook is broken versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43154] code.InteractiveConsole can crash if sys.excepthook is broken
Change by Julian Berman : -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue43154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43148] Call sys.unraisablehook in the REPL when sys.excepthook is broken
Julian Berman added the comment: Thanks Victor. Yes likely happy to send a PR (have to clear a few things off the yak stack first) On Tue, Feb 9, 2021 at 5:38 AM STINNER Victor wrote: > > STINNER Victor added the comment: > > It makes sense to call _PyErr_WriteUnraisableMsg() when sys.excepthook > raise a new exception. Do you want to propose a PR for that? > > sys.excepthook documentation mentions sys.unraisablehook: > https://docs.python.org/dev/library/sys.html#sys.excepthook > > threading._make_invoke_excepthook logs threading.excepthook failure using > sys.excepthook. > > Note: Carl also suggested to add a way to invoke sys.unraisablehook > explicitly, not only for testing purpose. It would help in some cases. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue43148> > ___ > -- nosy: +Julian2 ___ Python tracker <https://bugs.python.org/issue43148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21724] resetwarnings doesn't reset warnings registry
Julian Berman added the comment: Just ran into this myself -- not sure what the intended fix is (hopefully it's "add a function that restores the warnings configuration to its defaults?" Changing resetwarnings seems likely to be not doable I assume.) But in the meanwhile, is a doc patch acceptable? The current documentation for resetwarnings is really deceptive, and makes it look like it does what @pitrou (and I) thought it did: > Reset the warnings filter. This discards the effect of all previous calls to > filterwarnings(), including that of the -W command line options and calls to > simplefilter(). Compare to the docstring of the function (and to what it actually does): > """Clear the list of warning filters, so that no filters are active.""" But there are still too many implementation details of the warnings module leaking through here -- for end users it's just "restore the warnings configuration to its defaults" (what it looks like resetwarnings should do) or "unfilter all warnings, even beyond the filters configured by default" (what it actually does). Is at least making the docs reflect the latter a reasonable patch to submit, to start, while what to do about the former is thought about? -- assignee: -> docs@python components: +Documentation nosy: +Julian, docs@python versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue21724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40379] multiprocessing's default start method of fork()-without-exec() is broken
Change by Julian Berman : -- nosy: +Julian ___ Python tracker <https://bugs.python.org/issue40379> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
New submission from Julian Berman : The following code succeeds "silently", which seems undesirable: from inspect import signature def two(): return 2 bound = signature(two).bind() bound.arguments["does_not_exist"] = 12 two(*bound.args, **bound.kwargs) where the mechanism for finally calling `two` is the recommended way shown in the docs for `inspect.BoundArguments`: https://docs.python.org/3/library/inspect.html#inspect.BoundArguments.apply_defaults What's happened there is that: print(b.args, b.kwargs) "silently" ignored the non-existent argument. Somewhere along the line here it seems like something should complain. I don't see previous discussion of this from quickly searching on the bug tracker, but obviously if I've missed something let me know. I'm also not really sure what the desirable solution is. To me, it's possibly that BoundArguments should have a fully-managed way to invoke a callable rather than asking a user to unpack *args and *kwargs, and that that mechanism, say arguments.be_passed_to(callable) should do the error checking). Having `.arguments` full-on reject unknown parameters seems like another possibility but there may be reasons that's not a good idea (e.g. if you were to for some reason use a bound arguments object to call some other function that *did* take that additional argument). -- components: Library (Lib) messages: 376578 nosy: Julian priority: normal severity: normal status: open title: BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments type: behavior versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
Change by Julian Berman : -- nosy: +yselivanov versions: -Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
Julian Berman added the comment: As a secondary behavior here, which is actually the one that matters more for my use case, the following seems surprising as well: import inspect s = inspect.signature(lambda **kwargs: kwargs).bind() s.arguments["foo"] = 12 will similarly silently drop "foo" when attempting to call the function (i.e. it will not appear in bound.kwargs). This behavior I suspect is the intention of the docs saying "Contains only explicitly bound arguments." but still seems easily misused when .arguments is being used as a frontend for adding additional arguments. To me just brainstorming again it seems it'd be useful to provide a harder-to-misuse frontend, e.g. `BoundArguments.with_arguments(*args, **kwargs)` that returns a bound arguments with some additional to-be-bound arguments which may end up in `kwargs`. -- ___ Python tracker <https://bugs.python.org/issue41745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
Julian Berman added the comment: Not sure I agree with it being just a doc issue -- happy to clarify if something was unclear, not sure from your message if it was or if you disagree, but e.g.: > However, your 'two' function takes no arguments, so valid values of args and > kwargs must be empty for them to be used in a call. In all cases, args() and > kwargs() must look at the signature to see which key-value pairs they should > extract from arguments. Right, and that's "dangerous" behavior to me -- BoundArguments.arguments will happily let you add arguments to it, but does no error checking at that point, so does not raise an exception if you typo an argument that isn't in the signature of the callable, and then when you try to call the callable (via the only way possible, namely using .args and .kwargs), that argument that was never added is just dropped. Does that make sense? Or were you disagreeing with that being undesirable behavior? -- ___ Python tracker <https://bugs.python.org/issue41745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41745] BoundArguments.arguments used in the recommended way to call a callable silently succeeds for nonexistent arguments
Julian Berman added the comment: Totally fair! Sorry, was just making sure the label change wasn't intended to say it *wasn't* enough to warrant a design change :) (which I agree should be discussed with folks who do use that functionality, of which I only recently had to). -- ___ Python tracker <https://bugs.python.org/issue41745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13826] Having a shlex example in the subprocess.Popen docs is confusing
New submission from Julian Berman : The example at http://docs.python.org/dev/library/subprocess.html#popen-constructor seems a bit misplaced, as it seems to suggest that one should use the shlex module. Most of the other examples in the module seem to use a list to provide the args, so if there was a need to just point out that shlex could be used for a corner case perhaps it'd be better suited as a footnote or another subsection somewhere. -- assignee: docs@python components: Documentation messages: 151624 nosy: Julian, docs@python priority: normal severity: normal status: open title: Having a shlex example in the subprocess.Popen docs is confusing type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13826> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13826] Having a shlex example in the subprocess.Popen docs is confusing
Julian Berman added the comment: Sounds reasonable to me. I'll take a look at adding one unless someone manages to beat me to it. -- ___ Python tracker <http://bugs.python.org/issue13826> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14086] str(KeyError("Foo")) Unexpected Result
Julian Berman added the comment: Hey there. Check out #2651 -- nosy: +Julian ___ Python tracker <http://bugs.python.org/issue14086> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30754] textwrap.dedent mishandles empty lines
Julian Berman added the comment: I still disagree :) but docs are better than nothing. On Wed, Jun 12, 2019, 18:05 Guido van Rossum wrote: > > Change by Guido van Rossum : > > > -- > nosy: +gvanrossum > > ___ > Python tracker > <https://bugs.python.org/issue30754> > ___ > -- ___ Python tracker <https://bugs.python.org/issue30754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37805] json.dump(..., skipkeys=True) has no unit tests
New submission from Julian Berman : Looks like there possibly are upstream tests that could be pulled in with modification: https://github.com/simplejson/simplejson/blob/00ed20da4c0e5f0396661f73482418651ff4d8c7/simplejson/tests/test_dump.py#L53-L66 (Found via https://bitbucket.org/pypy/pypy/issues/3052/json-skipkeys-true-results-in-invalid-json) -- components: Tests messages: 349317 nosy: Julian priority: normal severity: normal status: open title: json.dump(..., skipkeys=True) has no unit tests versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30754] textwrap.dedent mishandles empty lines
New submission from Julian Berman:
⊙ python2 -c 'from textwrap import dedent; print repr(dedent(" " * 2 + "\n" +
" " * 4 + "\n"))'
'\n\n'
instead of the presumed '\n \n'
The same appears to be the case for py3.6.
(At first glance, this seems unrelated to http://bugs.python.org/issue19479
although that issue seems to have an unreviewed patch that changes the
implementation, so it might also "accidentally" fix the issue).
--
components: Library (Lib)
messages: 296825
nosy: Julian, georg.brandl, terry.reedy
priority: normal
severity: normal
status: open
title: textwrap.dedent mishandles empty lines
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue30754>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30754] textwrap.dedent mishandles empty lines
Julian Berman added the comment: @Terry IMHO it conflicts with the fundamental description of the function. > Remove any common leading whitespace from every line in text. If this behavior is intentional, textwrap.dedent does not do that, it does that, but also some other stuff. As for whether it *should* do that, I can't really see how it'd be a good idea to do this -- whether indented blank lines are like trailing whitespace or not is a good reason not to *add* them, but if you've got some already, textwrap.dedent isn't responsible for them, they were there already. It is also extremely hard to get the other behavior given a function that does this one, but trivial to do the reverse. Also, the #1 reason to use textwrap.dedent (and also the very next line of the docstring after the one I quoted) is to line up sections of source code. With this behavior, that usecase goes away any time you need trailing whitespace, which is exactly how I found this behavior, by unittesting a function that was returning: textwrap.dedent( """ foo ' bar baz quux ' """, ) -- ___ Python tracker <http://bugs.python.org/issue30754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34160] ElementTree not preserving attribute order
Julian Sivertsen added the comment: I don't understand why this library should go out of its way to support the old behavior when it seems like the only thing it breaks is tests that assume something that was never guaranteed and where you can get the old behavior in just two lines of Python: for node in root.iter(): node.attrib = dict(sorted(node.items())) Kind regards from confused Pythoner that just wonted the attribute order to make sense -- nosy: +sivert ___ Python tracker <https://bugs.python.org/issue34160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26530] tracemalloc: add C API to manually track/untrack memory allocations
Julian Taylor added the comment: The api looks good to me. Works fine in numpy. -- nosy: +jtaylor ___ Python tracker <http://bugs.python.org/issue26530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26530] tracemalloc: add C API to manually track/untrack memory allocations
Julian Taylor added the comment: I don't see any reason why not to. -- ___ Python tracker <http://bugs.python.org/issue26530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30054] Expose tracemalloc C API to track/untrack memory blocks
Julian Taylor added the comment: I am not sure if _PyTraceMalloc_GetTraceback really needs to be a public function. Exposing the tracing information should probably just go over python interfaces. -- ___ Python tracker <http://bugs.python.org/issue30054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30054] Expose tracemalloc C API to track/untrack memory blocks
Julian Taylor added the comment: With this changeset it would: https://github.com/numpy/numpy/pull/8885 -- ___ Python tracker <http://bugs.python.org/issue30054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30073] binary compressed file reading corrupts newlines (lzma, gzip, bz2)
New submission from Julian Taylor:
Probably a case of 'don't do that' but reading lines in a compressed files in
binary mode produces bytes with invalid newlines in encodings that where '\n'
is encoded as something else:
with lzma.open("test.xz", "wt", encoding="UTF-32-LE") as f:
f.write('0 1 2\n3 4 5');
lzma.open("test.xz", "rb").readlines()[0].decode('UTF-32-LE')
Fails with:
UnicodeDecodeError: 'utf-32-le' codec can't decode byte 0x0a in position 20:
truncated data
as readlines() produces:
b'0\x00\x00\x00 \x00\x00\x001\x00\x00\x00 \x00\x00\x002\x00\x00\x00\n'
The last newline should be '\n'.encode('UTF-32-LE') == b'\n\x00\x00\x00'
--
components: Library (Lib)
messages: 291661
nosy: jtaylor
priority: normal
severity: normal
status: open
title: binary compressed file reading corrupts newlines (lzma, gzip, bz2)
___
Python tracker
<http://bugs.python.org/issue30073>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30073] binary compressed file reading corrupts newlines (lzma, gzip, bz2)
Julian Taylor added the comment: on second though not really worth an issue as it is a general problem of readline on binary streams. Sorry for the noise. -- stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue30073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30073] binary compressed file reading corrupts newlines (lzma, gzip, bz2)
Julian Taylor added the comment: see also http://bugs.python.org/issue17083 -- ___ Python tracker <http://bugs.python.org/issue30073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30150] raw debug allocators to not return malloc alignment
New submission from Julian Taylor: The debug raw allocator do not return the same alignment as malloc. See _PyMem_DebugRawAlloc: https://github.com/python/cpython/blob/master/Objects/obmalloc.c#L1873 The line return p + 2*SST adds 2 * sizeof(size_t) to the pointer returned by malloc. On for example x32 malloc returns 16 byte aligned memory but size_t is 4 bytes. This makes all memory returned by the debug allocators not aligned the what the system assumes on such platforms. -- components: Interpreter Core messages: 292187 nosy: jtaylor priority: normal severity: normal status: open title: raw debug allocators to not return malloc alignment versions: Python 2.7, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue30150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
