[issue17795] backwards-incompatible change in SysLogHandler with unix domain sockets
New submission from Mike Lundy: The changed merged from http://bugs.python.org/issue16168 causes a regression in SysLogHandler behavior. The socktype of /dev/log is dependent on syslog configuration, and the fallback behavior (trying SOCK_DGRAM and then SOCK_STREAM if the former failed) was very useful. A better fix for this would preserve the fallback behavior in cases where the caller has not specifically requested a socktype. I've attached a patch with one such approach. -- components: Library (Lib) files: 0001-Restore-SysLogHandler-fallback-for-AF_UNIX-sockets.patch keywords: patch messages: 187347 nosy: Mike.Lundy priority: normal severity: normal status: open title: backwards-incompatible change in SysLogHandler with unix domain sockets type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file29937/0001-Restore-SysLogHandler-fallback-for-AF_UNIX-sockets.patch ___ Python tracker <http://bugs.python.org/issue17795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17795] backwards-incompatible change in SysLogHandler with unix domain sockets
Mike Lundy added the comment: It doesn't fix it unless I change the configuration (and in some cases the code) for every SyslogHandler across all of our projects, plus every single library we use. Google around For "SysLogHandler /dev/log socktype" and then compare with "SysLogHandler /dev/log". You won't find many hits where people set socktype, because people knew that SyslogHandler just Did The Right Thing when presented with an AF_UNIX. That has been the behavior since the logging module was introduced in 2.3. I'm just asking that you preserve the default behavior that has existed since python 2.3- that was the purpose of my patch. I'm not tied to how I implemented it (I mean, it is kind of ugly) but I believe preserving the behavior is important, and I also believe that it will break less code than what is currently there (because, after all, socktype was only introduced in 2.7, the SysLogHandler doesn't care if it's None, and subclasses couldn't have relied on it in the AF_UNIX case because the original fallback didn't update it) -- ___ Python tracker <http://bugs.python.org/issue17795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17795] backwards-incompatible change in SysLogHandler with unix domain sockets
Mike Lundy added the comment: On top of your patch? Yeah, I think so. (I wrote it the way I did so it could handle syslog configuration changes, but that's kind of an uncommon case). Thanks! -- ___ Python tracker <http://bugs.python.org/issue17795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17795] backwards-incompatible change in SysLogHandler with unix domain sockets
Mike Lundy added the comment: I've tested in our full dev setup, and it seems to work fine; I've also tested on my laptop, no problems there either. Unfortunately, that's python 2.7.4 in both cases. I don't really have a python3 setup I can bump up to test. -- ___ Python tracker <http://bugs.python.org/issue17795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24840] implement bool conversion for enums to prevent odd edge case
New submission from Mike Lundy:
There's a slightly odd edge case which can be summarized as follows:
from enum import Enum
class Bool(Enum):
Yep = True
Nope = False
for value in Bool:
print('%18r is %r' % (value, bool(value)))
output:
is True
is True
This isn't really a big deal, but can be made better with the attached patch. I
can't think of any odd consequences this might cause, but others may know
better.
--
messages: 248378
nosy: novas0x2a
priority: normal
severity: normal
status: open
title: implement bool conversion for enums to prevent odd edge case
type: enhancement
___
Python tracker
<http://bugs.python.org/issue24840>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24840] implement bool conversion for enums to prevent odd edge case
Mike Lundy added the comment: @r.david.murray man you're fast :) Sorry, realized I forgot to actually run the tests for 3.5 and 3.4, I'd only run them for master (I've now run them for 3.5 and 3.4 now, too). -- keywords: +patch Added file: http://bugs.python.org/file40160/issue24840.master.patch ___ Python tracker <http://bugs.python.org/issue24840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24840] implement bool conversion for enums to prevent odd edge case
Mike Lundy added the comment: (I should note that I just recently signed the contributor agreement, not that this a particularly complex fix, but it hasn't propagated to my profile yet). -- ___ Python tracker <http://bugs.python.org/issue24840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24840] implement bool conversion for enums to prevent odd edge case
Mike Lundy added the comment: @serhiy.storchaka: It's somewhat of a special case, to be sure. However, I do think it's justified to put it into the base (rather than a user type) for three reasons: 1) It makes IntEnum and Enum consistent. IntEnum actually already handles this case just fine, because it's an int and therefore already supports __bool__ correctly. It feels odd that changing the storage format from an IntEnum to a Enum should break the logic- correctly used, the actual enum values should never matter. This small change just brings them into line. 2) It is less surprising than the current case; I discovered this when I did something like the Enum.Nope case here, and I naively used the enum in an if statement, assuming that the value would control the __bool__ value. (This was caught by my tests, of course, but the point remains that I wrote the code). Normally in python, you'd expect the default bool conversion to be unconditionally True, but enums aren't really normal objects; for any use case for which there is a default noop value, you'd generally put that value _into_ the enum: class FilterType(Enum): NONE = None SUB = 'Sub' UP = 'Up' ... 3) It's not logically inconsistent with the idea of Enums. The other dunder methods you mention aren't consistent with the concept: __float__ (enum values aren't generally numbers except as an implementation detail), __lt__ (enums aren't generally ordered), __len__ (enums aren't generally containers). The one thing an enum does have is a value, and it feels consistent to me to check the truthiness of an enum without having to reach into the .value to do so. Anyway, that's my case for inclusion! -- ___ Python tracker <http://bugs.python.org/issue24840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
