[issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970
Akira Li added the comment: Alexander Belopolsky added the comment: I've provide the direct quote from *C* standard ... I understand that C standard uses the word encoding, but it does so for a reason that is completely unrelated to the choice of epoch. Encoding is how the bytes in memory should be interpreted as number of seconds or some other notion of time. For, example two's complement little-endian 32-bit signed int is an example of valid time_t encoding, another example would be IEEE 754 big-endian 64-bit double. Note that these choices are valid for both C and POSIX standards. I agree one *part* of encoding is how time_t is *represented* in memory but it is not the only part e.g.: The mktime function converts the broken-down time, expressed as local time, in the structure pointed to by timeptr into a calendar time value with the same encoding as that of the values returned by the time function. notice: the same encoding as ... returned by the time function. time() function can return values with different epoch (implementation defined). mktime() is specified to use the *same* encoding i.e., the same epoch, etc. i.e., [in simple words] we have calendar time (Gregorian date, time) and we can convert it to a number (e.g., Python integer), we can call that number seconds and we can represent that number as some (unspecified) bit-pattern in C. I consider the whole process of converting time to a bit-pattern in memory as encoding i.e., 32/64, un/signed int/754 double is just *part* of it e.g., 1. specify that 1970-01-01T00:00:00Z is zero (0) 2. specify 0 has time_t type 3. specify how time_t type is represented in memory. I may be wrong that C standard includes the first item in time encoding. If you google for your phrase time in POSIX encoding, this issue is the only hit. This strongly suggests that your choice of words is not the most natural. I've googled the phrase (no surrounding quotes) and the links talk about time encoded as POSIX time [1] and some *literally* contain the phrase *POSIX encoding* [2] because *Python* documentation for calendar.timegm contains it [3]: [timegm] returns the corresponding Unix timestamp value, assuming an epoch of 1970, and the POSIX encoding. In fact, time.gmtime() and timegm() are each others’ inverse. In an effort to avoid personal influence, I've repeated the expreriment using Tor browser and other search engines -- the result is the same. timegm() documentation might be the reason why I've used the phrase. I agree POSIX encoding might be unclear. The patch could be replaced by any phrase that expresses that some functions in stdlib assume that time.time() returns (+/- fractional part) seconds since the Epoch as defined by POSIX [4]. [1] http://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number [2] http://ruslanspivak.com/2011/07/20/how-to-convert-python-utc-datetime-object-to-unix-timestamp/ [3] https://docs.python.org/3/library/calendar.html#calendar.timegm [4] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22356 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22968] types._calculate_meta nit: isinstance != PyType_IsSubtype
Greg Turner added the comment: Also: In types.prepare_class, here is what currently happens: we let x be, in order of preference: (a) the explicitly given type if, one is given, else (b) type(bases[0]), if it exists, else (c) type and then, if isinstance(x, type), we run _calculate_bases. In python 2, I think something like this really does happen, although, perhaps isinstance(x, type) should have been issubclass(x, type) to correctly capture how python 2 does it. In particular, I think we can stick a Callable in there as bases[0], and then any old crazy list of objects as base classes, and it will call our Callable, although if we don't do something about our crazy base classes, it will still break later (something like that... I don't remember exactly, except that the first base is definitely special somehow). But in python 3, if I'm reading the C code correctly, I don't think the first base class receives any special handling, and the cpython-equivalent to _calculate_bases /always/ happens, suggesting that any non-descending-from-type metaclass is expected to have removed itself from the picture before type_new is invoked. So maybe more minor re-factoring is needed to get it all straightened out. My brain is kind of fried from looking at it, I'll try again later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22968 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20192] pprint chokes on set containing frozenset
Serhiy Storchaka added the comment: For now sets and frozensets are comparable with other types in Python 2. frozenset(xrange(10)) 1 False set(xrange(10)) 1 False The only known to me uncomparable types in Python 2 are naive and aware datetime. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20192 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
Waldemar Parzonka added the comment: Thanks for taking a look into that. And yes the behaviour when invalid value is encountered is bit weird as the rest of the cookie is being silently ignored which is probably less than ideal in most cases. Just wonder if there is any easy way of making the matching more aware as browsers may allow various things as cookie values I guess. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12657] Cannot override JSON encoding of basic type subclasses
Stefan Champailler added the comment: I'm adding a scenario for this problem, a real life one, so it gives a bit more substance. I use SQLALchemy. I do queries with it which returns KeyedTuples (an SQLALchemy type). KeyedTuples inherits from tuple. KeyedTuples are, in principle, like NamedTuple. I want to transmit the result of my queries over json. Since KeyedTuple inherit from tuple, json can't serialize them. Of course one might say that that problem is outside the scope of json. But if so, it means we have to first convert KeyedTuples to dict and then pass the dict to json. That's alot of copies to do... This problem is rather big because it affects my whole API (close to a hundred of functions)... I've looked into the code and as noted above, one could replace 'isinstance(x,tuple)' with 'type(x) == tuple'. But without knowledge of how many people use the flexibility introduced by isinstance, it's dangerous. We could also change the nature of default and say that default is called before any type checking in json (so default is not a 'default' anymore). We could also duplicate the default functionnality (so a function called before any type checks and then a default called if all type checks fail). But for these two last cases, I guess the difficulty is : how do we know the pre-type 'default' was applied correctly ? Patching is not easy because, at least in my case, the C code path is taken = an easy patch (i.e. full python) would force me out of the C path which may be bad for performance (I didn't measure the difference between the 2 paths). I see this bug is old and not much commented, should we conclude that nobody cares ? That'd a good news since it'd mean a patch wouldn't hurt many people :-) -- nosy: +wiz21 versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12657 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22976] multiprocessing Queue empty() is broken on Windows
New submission from Radosław Szkodziński: multiprocessing.Queue.empty() uses pipe polling on Windows. Unfortunately, pipe semantics on windows are different from POSIX. The result is either: - Hang when one process tries to get() and another checks for empty() - Falsely returning empty() == False despite nothing being possible to get - because the other process is actually trying to read from the queue. The attached testcase demonstrates the first case, with main process hard hanging on my Python 2.7.8 (anaconda), 32-bit on Windows 7 64-bit. Whether 1 or 2 happens depends on specific program flow. Both can cause deadlocks in code that should be valid. Note that get(block=False) actually works correctly. It is possible that the problem is also present in Python 3. -- components: Library (Lib), Windows files: testmp.py messages: 231984 nosy: Radosław.Szkodziński, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: multiprocessing Queue empty() is broken on Windows versions: Python 2.7 Added file: http://bugs.python.org/file37342/testmp.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22976 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12657] Cannot override JSON encoding of basic type subclasses
Stefan Champailler added the comment: Reading bugs a bit, I see this is quite related to : http://bugs.python.org/issue14886 stF -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12657 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12987] Demo/scripts/newslist.py has non-free licensing terms
Matthias Klose added the comment: thanks for bringing this up. I don't agree that the non-availability in the windows build should be used to close the issue. Linux distros distribute the source, and are still affected? If it's already removed in Python3, why not remove it here as well? Anyway, I can repackage the sources for Debian/Ubuntu -- nosy: +ncoghlan status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22977] Unformatted “Windows Error 0x%X” exception message
New submission from Martin Panter: The following code generates a connection reset error on Wine (Windows emulator, because I don’t have actual Windows to test on). Probably only a minor issue, but the error message isn’t quite right: s = create_connection((localhost, 8181)) # Server end accepts connection and then closes it s.sendall(b3 * 300) Traceback (most recent call last): File stdin, line 1, in module ConnectionResetError: [WinError 10054] Windows Error 0x%X I’m just guessing, but looking at Python/errors.c, there are two PyUnicode_FromFormat(Windows Error 0x%X, ...) calls. The documentation for that function says only a lower-case %x is supported, so that would explain the behaviour I am seeing. -- components: Windows messages: 231987 nosy: steve.dower, tim.golden, vadmium, zach.ware priority: normal severity: normal status: open title: Unformatted “Windows Error 0x%X” exception message type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22977] Unformatted “Windows Error 0x%X” exception message
Changes by STINNER Victor victor.stin...@gmail.com: -- keywords: +easy nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16041] poplib: unlimited readline() from connection
Matthias Klose added the comment: this looks ok to me, can we apply this for 2.7.9? -- nosy: +doko ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16041 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16042] smtplib: unlimited readline() from connection
Changes by Matthias Klose d...@debian.org: -- nosy: +doko ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16042 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16043] xmlrpc: gzip_decode has unlimited read()
Matthias Klose added the comment: updated patch to use an optional parameter max_decode. -- nosy: +doko Added file: http://bugs.python.org/file37343/xmlrpc_gzip_27_parameter.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18967] Find a less conflict prone approach to Misc/NEWS
Nick Coghlan added the comment: As an interim step, should we add Ezio's newsmerge.py to Tools/scripts and instructions for enabling it to the devguide? That seems straightforward enough, and doesn't require any global workflow changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12987] Demo/scripts/newslist.py has non-free licensing terms
Nick Coghlan added the comment: Given that it's only the demo directory (and a relatively obscure demo as well these days), I'm inclined to just fix it upstream rather than making the distros patch it. There's also the fact that we distribute the source tarballs from python.org as well, and assert that those are under the PSF license, which this script doesn't adhere to. -- nosy: +bkabrda resolution: wont fix - stage: resolved - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16043] xmlrpc: gzip_decode has unlimited read()
Matthias Klose added the comment: document the new exception -- Added file: http://bugs.python.org/file37344/xmlrpc_gzip_27_parameter.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20453] json.load() error message changed in 3.4
Serhiy Storchaka added the comment: In issue19361 I suggest to change error messages even more and drop end position from Extra data error message. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20453 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22701] Write unescaped unicode characters (Japanese, Chinese, etc) in JSON module when ensure_ascii=False
Serhiy Storchaka added the comment: Looks either you have opened a file with the backslashreplace error handler or ran Python with PYTHONIOENCODING which sets the backslashreplace error handler. -- nosy: +serhiy.storchaka status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22701 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13027] python 2.6.6 interpreter core dumps on modules command from help prompt
Serhiy Storchaka added the comment: I suggest to close this issue as caused by a bug in third party extension. -- nosy: +serhiy.storchaka resolution: - third party status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13027 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7567] Messed up terminal after calling curses.initscr() twice.
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7567 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22978] Logical Negation of NotImplemented
New submission from Maytag Metalark: Performing a logical negation (`not`) on `NotImplemented` should return `NotImplemented`. Currently, it returns `False`. A common pattern for implementing __eq__ and __ne__ is to implement the comparison in __eq__, and simply delegate to it in __ne__ with a negation. However, if two values are incomparable, then __eq__ and __ne__ should both return NotImplemented. If you try to negate NotImplemented in __ne__, you will end up with a value of False, instead of NotImplemented, so you have to specifically test for this case. For instance, here is how one would write the code now: def __ne__(self, other): eq = self.__eq__(other) if eq is NotImplemented: return NotImplemented return not eq Where as the following would be simpler, and could be used if this change was made: def __ne__(self, other): return not self.__eq__(other) This is not simply sugar to reduce typing, it is safer because some coders may forget about NotImplemented and implement __ne__ as shown in the second example anyway, which is not actually correct with the current behavior. -- messages: 231996 nosy: Brian.Mearns priority: normal severity: normal status: open title: Logical Negation of NotImplemented type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22978 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9647] os.confstr() does not handle value changing length between calls
Serhiy Storchaka added the comment: I agree with Victor that two calls to confstr() should be enough. An example in confstr manpage uses two calls and I think there is no many software (if any) in the world which does more. -- keywords: +easy nosy: +serhiy.storchaka stage: - needs patch versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9647 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22979] Use of None in min and max
New submission from Maytag Metalark: `None` should never be the result of the built-in `min` and `max` functions. When `None` is supplied as one of the values to check, it should never be chosen as the result. This would make it much easier to find a minimum and/or maximum while iterating over values. For instance, the following is a common pattern: mn = None mx = None for x in iterable: if mn is None or x mn: mn = x if mx is None or x mx: mx = x Note that although the `min` and `max` functions could be applied directly to `iterable` in the above case, the above pattern is more efficient (only once through the loop) and covers the common case where additional operations are performed on each value of the iterable. If the suggested enhancement was made, the above code could be written more simply as: mn = None mx = None for x in iterable: mn = min(mn, x) mx = max(mx, x) At present, this will actually work for `max`, as None evaluates as less than every number, but it will not work for `min` (for the same reason). The suggested change would mean that None is simultaneously greater than and less than every other value, but that only matters if we assume a total ordering of all the values including None, which doesn't seem like it would be important. -- messages: 231998 nosy: Brian.Mearns priority: normal severity: normal status: open title: Use of None in min and max type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22979 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18290] json encoder does not support JSONP/JavaScript safe escaping
Tom Christie added the comment: I believe the status of this should be reassessed and that python should default to escaping '\u2028' and '\u2029'. *Strictly* speaking this isn't a bug and is per the JSON spec. *However* this *is* a bug in the JSON spec - which *should* be a strict subset of JSON. Given that both escaped and unescaped are valid, ensuring that those two characters *are* always escaped would clearly be more user-friendly behavior on our part, and *would* lead to less bugs in, say web frameworks that use the JSON module and then pass the output to template (eg populating a javscript variable with some JSON output). -- nosy: +tomchristie ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18290 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
New submission from Antoine Pitrou: Currently, C extensions are named something like _helperlib.cpython-34dm.so. This doesn't take into account the bitness of the interpreter (32- vs. 64-bit), which makes it awkward to use the same working copy with two different interpreters (you have to rebuild everything each time you switch bitnesses). Worse, under Windows it seems ABI tags aren't even used, giving generic names such as _helperlib.pyd. Why is that? -- messages: 232000 nosy: barry, brett.cannon, eric.snow, ncoghlan, pitrou, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: C extension naming doesn't take bitness into account type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
STINNER Victor added the comment: See also the PEP 3149. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: PEP 3149 says It is not currently clear that the facilities in this PEP are even useful for Windows. Well, it seems I have found a use for it :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: Ideally, we would use distutils.util.get_platform(). However, there are two cases where it relies on other modules: - the re module under CygWin - the sysconfig and _osx_support under OS X Of course, ideally we should be able to hardcode this into the compiled CPython executable... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18290] json encoder does not support JSONP/JavaScript safe escaping
Serhiy Storchaka added the comment: There is explicit note in the documentation about incompatibility with JavaScript. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18290 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Changes by Florent Xicluna florent.xicl...@gmail.com: -- nosy: +flox ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22979] Use of None in min and max
Simeon Visser added the comment: This doesn't happen in Python 3 as None can't be compared to other elements: min([1,2,3,None]) Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: NoneType() int() I can also imagine people now using min with the intended behaviour of give me the smallest element, or None if it happens to be present. -- nosy: +simeon.visser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22979 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18290] json encoder does not support JSONP/JavaScript safe escaping
Tom Christie added the comment: There is explicit note in the documentation about incompatibility with JavaScript. That may be, but we're still unnecessarily making for a poorer user experience. There's no good reason why we shouldn't just treat \u2028 and \u2029 as control characters - it's only going to making things better for developers using the json module. It is an unnecessary usability bug as it stands. Just because JSON has a bug in its spec wrt those two characters, doesn't mean we can't help our users avoid ever having to know about that or work around it in user code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18290 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22976] multiprocessing Queue empty() is broken on Windows
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22976 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22979] Use of None in min and max
Simeon Visser added the comment: So, to clarify, as the problem no longer occurs in Python 3 (as it requires the caller to provide only orderable objects) I'm not sure a meaningful change can be made here. It would require changing the behaviour of min/max in Python 2.7.x in a way that could break existing code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22979 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: As a side-note, it is interesting to note that Python currently wrongly identifies 32-bit builds under 64-bit Linux: Python 3.5.0a0 (default:64a54f0c87d7, Nov 2 2014, 17:18:13) [GCC 4.9.1] on linux Type help, copyright, credits or license for more information. import sys, os, sysconfig sys.maxsize 2147483647 os.uname() posix.uname_result(sysname='Linux', nodename='fsol', release='3.16.0-25-generic', version='#33-Ubuntu SMP Tue Nov 4 12:06:54 UTC 2014', machine='x86_64') sysconfig.get_platform() 'linux-x86_64' AFAIU, sysconfig.get_platform() (or its sibling distutils.util.get_platform()) is used for the naming of binary distributions... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22978] Logical Negation of NotImplemented
R. David Murray added the comment: This would break Python's consistency. 'not' of a value returns its boolean inverse, and the boolean value of NotImplemented is True, just like the boolean value of any object that does not have methods that set its boolean value is True. Having anything that is True return True when not is applied would be even more perverse than NANs are :) The correct implementation of your __ne__ method is to not define it. Python will then do the 'not __eq__(other)' call itself. -- nosy: +r.david.murray resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22978 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22979] Use of None in min and max
R. David Murray added the comment: Just select your initial value as something that works with the sequence you are iterating. If necessary, you can define custom 'always maximum' and 'always minimum' objects. (You could try proposing builtin objects with that feature on the python-ideas mailing list, if you want to pursue this, but since this is a specialized need and usually you don't even need custom objects, I suspect you won't get much enthusiasm. But I could be wrong, especially if you can some up with additional use cases. -- nosy: +r.david.murray resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22979 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22981] Use CFLAGS when extracting multiarch
New submission from Antoine Pitrou: This patch fixes MULTIARCH computation when using CFLAGS=-m32: diff --git a/configure b/configure --- a/configure +++ b/configure @@ -5402,7 +5402,7 @@ hp*|HP*) esac;; esac -MULTIARCH=$($CC --print-multiarch 2/dev/null) +MULTIARCH=$($CC $CFLAGS --print-multiarch 2/dev/null) diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -788,7 +788,7 @@ hp*|HP*) esac;; esac -MULTIARCH=$($CC --print-multiarch 2/dev/null) +MULTIARCH=$($CC $CFLAGS --print-multiarch 2/dev/null) AC_SUBST(MULTIARCH) -- messages: 232013 nosy: barry, doko, pitrou priority: normal severity: normal status: open title: Use CFLAGS when extracting multiarch type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22981 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18053] Add checks for Misc/NEWS in make patchcheck
Brett Cannon added the comment: If it's bugging you, Terry, feel free to delete that part of the check as it's of more use to core devs and we won't forget. -- assignee: - terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: The MULTIARCH variable can help at least under Linux: import sysconfig sysconfig.get_platform() 'linux-x86_64' sysconfig.get_config_var('MULTIARCH') 'i386-linux-gnu' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9584] Allow curly brace expansion
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9584 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22982] BOM incorrectly inserted before writing, after seeking in text file
New submission from MarkIngramUK: If you open a text file for append, but then perform any form of seeking, before attempting to write to the file, it will cause the BOM to be written before you text. See the attached file for an example. If you run the test, take a look at the output file, and you'll notice the UTF16 BOM gets written out before each number. I'm running a 2014 iMac with Yosemite. -- components: IO files: append-test.py messages: 232015 nosy: MarkIngramUK priority: normal severity: normal status: open title: BOM incorrectly inserted before writing, after seeking in text file type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file37345/append-test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc
Brett Cannon added the comment: Apparently this broke under Windows: http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8999/steps/test/logs/stdio -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
STINNER Victor added the comment: There is also platform.architecture(). I don't like its implementation, it relies on the external file program :-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell
STINNER Victor added the comment: Buildbot failures observed on koobs-freebsd9 and koobs-freebsd10 for 3.x and 3.4, respectively. It looks like test_asyncio pass on the last 5 builds of the following buildbots, and so I consider the issue as closed. http://buildbot.python.org/all/builders/AMD64 FreeBSD 9.x 3.x http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22685 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22473] The gloss on asyncio future with run_forever example is confusing
Roundup Robot added the comment: New changeset a4b58e779a16 by Victor Stinner in branch '3.4': Close #22473: asyncio doc: rephrase Future with run_forever() example https://hg.python.org/cpython/rev/a4b58e779a16 -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22473 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22473] The gloss on asyncio future with run_forever example is confusing
STINNER Victor added the comment: I rephrase the explanation of the example and I removed the useless note. Thanks for your feedback David. Don't hesitate to propose other enhancements to the documentation! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22473 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22983] Cookie parsing should be more permissive
New submission from Demian Brecht: As found in #22931, if an invalid cookie value is found while parsing, the rest of the cookie is silently ignored. The expected behavior is undefined in RFC 6265, but does state that if unexpected values are encountered that user agents MAY ignore an entire set-cookie string (not just a subsection of it). Given that, invalid cookie portions should likely be handled by either: 1. Ignore the cookie string in its entirety and log an error message, or 2. Ignore invalid cookie-pairs but still parse the rest of the string The latter would likely be the best path (Postel's law and all) -- components: Library (Lib) messages: 232020 nosy: demian.brecht priority: normal severity: normal status: open title: Cookie parsing should be more permissive type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22914] Rewrite of Python 2/3 porting HOWTO
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22931] cookies with square brackets in value
Demian Brecht added the comment: I do think it should be a little more permissive when parsing cookies. I've created #22983 to address that as to not conflate this issue, which the attached patch does address. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22931 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22475] asyncio task get_stack documentation seems to contradict itself
Roundup Robot added the comment: New changeset 4b6b03c1f4ff by Victor Stinner in branch '3.4': Closes #22475: asyncio doc, fix Task.get_stack() doc https://hg.python.org/cpython/rev/4b6b03c1f4ff -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22475 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19361] Specialize exceptions thrown by JSON parser
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19361 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22475] asyncio task get_stack documentation seems to contradict itself
STINNER Victor added the comment: I fixed the most obvious issue in the documentation. I don't know the function enough to propose a better documentation, sorry. Don't hesitate to write a patch on the documentation if you have a better explanation of how get_stack() behaves. It is correct that get_stack() only returns 1 frame if the task is suspended, whereas it returns more frames if get_stack() is called while the task is running. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22475 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20453] json.load() error message changed in 3.4
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20453 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22983] Cookie parsing should be more permissive
Antoine Pitrou added the comment: Well, remember that we recently made parsing stricter in response to a security issue... -- nosy: +orsenthil, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22982] BOM incorrectly inserted before writing, after seeking in text file
Amaury Forgeot d'Arc added the comment: issue5006 was supposed to take care of this, but it has a flaw IMO: This statement https://hg.python.org/cpython/file/0744ceb5c0ed/Lib/_pyio.py#l2003 is missing an and whence!=2. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22982 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Steve Dower added the comment: I'm very much in favor of adding this for .pyds on Windows. I assume the hard part will be getting the details for Linux (doesn't bitness have to be compiled in there? For Windows it can be determined at compile-time...), but preferring an extension with the ABI tag and falling back on one without seems easy enough. (Would/could this also work for .py files? So a 2.7/3.x or Jython/CPython/IronPython package could include tags in pure-Python code files?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc
Barry A. Warsaw added the comment: I already pushed a fix. http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.4/builds/702/steps/test/logs/stdio (although asyncio is still failing there but that should be unrelated) -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22983] Cookie parsing should be more permissive
Demian Brecht added the comment: Sure, but this is in regards to the initial matching, not the parsing. Because the pattern expects RFC conformity, in this cookie string: Cookie: a=b; c=[; d=r; f=h The only matching parts will be: Cookie: a=b; The rest will be discarded. What I'm proposing is that this should instead result in: Cookie: a=b; d=r; f=h The recent changes would stay intact. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22983] Cookie parsing should be more permissive
Demian Brecht added the comment: Sorry, bad example. Replace [ in the previous example with any actually invalid character. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22983 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: Note that there's a difference between the platform's architecture (which is what get_platform() returns) and the pointer size of the currently running Python executable. On 64-bit Linux, it's rather rare to have an application built as 32-bit executable. On 64-bit Windows, it's rather common to have 32-bit applications running. The best way to determine 32-bit vs. 64-bit is by using the struct module: # Determine bitsize used by Python (not necessarily the same as # the one used by the platform) import struct bits = struct.calcsize('P') * 8 This should be portable across all platforms and will always refer to the pointer size of the currently running Python executable. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: Note that there's a difference between the platform's architecture Yes, that's pointed out above. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14099] ZipFile.open() should not reopen the underlying file
Benjamin Peterson added the comment: Okay for 2.7.10. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: Nothing new should be necessary for pyc files under Windows: Python 3.4.2 |Continuum Analytics, Inc.| (default, Oct 22 2014, 11:51:45) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import sys sys.implementation.cache_tag 'cpython-34' The problem is with C extensions: import _imp _imp.extension_suffixes() ['.pyd'] Compare with Linux: import _imp _imp.extension_suffixes() ['.cpython-35dm.so', '.abi3.so', '.so'] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: I assume the hard part will be getting the details for Linux (doesn't bitness have to be compiled in there? For Windows it can be determined at compile- time...), but preferring an extension with the ABI tag and falling back on one without seems easy enough. Sticking to bitness should be easy (although I wonder if it would be desirable for platforms with fat binaries - Ned?). If we can go the extra mile and include platform identification all the better, of course. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14099] ZipFile.open() should not reopen the underlying file
David Wilson added the comment: Could we also make a small tweak to zipfile.rst indicating the new behaviour? I had made an initial attempt in my patch but wasn't particularly happy with the wording. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Steve Dower added the comment: I was more interested in source file resolution than bytecode caching. If Python 3.5 would prefer spam.cpython-35.py or spam.cpython-3.py over spam.py and Python 2 preferred spam.py, then I can more easily separate the code that won't parse in the alternative. Happy to be told it's unrelated and I should raise it separately, but from my POV resolving .pyd filenames looks very similar to resolving .py files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 02.12.2014 19:02, Antoine Pitrou wrote: Sticking to bitness should be easy (although I wonder if it would be desirable for platforms with fat binaries - Ned?). If we can go the extra mile and include platform identification all the better, of course. I hear the can of worms alarm ringing :-) Seriously, I think that putting platform infos into the file name is bound to cause more trouble than it tries to solve. Fat builds leave the decision to the linker, which is a good method and avoids the file name clashes. I think we should only focus on platforms where fat builds are uncommon, while at the same time you do have to support multiple architectures, like e.g. Windows: http://en.wikipedia.org/wiki/Fat_binary Note that on Linux, 32-bit and 64-bit versions are typically placed into different directory trees: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard so I'm not sure whether it's a real problem on Linux. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: Fat binaries seem to exist under: - OS X: yes, that's why I was asking for Ned's advice - Linux: A proof-of-concept Ubuntu 9.04 image is available... enough said - DOS: perhaps MicroPython is interested :-) http://en.wikipedia.org/wiki/Fat_binary -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Steve Dower added the comment: But since you pointed out cache-tag, should that distinguish for bitness as well? It seems to be 'cpython-34' for both 32-bit and 64-bit interpreters on Windows, which isn't really a problem now, but may become one if we start allowing/encouraging sharing packages between interpreters. In fact, it probably is an issue now with user site-packages, since that path is the same for both 32-bit and 64-bit... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 02.12.2014 19:40, Steve Dower wrote: I was more interested in source file resolution than bytecode caching. If Python 3.5 would prefer spam.cpython-35.py or spam.cpython-3.py over spam.py and Python 2 preferred spam.py, then I can more easily separate the code that won't parse in the alternative. Happy to be told it's unrelated and I should raise it separately, but from my POV resolving .pyd filenames looks very similar to resolving .py files. That's an interesting idea, but indeed unrelated to this ticket :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: Note that on Linux, 32-bit and 64-bit versions are typically placed into different directory trees By whom? Our standard installer doesn't (it uses ../lib/python-X.Y for all builds). Also, one of the problems (and actually the problem which triggered this tracker entry) is when doing development inside a working copy (either through setup.py develop or setup.py build_ext --inplace - both copy C extensions directly into the source tree). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: @Steve: IIRC, pyc files should be portable, so there's no need to differentiate between various bitnesses. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Steve Dower added the comment: @Antoine: You're right. I hereby withdraw all contributions to this thread after my first statement of support :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 02.12.2014 19:46, Antoine Pitrou wrote: Note that on Linux, 32-bit and 64-bit versions are typically placed into different directory trees By whom? Our standard installer doesn't (it uses ../lib/python-X.Y for all builds). By the system vendors. Packages (with extensions) will automatically pick up their configuration. Also, one of the problems (and actually the problem which triggered this tracker entry) is when doing development inside a working copy (either through setup.py develop or setup.py build_ext --inplace - both copy C extensions directly into the source tree). Fair enough; it's a rare use case, but may be worth supporting. My main point was that we shouldn't start adding tags for e.g. PPC, Intel, ARM, etc. since platforms needing to support multiple such architectures will typically support fat builds anyway. How about using these flags: b0 - 16-bit b1 - 32-bit b2 - 64-bit b3 - 128-bit and so on -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Antoine Pitrou added the comment: Le 02/12/2014 19:59, Marc-Andre Lemburg a écrit : My main point was that we shouldn't start adding tags for e.g. PPC, Intel, ARM, etc. since platforms needing to support multiple such architectures will typically support fat builds anyway. How about using these flags: b0 - 16-bit b1 - 32-bit b2 - 64-bit b3 - 128-bit Fair enough, although I think we only need 32-bit and 64-bit for now, and 32b vs. 64b would probably be more readable :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22977] Unformatted “Windows Error 0x%X” exception message
eryksun added the comment: This also affects SEH-related exceptions raised by ctypes. For example, VC++ uses exception code 0xE06D7363 (i.e. b'\xe0msc'), so unhandled VC++ exceptions leak into Python like this: ctypes.windll.kernel32.RaiseException(0xe06d7363, 0, 0, None) Traceback (most recent call last): File stdin, line 1, in module OSError: [WinError -529697949] Windows Error 0x%X The ctypes SEH handler defaults to calling PyErr_SetFromWindowsErr(code). Since this isn't actually a Windows error code, Win32 FormatMessageW fails. Then Python uses the following default: PyUnicode_FromFormat(Windows Error 0x%X, err). Normally (i.e. not under Wine) the OP's error number formats correctly: ctypes.windll.kernel32.RaiseException(10054, 0, 0, None) Traceback (most recent call last): File stdin, line 1, in module ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host PyErr_SetExcFromWindowsErrWithFilenameObjects https://hg.python.org/cpython/file/ab2c023a9432/Python/errors.c#l553 PyErr_SetFromErrnoWithFilenameObjects https://hg.python.org/cpython/file/ab2c023a9432/Python/errors.c#l416 -- nosy: +eryksun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 02.12.2014 20:10, Antoine Pitrou wrote: Antoine Pitrou added the comment: Le 02/12/2014 19:59, Marc-Andre Lemburg a écrit : My main point was that we shouldn't start adding tags for e.g. PPC, Intel, ARM, etc. since platforms needing to support multiple such architectures will typically support fat builds anyway. How about using these flags: b0 - 16-bit b1 - 32-bit b2 - 64-bit b3 - 128-bit Fair enough, although I think we only need 32-bit and 64-bit for now, and 32b vs. 64b would probably be more readable :-) True, I'm just not sure what the parsing requirements are and the ABI version names are too long already, IMO. PEP 425 used a nice short variant for the Python part. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14099] ZipFile.open() should not reopen the underlying file
Serhiy Storchaka added the comment: How about just Objects returned by :meth:`.open` can operate independently of the ZipFile.? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22984] test_json.test_endless_recursion(): Fatal Python error: Cannot recover from stack overflow. on x86 XP-4 3.x buildbot
New submission from STINNER Victor: http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/11271/steps/test/logs/stdio [116/390] test_json Fatal Python error: Cannot recover from stack overflow. Current thread 0x0e84 (most recent call first): File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\json\encoder.py, line 250 in iterencode File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\json\encoder.py, line 192 in encode File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_json\test_recursion.py, line 96 in test_endless_recursion File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py, line 577 in run File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py, line 625 in __call__ File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py, line 125 in run File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py, line 87 in __call__ File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py, line 125 in run File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py, line 87 in __call__ File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py, line 125 in run File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py, line 87 in __call__ File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py, line 125 in run File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py, line 87 in __call__ File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py, line 125 in run File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py, line 87 in __call__ File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\runner.py, line 168 in run File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support\__init__.py, line 1769 in _run_suite File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support\__init__.py, line 1803 in run_unittest File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py, line 1279 in test_runner File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py, line 1280 in runtest_inner File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py, line 967 in runtest File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py, line 763 in main File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py, line 1564 in main_in_temp_cwd File d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py, line 1589 in module -- components: Tests keywords: buildbot messages: 232049 nosy: haypo priority: normal severity: normal status: open title: test_json.test_endless_recursion(): Fatal Python error: Cannot recover from stack overflow. on x86 XP-4 3.x buildbot type: crash versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22971] test_pickle: Fatal Python error: Cannot recover from stack overflow. on FreeBSD buildbot
Changes by STINNER Victor victor.stin...@gmail.com: -- components: +Windows nosy: +steve.dower, tim.golden, zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22971 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22977] Unformatted “Windows Error 0x%X” exception message on Wine
Changes by STINNER Victor victor.stin...@gmail.com: -- title: Unformatted “Windows Error 0x%X” exception message - Unformatted “Windows Error 0x%X” exception message on Wine ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
Roundup Robot added the comment: New changeset fd80195b920f by Serhiy Storchaka in branch 'default': Issue #17401: Output the closefd attribute as boolean. https://hg.python.org/cpython/rev/fd80195b920f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
Serhiy Storchaka added the comment: Committed the first patch (showing closefd always) with additional test from second path. -- versions: -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
STINNER Victor added the comment: Would it be possible to add something to the sys module, computed during the compilation, instead of having to rely on platform, sysconfig, struct or something else? Note: There is also the funnny x32 platform project :-) https://sites.google.com/site/x32abi/ 32-bit pointer on 64-bit CPU. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22984] test_json.test_endless_recursion(): Fatal Python error: Cannot recover from stack overflow. on x86 XP-4 3.x buildbot
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12987] Demo/scripts/newslist.py has non-free licensing terms
Terry J. Reedy added the comment: If we are going to backport the removal from the distribution of Demo/scripts/newslist.py to 2.7, it might as well be done immediately, before 2.7.9 goes out. Benjamin? I am more concerned about separately licensed stdlib modules, such as turtle* (and others). Do they all properly 'fall under the PSF license'? Has this been systematically checked (and recorded)? Is there a policy in place with respect to new modules? * G.Lingl said in email he would sign he contributor agreement in August, but none is recorded yet. -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22984] test_json.test_endless_recursion(): Fatal Python error: Cannot recover from stack overflow. on x86 XP-4 3.x buildbot
Serhiy Storchaka added the comment: JSON encoder uses recursion calls guards but they don't save from an overflow of C stack. How to reproduce: import json sys.setrecursionlimit(10) json.dumps(5j, check_circular=False, default=lambda o: [o]) -- components: +Extension Modules ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - fixed stage: commit review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17401 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14099] ZipFile.open() should not reopen the underlying file
David Wilson added the comment: Sounds great :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14099 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22976] multiprocessing Queue empty() is broken on Windows
eryksun added the comment: This also hangs for me in 2.7.8 64-bit, Windows 7. To poll the pipe, the parent process calls PeekNamedPipe, which blocks because the child has already called ReadFile. It is possible that the problem is also present in Python 3. multiprocessing switched to overlapped I/O in 3.3, which avoids this problem. -- nosy: +eryksun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22976 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18967] Find a less conflict prone approach to Misc/NEWS
Terry J. Reedy added the comment: Thanks for the reminder/suggestion. Re-reading Ezio's two patches (newsmerge.py and .hg/hgrc additions in msg217079), they appear to jointly automate what I now do by hand (revert to local and dump merge artifacts, replace with edited file with new entries pasted in, and mark as resolved) . I also checked that the current Windows installers make .py files executable, so hg should be able to run newsmerge on Windows. I have downloaded the file and made the additions to my 3.5 hgrc to test next time I have a news entry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18967 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13027] python 2.6.6 interpreter core dumps on modules command from help prompt
Terry J. Reedy added the comment: I would close this anyway, but 2.6 is no longer maintained even for security patches. -- stage: - resolved status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13027 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22985] Segfault on time.sleep
New submission from Omer Katz: I have found what appears to be a segfualt in time.sleep but I'm not sure. I have verified that the segfualt occurs both on Python 2.7.8 and 3.4.2. The following program that reproduces the segfault uses my fork of billiard, a replacement for the multiprocessing module that is used by celery. In order to install: pip install git+https://github.com/thedrow/billiard@topic/dill-with-threads The program: from billiard.pool import ThreadPool p1 = ThreadPool() class Foo(object): def a(self): print(a) return 1 def do(self): return p1.apply_async(self.a) foo = Foo() r = foo.do() print(r.get()) p1.close() p1.join() The output from gdb: gdb -ex r -q --args python mt_example.py Reading symbols from python...done. Starting program: /home/omer/.virtualenvs/billiard/bin/python mt_example.py [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x731db700 (LWP 2897)] [New Thread 0x729da700 (LWP 2898)] [New Thread 0x721d9700 (LWP 2899)] [New Thread 0x719d8700 (LWP 2900)] [New Thread 0x711d7700 (LWP 2901)] [New Thread 0x709d6700 (LWP 2902)] [New Thread 0x7fffdbfff700 (LWP 2903)] Program received signal SIGTERM, Terminated. [Switching to Thread 0x721d9700 (LWP 2899)] 0x771dc1c3 in select () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x771dc1c3 in select () at ../sysdeps/unix/syscall-template.S:81 #1 0x75fd5d5d in floatsleep (secs=optimized out) at Modules/timemodule.c:948 #2 time_sleep (self=optimized out, args=optimized out) at Modules/timemodule.c:206 #3 0x004b658c in call_function (oparg=optimized out, pp_stack=0x721d8540) at Python/ceval.c:4033 #4 PyEval_EvalFrameEx (f=f@entry=0x7463eda8, throwflag=throwflag@entry=0) at Python/ceval.c:2679 #5 0x004b6f6b in PyEval_EvalCodeEx (co=optimized out, globals=optimized out, locals=locals@entry=0x0, args=optimized out, argcount=argcount@entry=4, kws=optimized out, kwcount=0, defs=0x740bab68, defcount=1, closure=0x0) at Python/ceval.c:3265 #6 0x004b5b28 in fast_function (nk=optimized out, na=4, n=optimized out, pp_stack=0x721d8730, func=0x731e2938) at Python/ceval.c:4129 #7 call_function (oparg=optimized out, pp_stack=0x721d8730) at Python/ceval.c:4054 #8 PyEval_EvalFrameEx (f=f@entry=0x7fffe8000b50, throwflag=throwflag@entry=0) at Python/ceval.c:2679 #9 0x004b6f6b in PyEval_EvalCodeEx (co=optimized out, globals=optimized out, locals=locals@entry=0x0, args=optimized out, argcount=argcount@entry=1, kws=optimized out, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265 #10 0x004b5b28 in fast_function (nk=optimized out, na=1, n=optimized out, pp_stack=0x721d8920, func=0x731e28c0) at Python/ceval.c:4129 #11 call_function (oparg=optimized out, pp_stack=0x721d8920) at Python/ceval.c:4054 #12 PyEval_EvalFrameEx (f=f@entry=0x7fffe8000910, throwflag=throwflag@entry=0) at Python/ceval.c:2679 #13 0x004b5bc7 in fast_function (nk=optimized out, na=1, n=optimized out, pp_stack=0x721d8a70, func=0x77e55230) ---Type return to continue, or q return to quit--- at Python/ceval.c:4119 #14 call_function (oparg=optimized out, pp_stack=0x721d8a70) at Python/ceval.c:4054 #15 PyEval_EvalFrameEx (f=f@entry=0x731f1210, throwflag=throwflag@entry=0) at Python/ceval.c:2679 #16 0x004b6f6b in PyEval_EvalCodeEx (co=optimized out, globals=optimized out, locals=locals@entry=0x0, args=args@entry=0x731dca68, argcount=optimized out, kws=kws@entry=0x0, kwcount=kwcount@entry=0, defs=defs@entry=0x0, defcount=defcount@entry=0, closure=0x0) at Python/ceval.c:3265 #17 0x00529e70 in function_call (func=0x77e55140, arg=0x731dca50, kw=0x0) at Objects/funcobject.c:526 #18 0x00422f5a in PyObject_Call (func=func@entry=0x77e55140, arg=arg@entry=0x731dca50, kw=kw@entry=0x0) at Objects/abstract.c:2529 #19 0x0042747d in instancemethod_call (func=0x77e55140, arg=0x731dca50, kw=0x0) at Objects/classobject.c:2602 #20 0x00422f5a in PyObject_Call (func=func@entry=0x74636d70, arg=arg@entry=0x77f93050, kw=optimized out) at Objects/abstract.c:2529 #21 0x004b07f7 in PyEval_CallObjectWithKeywords (func=0x74636d70, arg=0x77f93050, kw=optimized out) at Python/ceval.c:3902 #22 0x004fae92 in t_bootstrap (boot_raw=0x8899c0) at ./Modules/threadmodule.c:614 #23 0x77bc40a5 in start_thread (arg=0x721d9700) at pthread_create.c:309 #24 0x771e484d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 -- components: Interpreter Core messages: 232059 nosy: Omer.Katz priority: normal severity: normal status: open title: Segfault on time.sleep type:
[issue18053] Add checks for Misc/NEWS in make patchcheck
Terry J. Reedy added the comment: As of now the patchcheck utility adds a notice to modify Misc/NEWS for every patch. Patchcheck truthfully reports whether /docs, ACKS, and NEWS have been modified. I do not read it as saying anything about whether they *should* be updated. For Docs and NEWS, *should* is a judgement call for core devs, which would be very hard to automate. The only remotely simple check would be whether a NEWS item contains a name not in ACKS, and even that is only a suggestion. So lets leave it alone. -- resolution: - rejected stage: needs patch - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22986] Improved handling of __class__ assignment
New submission from Nathaniel Smith: Following on from the discussion starting here: http://thread.gmane.org/gmane.comp.python.devel/150438/focus=150604 Here's a patch to improve __class__ assignment. 1) We remove the HEAPTYPE check from object_set_class, and move it to same_slots_added. This fixes an outright bug: previously it was possible for non-HEAPTYPE types to get passed into same_slots_added (either b/c the loop in compatible_for_assignment ended up with non-HEAPTYPE types, or via __bases__ assignment), and it would then wander off following pointers through random memory. 2) Now that object_set_class can potentially accept non-HEAPTYPE types, adjust the reference counting appropriately. 3) To clarify the logic of compatible_for_assignment, rename equiv_structs to compatible_with_tp_base, tweak accordingly, and add a nice comment explaining the logic. (compatible_for_assignment is equiv_structs's only caller so this is totally safe.) 4) Now that equiv_structs/compatible_with_tp_base has a clearer purpose, also move the tp_dealloc check from compatible_for_assignment into compatible_with_tp_base. In the process, add special-case handling for subclass_dealloc, b/c subclass_dealloc delegates to the parent class tp_dealloc anyway. These changes together make it possible to assign to module instances's __class__ slot, which is useful for reasons described in the above thread. So I added a test for this to check the new code. -- components: Interpreter Core files: better-__class__-assignment-v1.patch keywords: patch messages: 232061 nosy: njs priority: normal severity: normal status: open title: Improved handling of __class__ assignment Added file: http://bugs.python.org/file37346/better-__class__-assignment-v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22986 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com