[issue18261] Confusing description in Minimal DOM implementation
Ned Deily added the comment: No, the intent really is to suggest using the ElementTree module rather than either minidom or any of the other XML modules in the standard library. Many people find the ElementTree API easier to understand and to use. -- nosy: +ned.deily resolution: - rejected stage: - committed/rejected status: open - closed type: resource usage - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18261 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18262] ZipInfo.external_attr are not documented
New submission from anatoly techtonik: zipfile doesn't restore file attributes when extracting. Documentation should at least contain example how to do this manually, because the ony way to do this - through ZipInfo.external_attr is too cryptic. -- assignee: docs@python components: Documentation messages: 191447 nosy: docs@python, techtonik priority: normal severity: normal status: open title: ZipInfo.external_attr are not documented versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18262 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: (ping) It would be nice to have the feature on 3.4. What changes should I do to the patch? Is anyone else working on that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17961] Use enum names as values in enum.Enum() functional API
Ethan Furman added the comment: Enum members have two pieces of easily accessible information: `name` and `value`. The name is taken from the attribute the value is assigned to; the value, obviously, is the value assigned. The question, then, is what should happen when the function syntax is used, and values are not explicitly given? - use `int`s starting from one - use `int`s starting from zero - use the key name itself - use no value at all Working from the bottom up: - no value: if the enum member has no actual value, the user cannot retrieve the member using the class call syntax (e.g. Color(???) ) - the key name as value: if we go this route, then instead of two pieces of info, our enum member has only one piece in two places - `int`s from zero: falls in line with normal Python counting, but is the zeroth member False? - `int`s from one: avoids the False question, and it's what flufl.enum does. No value is obviously a no-go as it causes more problems than it solves. `str` value is also a no-go as the key name is already available as `name`. `int`s starting from zero or starting from one? Personally, I have no problem with a zero-value enum member that is True -- not every zero should be False. This is the only change I would be willing to make. To sum up: the name is already available in the name, no need to have it be the value as well. I am open to changing the start value to zero instead of one (which is what I do in my customization of Enum in my personal modules ;) . -- assignee: - ethan.furman nosy: +eli.bendersky title: Use enum names as values in enum.Enum convenience API - Use enum names as values in enum.Enum() functional API ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18042] Provide enum.unique class decorator
Ethan Furman added the comment: I haven't seen any discouraging words regarding the decorator. If no one has any compelling reasons why it shouldn't be added, I'll craft a version and put it in (only real difference with Nick's would be catching all the duplicates at once instead of one at a time). -- assignee: - ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18262] ZipInfo.external_attr are not documented
anatoly techtonik added the comment: Here is the doc - http://stackoverflow.com/questions/434641/how-do-i-set-permissions-attributes-on-a-file-in-a-zip-file-using-pythons-zip/6297838#6297838 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18262 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18202] Minor fixes for test_coding
Roundup Robot added the comment: New changeset 410ea970866e by Serhiy Storchaka in branch '3.3': Issue #18202: Fix minor bugs and cleanup test_coding.py. http://hg.python.org/cpython/rev/410ea970866e New changeset 959f4ce4d590 by Serhiy Storchaka in branch 'default': Issue #18202: Fix minor bugs and cleanup test_source_encoding.py. http://hg.python.org/cpython/rev/959f4ce4d590 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18202] Minor fixes for test_coding
Serhiy Storchaka added the comment: Not all other changes are cleanups and enhancements. Some of them also fix minor bugs. Thank you for review Victor. -- assignee: - serhiy.storchaka resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18202 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1159] os.getenv() not updated after external module uses C putenv()
Amaury Forgeot d'Arc added the comment: FYI, PyPy recently got bitten by this: https://bugs.pypy.org/issue1518 A posix.libc_getenv() function could be a solution. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18244] singledispatch: When virtual-inheriting ABCs at distinct points in MRO, composed MRO is dependent on haystack ordering
Edward Catmur added the comment: Łukasz, thanks. When the most-derived class virtual-inherits two related ABCs U, V: object / | \ A W V | .` .` B` U` | .` C` The secondary `for` loop is necessary to ensure U and V are ordered correctly. I'll upload a patch with an improved test that covers this case. -- Added file: http://bugs.python.org/file30646/singledispatch-mro-composition.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18262] ZipInfo.external_attr are not documented
Ronald Oussoren added the comment: I'd be +1 on extending the zipfile API in 3.4 (with a documentation update in older releases as suggested by anatoly): * Add a method or property to ZipInfo for (un)packing the external_attr field * Add an keyword argument to Zipfile.extract and Zipfile.extractall that toggles restoring file permissions. This should be off by default for backward compatibility. The code that restores the file permissions should be careful to avoid security problems, IMHO it should by default ignore the SUID en SGID bits. -- components: +Library (Lib) nosy: +ronaldoussoren stage: - needs patch type: - enhancement versions: -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18262 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18262] ZipInfo.external_attr are not documented
Ronald Oussoren added the comment: See also #15795 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18262 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18262] ZipInfo.external_attr are not documented
Ronald Oussoren added the comment: Closing this as a duplicate of #15795 (which already has a patch) -- resolution: - duplicate superseder: - Zipfile.extractall does not preserve file permissions ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18262 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15795] Zipfile.extractall does not preserve file permissions
Ronald Oussoren added the comment: On first glance the patch looks good. I haven't tested it with the current trunk though. -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17894] Edits to descriptor howto
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17894 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17961] Use enum names as values in enum.Enum() functional API
Nick Coghlan added the comment: OK, I've satisfied myself that the current behaviour is reasonable, and it's specifically the subclassing behaviour of the status quo that works for me. 1. You have to specifically access the x.value attribute of a default enum member to see it. str(x) shows the fully qualified name, not the value (even for concrete subclasses). 2. The implicitly chosen values are valid for any concrete enum subclass that accepts a single integer as an argument. This covers strings and the whole numeric tower. The same can't be said for using the enum name. 3. The implicitly chosen values are always true, even when used with a concrete numeric enum subclass. This matches the behaviour of standard user defined classes (where all instances are considered true by default unless you define __len__ or __bool__ to say otherwise). The fact str(x) returns the fully qualified name for IntEnum worries me a bit, but if there's a real backwards compatibility problem there (rather than a theoretical one), hopefully we'll see it once we start converting socket and errno. -- resolution: - rejected stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13483] Use VirtualAlloc to allocate memory arenas
STINNER Victor added the comment: Ah ok. I guess tuples.py then indeed demonstrates a saving. I'll apply the patch. According to my test, the memory usage is a little bit better with the patch. So Martin:,do you plan to commit the patch? Or is a benchmark required? Or should check first check the Low Fragmentation Allocator? I plan to test the Low Fragmentation Allocator, at least on Windows 7. But I prefer to do it later, I'm working on the PEP 445 right now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16742] PyOS_Readline drops GIL and calls PyOS_StdioReadline, which isn't thread safe
Changes by STINNER Victor victor.stin...@gmail.com: -- dependencies: +API for setting the memory allocator used by Python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18259] Declare sethostname in socketmodule.c for AIX
Changes by Berker Peksag berker.pek...@gmail.com: -- versions: -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18259 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17961] Use enum names as values in enum.Enum() functional API
Eli Bendersky added the comment: Nicely done summary, Ethan. I think it would be worthwhile to add the reasoning of why from 1 and not from 0 into the documentation and maybe the PEP too. I think the falsiness answer is reasonable, and since it's a common FAQ it's good to state it explicitly. But make sure to specify that it only applies to IntEnum because Enum values are always truthy :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18263] python.man: no documentation for -b, -X
New submission from Jakub Wilk: The -b and -X options are not documented in Misc/python.man. -- assignee: docs@python components: Documentation messages: 191463 nosy: docs@python, jwilk priority: normal severity: normal status: open title: python.man: no documentation for -b, -X ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18263 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17961] Use enum names as values in enum.Enum() functional API
Eli Bendersky added the comment: The fact str(x) returns the fully qualified name for IntEnum worries me a bit, but if there's a real backwards compatibility problem there (rather than a theoretical one), hopefully we'll see it once we start converting socket and errno. What is the theoretical problem here? I though that it's an explicit design goal of enums? Which RED - Color.RED, or MeatReadiness.RED? For sockets: class SocketType(IntEnum): ... SOCK_STREAM = 1 ... SOCK_DGRAM = 2 ... str(SocketType.SOCK_STREAM) 'SocketType.SOCK_STREAM' Looks pretty good to me in terms of debuggability. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17121] SSH upload for distutils
Changes by Jakub Wilk jw...@jwilk.net: -- nosy: +jwilk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17961] Use enum names as values in enum.Enum() functional API
Barry A. Warsaw added the comment: On Jun 19, 2013, at 01:00 PM, Eli Bendersky wrote: What is the theoretical problem here? I though that it's an explicit design goal of enums? Which RED - Color.RED, or MeatReadiness.RED? For sockets: class SocketType(IntEnum): ... SOCK_STREAM = 1 ... SOCK_DGRAM = 2 ... str(SocketType.SOCK_STREAM) 'SocketType.SOCK_STREAM' Looks pretty good to me in terms of debuggability. Me too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17961] Use enum names as values in enum.Enum() functional API
Barry A. Warsaw added the comment: On Jun 19, 2013, at 06:45 AM, Ethan Furman wrote: To sum up: the name is already available in the name, no need to have it be the value as well. I am open to changing the start value to zero instead of one (which is what I do in my customization of Enum in my personal modules ;) I'm sure it's obvious that I prefer start-from-one, and aside from the truthiness question, it would maximize compatibility with flufl.enum. Besides, the functional API accepts a sequence so if you *really* wanted start-from-zero, then you can do it easily. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
New submission from Nick Coghlan: Replacing an integer constant with the current incarnation of enum.IntEnum breaks JSON serialisation: from enum import Enum from enum import Enum, IntEnum class Example(IntEnum): ... x = 1 ... import json json.dumps(1) '1' json.loads(json.dumps(1)) 1 json.dumps(Example.x) 'Example.x' json.loads(json.dumps(Example.x)) Traceback (most recent call last): File stdin, line 1, in module File /home/ncoghlan/devel/py3k/Lib/json/__init__.py, line 316, in loads return _default_decoder.decode(s) File /home/ncoghlan/devel/py3k/Lib/json/decoder.py, line 344, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File /home/ncoghlan/devel/py3k/Lib/json/decoder.py, line 362, in raw_decode raise ValueError(errmsg(Expecting value, s, err.value)) from None ValueError: Expecting value: line 1 column 1 (char 0) It breaks for floats as well, but in a slightly different way: class FloatExample(float, Enum): ... x = 1.0 ... json.dumps(FloatExample.x) 'FloatExample.x: 1.0' Allowing __str__ to be inherited from Enum rather than from the concrete type will similarly break any serialisation protocol that relies on str() to handle integers. The float case is even trickier, since failing to inherit __repr__ would rather miss the point of the whole exercise... We're going to have to be *very* careful with swapping out existing constants with enums, and we should be warning about the pitfalls in the docs too (where we can't change enum to avoid them). -- components: Library (Lib) messages: 191467 nosy: ncoghlan priority: normal severity: normal status: open title: enum.IntEnum is not compatible with JSON serialisation versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17961] Use enum names as values in enum.Enum() functional API
Nick Coghlan added the comment: I created issue 18264 after I tried it and found my theoretical concern wasn't theoretical at all: swapping a true integer for the current incarnation of enum.IntEnum breaks (at least) JSON serialisation, which means we can't use it in its current form to replace stdlib constants. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17961] Use enum names as values in enum.Enum() functional API
Barry A. Warsaw added the comment:
On Jun 19, 2013, at 01:48 PM, Nick Coghlan wrote:
I created issue 18264 after I tried it and found my theoretical concern
wasn't theoretical at all: swapping a true integer for the current
incarnation of enum.IntEnum breaks (at least) JSON serialisation, which means
we can't use it in its current form to replace stdlib constants.
JSON has to be taught how to serialize enums. Of course, it also has to be
taught how to serialize datetimes, timedeltas, and other common data types.
In Mailman, I use the following subclass of json.JSONEncoder. Note though
that in my REST API, I always know the class/enum that a string should be
associated with so my deserializer always does the right thing.
class ExtendedEncoder(json.JSONEncoder):
An extended JSON encoder which knows about other data types.
def default(self, obj):
if isinstance(obj, datetime):
return obj.isoformat()
elif isinstance(obj, timedelta):
# as_timedelta() does not recognize microseconds, so convert these
# to floating seconds, but only if there are any seconds.
if obj.seconds 0 or obj.microseconds 0:
seconds = obj.seconds + obj.microseconds / 100.0
return '{0}d{1}s'.format(obj.days, seconds)
return '{0}d'.format(obj.days)
elif isinstance(obj, Enum):
# It's up to the decoding validator to associate this name with
# the right Enum class.
return obj.name
return json.JSONEncoder.default(self, obj)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17961
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Barry A. Warsaw added the comment: On Jun 19, 2013, at 01:45 PM, Nick Coghlan wrote: Allowing __str__ to be inherited from Enum rather than from the concrete type will similarly break any serialisation protocol that relies on str() to handle integers. The float case is even trickier, since failing to inherit __repr__ would rather miss the point of the whole exercise... Serialization isn't the only issue - you have to know how to deserialize as well. I use JSON extensively in Mailman's REST API. For enums I always encode them to just the member name, because I always know what enum class will be used to deserialize them. (TBH, I wish the json module had better hooks for extending both serialization and deserialization of non-basic types.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Eric Snow added the comment: It's for times like this that I wonder if a simple serialization protocol might be worth it--something separate from __str__() but much simpler than the pickle protocol. __str__() could be the fallback. In the end, though, I always conclude that it's not worth adding yet another optional protocol to objects. Still, it would help in this case (at least for anything that knows to make use of the simple serialization protocol). Alternately, would it make sense to add special handling of enums to the json module? Do we already with pickle? -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17961] Use enum names as values in enum.Enum() functional API
Antoine Pitrou added the comment: JSON has to be taught how to serialize enums. Of course, it also has to be taught how to serialize datetimes, timedeltas, and other common data types. How so? The point of IntEnum was that it derived from int, and therefore would avoid any need for special-casing in C code. (now if json has a PyLong_CheckExact() check, perhaps it can be relaxed to PyLong_Check()...) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17961 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Amaury Forgeot d'Arc added the comment: in encoder.py: ... elif instance(value, int): yield buf + str(value) ... What if we use int(str(value)) instead? -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Eric Snow added the comment: Serialization isn't the only issue - you have to know how to deserialize as well. +1 (TBH, I wish the json module had better hooks for extending both serialization and deserialization of non-basic types.) +1 There's at least one stdlib module that does this pretty well (sqlite3, I think). This is where a simple serialization (and deserialization of course) protocol would come in handy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Ethan Furman added the comment: Nick, in your example it looks like json is using the __str__ for int, but the __repr__ for float -- is this correct? -- assignee: - ethan.furman nosy: +eli.bendersky, ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Barry A. Warsaw added the comment: On Jun 19, 2013, at 02:09 PM, Eric Snow wrote: There's at least one stdlib module that does this pretty well (sqlite3, I think). This is where a simple serialization (and deserialization of course) protocol would come in handy. Yeah, my database layer also has to be taught how to handle enums! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Antoine Pitrou added the comment: What if we use int(str(value)) instead? You mean str(int(value)). Sounds good to me. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Antoine Pitrou added the comment: Serialization isn't the only issue - you have to know how to deserialize as well. I think this is pretty much besides the point. IntEnums are meant to be substitutible with plain ints, so you can deserialize as a plain int. Moreoven, JSON doesn't fill the same use cases as pickle: it is meant to communicate with services written in any languages, and those services won't have the same enum mnemonics as your Python library. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Nick Coghlan added the comment: While I agree with forcing int subclasses to true integers in the JSON module, that may not be enough - the problem will affect third party serialisers as well. Whiel the debugging gains won't be as high, we may need to override __str__() in enum.IntEnum to give the raw form (leaving the debugging form solely for repr). As for the float behaviour, the JSON serialiser is almost certainly playing games to avoid the truncation that used to occur in float.__str__ (I don't recall if we actually got rid of that, or if it's just a lot harder to trigger these days - it definitely changed when float.__repr__ was updated to prefer human friendly representations that produce the same floating point number). I'm less concerned about that, since we don't plan to swap out any standard library floats for enums. We may still want to mention the potential compatibility issue somewhere in the docs, though. Backwards compatibility is such fun, isn't it? :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Ethan Furman added the comment: I have no problem with leaving __str__ as the inherited type's, and just keeping the __repr__ as the enum add-on; this could be one of the differences between a pure Enum and a hybrid Enum. Is it safe to change the json behaviour back to using __str__ for floats? If so, those two updates and we could be good to go. (Famous last words? ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Ethan Furman added the comment: Eric, The pickle support is solely in Enum. No changes were made to pickles. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17180] shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
Christian Heimes added the comment: Shouldn't you try to make the permission removal atomic? Otherwise there's a window of opportunity to exploit the suid bit. Permissions bits are copied from the source file *after* all data has been copied to the destination file. copy() calls copyfile() followed by copymode() copyfile() doesn't create files with SUID. In fact it has 0666 umask. In worst case the new file is readable and writable by every user. The new patch addresses the unlikely issue with os.open()ing the file with mask=0600. I could also add a create_mode argument to _io.FileIO() in order to make the permission bits of new files more flexible. Modules/_io/fileio.c hard codes mode as 0600. -- Added file: http://bugs.python.org/file30647/17180_preserve_sbits2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18265] typedef lookupfunc defined by not used
New submission from David Edelsohn: Objects/setobject.c:217:25: warning: typedef 'lookupfunc' locally defined but not used [-Wunused-local-typedefs] This was fixed in trunk (changeset 84208:626a8e49f2a9) and should be backported to 3.3 branch. This is a warning found by GCC 4.8. -- components: Build messages: 191483 nosy: David.Edelsohn priority: normal severity: normal status: open title: typedef lookupfunc defined by not used type: compile error versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18265 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18248] fficonfig.py.in wrong for AIX
Roundup Robot added the comment: New changeset 00082406e13f by Benjamin Peterson in branch '3.3': fix libffi build on AIX (closes #18248) http://hg.python.org/cpython/rev/00082406e13f New changeset 974d4844d5a7 by Benjamin Peterson in branch 'default': merge 3.3 (#18248) http://hg.python.org/cpython/rev/974d4844d5a7 -- nosy: +python-dev resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18248 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18248] fficonfig.py.in wrong for AIX
Changes by STINNER Victor victor.stin...@gmail.com: -- versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18248 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18263] python.man: no documentation for -b, -X
R. David Murray added the comment: I think we tend to forget that that page exists. Patches welcome. -- keywords: +easy nosy: +r.david.murray stage: - needs patch type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18263 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11016] stat module in C
Changes by Christian Heimes li...@cheimes.de: Removed file: http://bugs.python.org/file30147/statmodule.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11016] stat module in C
Christian Heimes added the comment: New patch with extensive tests for the stat module. The tests are testing both the new C module and the old stat.py module. -- Added file: http://bugs.python.org/file30648/statmodule2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16748] Make CPython test package discoverable
Zachary Ware added the comment: So many things have been fixed since I last made a list of failing modules that it seemed like time to make a new one. First, failing modules that already have open issues with patches: - test_codecmaps* (issue18258) - test_concurrent_futures (issue16968) - test_locale (issue17767) - test_multiprocessing (issue17778) - test_socket (issue14408 -- incomplete patch, waiting on resolution of issue16968 for how to handle thread/process reaping) Other tests that fail, that may be the fault of my test machine rather than the tests themselves (or, ones that I'd like others to try before I call them broken): - test_urllib2net (fails on my machine on normal runs due to network setup) - test_shutil (fails on my machine on normal runs for unknown reasons relating to symlinks) The below tests fail for reasons that I expect to probably be related to test run order, as all of them pass when narrowing the pattern to match only them (e.g., test_dbm*.py rather than test_*.py): - test_dbm (had a permission error on a test file) - test_venv (tried to delete a temp dir that was unexpectedly non-empty) - test_wsgiref (failure in testEnviron) - test_logging (failure in test_warnings) - test_inspect (had some issue with locating its test files) This leaves only 6 other tests that fail due to improper inheritance, setup done in test_main rather than setUp/setUpClass/setUpModule, or other reasons directly related to discovery: - test_decimal - test_largefile - test_pickle (pickletester) - test_runpy - test_shelve - test_xml_etree Other tests that need some manner of attention related to discovery: - test_json: it half-uses discovery, it could use it completely - test_importlib: about the same as test_json - leakers package: either rename to non-discoverable names or otherwise make leakers.test_gestalt (in particular) not report an error when discovered. This may not be a comprehensive list, but it does cover all of the most obvious failures that remain. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16748 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16662] load_tests not invoked in package/__init__.py
Changes by Zachary Ware zachary.w...@gmail.com: -- nosy: +zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16662 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18262] ZipInfo.external_attr are not documented
anatoly techtonik added the comment: 3.4+ feature is not a replacement for proper documentation for 2.7-3.4 -- resolution: duplicate - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18262 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue935117] pkgutil doesn't understand case-senseless filesystems
Changes by Ankur Ankan ankuran...@gmail.com: -- nosy: +Ankur.Ankan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue935117 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3354] Improve error reporting for the argument parsing C API
Changes by Ankur Ankan ankuran...@gmail.com: -- nosy: +Ankur.Ankan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3354 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18263] python.man: no documentation for -b, -X
Corey Brune added the comment: Hello, I added the two options requested in python.man in the patch file created from hg diff python.man.patch. -- keywords: +patch nosy: +cbrune Added file: http://bugs.python.org/file30649/python.man.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18263 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18265] typedef lookupfunc defined by not used
David Edelsohn added the comment: Will not fix in Python 3.3. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18265 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Ethan Furman added the comment: I was unable to find any references to previous problems with json and floats. A quick-n-dirty patch yields the following: -- from json import dumps, loads -- from enum import Enum -- class FE(float, Enum): ... pass ... -- class Test(FE): ... one = 1.0 ... -- Test.one Test.one: 1.0 -- str(Test.one) '1.0' -- dumps(Test.one) '1.0' -- loads(dumps(Test.one)) 1.0 All json and enum tests are still passing. If this is an acceptable solution I'll create a nicer patch and post for review. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11016] Re-implementation of the stat module in C
Christian Heimes added the comment: The latest patch comes with more comments and documentation updates. The C implementation defines all existing constants to the hard coded values from stat.py if the platform doesn't provide them. The approach keeps maximum backward compatibility with the old stat module. I have also added the new constants and functions to the pure Python implementation for maximum compatibility with other Python implementation. -- title: stat module in C - Re-implementation of the stat module in C Added file: http://bugs.python.org/file30650/statmodule3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16499] CLI option for isolated mode
Christian Heimes added the comment: I'm catching up on some old patches. What shall I do about this patch? Does anybody want to review or intervene it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16499 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18266] Fix test discovery for test_largefile.py
New submission from Zachary Ware: This one is another inheritance issue. The patch removes unittest.TestCase as a base for LargeFileTest and converts test_main into setUpModule, load_tests, and tearDownModule. This seems like the way to go due to the fact that the order of test execution matters: test_seek must be first and test_truncate must be last. The only way around that restriction would be to create a new copy of the file for test_truncate, which would make the test take even longer and use even more resources. Also, the programmatic creation of the C and Py variants of the test has been changed from creating an empty subclass of LargeFileTest which is then renamed and assigned an 'open' attr, to using the three-arg form of type to create a subclass of LargeFileTest and unittest.TestCase with name set and an 'open' attr pointing to the correct function. Lastly, the superfluous check on whether f.truncate is available that had been in test_main is now removed so that the test is properly marked as skipped if skipped. -- components: Tests files: test_largefile_discovery.diff keywords: patch messages: 191494 nosy: brett.cannon, ezio.melotti, zach.ware priority: normal severity: normal status: open title: Fix test discovery for test_largefile.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30651/test_largefile_discovery.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18266 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18267] xmlrpc.client documentation multicall example missleading for division behaviour of python3
New submission from Bernhard Reiter: http://docs.python.org/3.4/library/xmlrpc.client.html as of 2013-06-19 20:35 UTC has a divide example and the output can misslead the learning reader towards the new behaviour of python3 with the '/' binary operator for division. server code: def divide(x, y): return x/y client code: multicall.divide(7,3) [..] print(7+3=%d, 7-3=%d, 7*3=%d, 7/3=%d % tuple(result)) The client call results into: python3 client.py 7+3=10, 7-3=4, 7*3=21, 7/3=2 This is missleading because '7/3' is now resulting to a float in python3 (see PEP238).The example probably was copied over from the python2 documentation where '7/3' result to int. The implicit conversion from float to int is done in the string formatting. Proposal replace the print line with print(7+3=%d, 7-3=%d, 7*3=%d, 7/3=%g % tuple(result)) to get 7+3=10, 7-3=4, 7*3=21, 7/3=2.3 or print(repr(tuple(result))) to get (10, 4, 21, 2.3335) -- assignee: docs@python components: Documentation messages: 191495 nosy: ber, docs@python priority: normal severity: normal status: open title: xmlrpc.client documentation multicall example missleading for division behaviour of python3 versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18267 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11193] test_subprocess error on AIX
Changes by David Edelsohn dje@gmail.com: -- components: +Interpreter Core nosy: +David.Edelsohn type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11193 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18140] urlparse.urlsplit confused to fragment when password include #
Madison May added the comment: Here's a potential patch for the issue, should we decide it's worth fixing. All current tests pass with the update version of _splitnetloc(), and I've added a test to test_urlparse to check that urls with '#' or '?' in the password field are treated properly. -- keywords: +patch Added file: http://bugs.python.org/file30652/password_delimiters.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18140 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18268] ElementTree.fromstring non-deterministically gives unicode text data
New submission from Brendan O'Connor:
(This is Python 2.7 so I'm using string vs unicode terminology.)
When I use ElementTree.fromstring(), and use the .text field on nodes, the
value is usually a string object, but in rare cases it's a unicode object. I'm
parsing many XML documents of newspaper text [1]; on one subset of the data,
out of 5 million nodes, ~200 of them have a unicode object for the .text field.
I think this is all related to http://bugs.python.org/issue11033 but I can't
figure out how, exactly. I'm passing in strings to ElementTree.fromstring()
like you're supposed to.
The workaround is to defensively convert the .text value to unicode [3].
[1] data is
http://www.ldc.upenn.edu/Catalog/catalogEntry.jsp?catalogId=LDC2012T21
[2] my processing code is
https://github.com/brendano/gigaword_conversion/blob/master/annogw2justsent.py
[3]
def convert_to_unicode(mystr):
if isinstance(mystr, unicode):
return mystr
if isinstance(mystr, str):
return mystr.decode('utf8')
--
messages: 191496
nosy: Brendan.OConnor
priority: normal
severity: normal
status: open
title: ElementTree.fromstring non-deterministically gives unicode text data
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18268
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11185] test_wait4 error on AIX
Changes by David Edelsohn dje@gmail.com: -- nosy: +David.Edelsohn type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11185 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11188] test_time error on AIX
Changes by David Edelsohn dje@gmail.com: -- components: +Extension Modules type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11188] test_time error on AIX
Changes by David Edelsohn dje@gmail.com: -- nosy: +David.Edelsohn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11188 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ezio.melotti, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18264 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18264] enum.IntEnum is not compatible with JSON serialisation
Ethan Furman added the comment:
Here's the relevant routine from _json.c:
-
static PyObject *
encoder_encode_float(PyEncoderObject *s, PyObject *obj)
{
/* Return the JSON representation of a PyFloat */
double i = PyFloat_AS_DOUBLE(obj);
if (!Py_IS_FINITE(i)) {
if (!s-allow_nan) {
PyErr_SetString(PyExc_ValueError, Out of range float values are
not JSON compliant);
return NULL;
}
if (i 0) {
return PyUnicode_FromString(Infinity);
}
else if (i 0) {
return PyUnicode_FromString(-Infinity);
}
else {
return PyUnicode_FromString(NaN);
}
}
/* Use a better float format here? */
return PyObject_Repr(obj);
}
Possible solutions
--
- Use PyObject_Str() instead of PyObject_Repr()
I was unable to find any references to why it isn't currently
PyObject_Str(), but switching over to it did not break any tests
- Coerce the obj to a PyFloat, and take the repr of that (just use the `i`)
float subclasses would always lose the subclass status, but that is lost on
deserialization anyway unless a custom decoder is used; and if a custom decoder
is being used I would think a custom encoder is also being used?
Summary
---
Having hybrid Enums not change __str__ would solve most of the json
serialization issues;
either of the above two changes will solve the json issue of enumerated floats.
Thoughts on which route to take for json?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18264
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18233] SSLSocket.getpeercertchain()
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18233 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18263] python.man: no documentation for -b, -X
Senthil Kumaran added the comment: Thanks for the patch. Committed these changes in: changeset dfead0696a71 changeset e26b00adb7ba -- nosy: +orsenthil resolution: - fixed stage: needs patch - committed/rejected status: open - closed versions: +Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18263 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18268] ElementTree.fromstring non-deterministically gives unicode text data
R. David Murray added the comment: This kind of thing is why python3 exists. Presumably some bit of the elementree code is successfully converting non-ascii into unicode, and then when that is mixed with the result it is returning, you end up with unicode. But that is just a guess; you'll have to dig into a specific example to figure out why it is happening. Or when you say non-deterministically, do you mean that you have tried to reproduce it with a specific entry that returns unicode in the full run and it does not reproduce? Although even in that case it might be due to some complex interaction in the non-reduced code... It might be interesting to run it under python3 and see if anything odd happens there...but it will probably just work. -- components: +XML nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18268 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18268] ElementTree.fromstring non-deterministically gives unicode text data
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +eli.bendersky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18268 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18268] ElementTree.fromstring non-deterministically gives unicode text data
Brendan O'Connor added the comment: By non-deterministic I just mean that the conversion happens for some data but not other data. I should try to find examples that causes it to happen. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18268 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
