[issue9157] Allow inspection of used decorators on a function
Mitar added the comment: Here is the concrete code how I imagined that: http://code.djangoproject.com/ticket/13854 So this would be not made in code of `wraps` function, but would be contract for implementers to do it, if they want to be visible (maybe they still do not want that). And all built-in decorators should do that then. -- ___ Python tracker <http://bugs.python.org/issue9157> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1652] subprocess should have an option to restore SIGPIPE to default action
Mitar added the comment: GHC Haskell compiler is currently opting for a different solution: installing an default empty handler which is cleared by exec automatically and signal handler is restored back to SIG_DFL: http://hackage.haskell.org/trac/ghc/ticket/4274 -- nosy: +mitar ___ Python tracker <http://bugs.python.org/issue1652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24739] allow argparse.FileType to accept newline argument
Mitar added the comment: I think the issue is that it is hard to subclass it. Ideally, call to open would be made through a new _open method which would then call it, and one could easily subclass that method if/when needed. -- nosy: +mitar ___ Python tracker <https://bugs.python.org/issue24739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22848] Subparser help does not respect SUPPRESS argument
Change by Mitar : -- nosy: +mitar ___ Python tracker <https://bugs.python.org/issue22848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5752] xml.dom.minidom does not escape CR, LF and TAB characters within attribute values
Change by Mitar : -- nosy: +mitar ___ Python tracker <https://bugs.python.org/issue5752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14465] xml.etree.ElementTree: add feature to prettify XML output
Change by Mitar : -- nosy: +mitar ___ Python tracker <https://bugs.python.org/issue14465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37374] Minidom does not have to escape quote inside text segments
New submission from Mitar : I am using Minidom to pretty-print XML. But currently if there is a quote inside a text segment it escapes it to " To my understanding this is unnecessary if all other symbols are escaped. This escaping makes it really ugly and defeats the purpose of me using Minidom for pretty-printing XML. -- components: XML messages: 346296 nosy: mitar priority: normal severity: normal status: open title: Minidom does not have to escape quote inside text segments type: enhancement versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue37374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37374] Minidom does not have to escape quote inside text segments
Change by Mitar : -- keywords: +patch pull_requests: +14134 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14312 ___ Python tracker <https://bugs.python.org/issue37374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37374] Minidom does not have to escape quote inside text segments
Mitar added the comment: FYI, this is exactly how ElementTree.tostring does it. So this would make ElementTree.tostring behave the same as minidom. @dhilst: I do not think a parameter is needed here. This is completely compatible with HTML. It is just that currently an additional unnecessary escaping (for both XML in HTML context) is done. -- ___ Python tracker <https://bugs.python.org/issue37374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17239] XML vulnerabilities in Python
Change by Mitar : -- nosy: +mitar ___ Python tracker <https://bugs.python.org/issue17239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37442] Minidom should not pretty-print inside text elements
New submission from Mitar : Inside text elements both in HTML and SVG white-space is significant and introduces differences in how things are rendered. By default in general all white-space is collapsed into one space and then this is rendered, adding additional text content. I observed this while working with SVG which can have content like: foobar After pretty-printing it with minidom, and white-space collapsing, the following is what is input to SVG rendering: foo bar And space between "foo" and "bar" is now visible and while before it was one word to the user, now it is shown as two. Related issue: https://github.com/mozman/svgwrite/issues/58 I think pretty-printing not add whitespace inside text elements. -- components: XML messages: 346846 nosy: mitar priority: normal severity: normal status: open title: Minidom should not pretty-print inside text elements versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue37442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37374] Minidom does not have to escape quote inside text segments
Mitar added the comment: Sure, but is old behavior useful in any use case? Every bugfix changes old behavior in an irreversible way. So in which use case you want the old behavior? Can you elaborate here? -- ___ Python tracker <https://bugs.python.org/issue37374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30995] Support logging.getLogger(style='{')
New submission from Mitar:
Currently, using non-legacy formatting in logging message is really cumbersome.
I think a new style could be supported much easier using the following:
logger = logging.getLogger(style='{')
logger.misc('User {} logged in', username}
This is both backwards compatible, and does not interfere with 3rd party
packages which might use a different logger with different style. You only have
to make sure they do not use this logger without knowing about new format,
which can be done in various ways (like prefixing the name of the logger, for
example).
See https://bugs.python.org/issue14031 for more information, where this has
also been proposed but not really commented upon.
--
components: Library (Lib)
messages: 298883
nosy: mitar
priority: normal
severity: normal
status: open
title: Support logging.getLogger(style='{')
type: enhancement
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue30995>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30995] Support logging.getLogger(style='{')
Mitar added the comment:
> That's the problem, right there. I don't think the ways of doing this are
> bulletproof and require too much cooperation between third-party libraries.
Which third-party libraries? The thing I am proposing works for that particular
file you call getLogger with.
In my files I already have:
logger = logging.getLogger(__name__)
Changing that to:
logger = logging.getLogger(__name__, style='{')
seems easy and backwards compatible. How will I break any other 3rd party use
by doing this? It is my code in my file.
The only issue is that you have to make sure you are not passing object on. But
that again, is your code, so you should know what you are passing on.
We could also add logger.defaultStyle() to return the same logger, with default
style, so that you can pass it on to other function which might expect a
logger, if you want that. Or, you could define:
defaultLogger = logging.getLogger(__name__)
logger = logging.getLogger(__name__, style='{')
at the beginning of the file, and then use logger in the file, and pass
defaultLogger on.
There are so many options to address your concerns.
> I don't see how it's "really cumbersome". A simple approach is outlined in
Simple approach by everywhere in my code having to use __ now? So I have _ for
string translations, and __ for logging. This is cumbersome. Because it could
be solved by having it only once in the file. Not that I have to call it
manually everywhere in the file.
> which is also described in the documentation here:
Yes, I have read it, used it, didn't like it. So I thought about it and it
feels pretty easy to provide a capacity to have a default style applied to the
whole file. Instead of manually having to call __. It would effectively be the
same internally. Just cleaner code. Do not repeat yourself. Repeating __
everywhere is repeating myself a lot. I would like this style. Let this be
specified only once.
--
___
Python tracker
<http://bugs.python.org/issue30995>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13824] argparse.FileType opens a file and never closes it
Mitar added the comment: Why not make FileType instance also a context manager, so you could do something like: with arguments.input as f: assert arguments.input is f For backwards compatibility, FileType would open eagerly as now, but it would be closed at exit from context manager. We should just make sure we do not close stdout/stderr. -- nosy: +mitar ___ Python tracker <https://bugs.python.org/issue13824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36841] Supporting customization of float encoding in JSON
New submission from Mitar : Currently, there is only one argument which allows customization how float numbers are encoded in JSON: allow_nan. But this does not allow one to hook into the encoding of floating points really. The JSONEncoder is not called for float numbers. The motivation here is that we would like to encode NaN and Infinity values differently, instead of non-standard approach and instead of raising an exception. The "load" counterpart has "parse_float" which one can use to hook into parsing floats. I would suggest something similar, maybe "encode_float" which if provided would be used instead of the default. -- components: Library (Lib) messages: 341817 nosy: mitar priority: normal severity: normal status: open title: Supporting customization of float encoding in JSON ___ Python tracker <https://bugs.python.org/issue36841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13824] argparse.FileType opens a file and never closes it
Mitar added the comment: > So it's already possible to do what you describe, simply by doing: I think there is an edge case here if a stdin/stdout is opened? It would get closed at exist from the context, no? So I suggest that a slight extension of what open otherwise returns is returned which make sure context manager applies only to non-stdin/stdout handles. -- ___ Python tracker <https://bugs.python.org/issue13824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36841] Supporting customization of float encoding in JSON
Mitar added the comment: That would be awesome! BTW, just as an additional example, JavaScrpt's JSON.stringify encodes NaN and Infinity to null. By having a custom function I could for example try to match such implementation. -- ___ Python tracker <https://bugs.python.org/issue36841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12932] filecmp.dircmp does not allow non-shallow comparisons
Change by Mitar : -- nosy: +mitar ___ Python tracker <https://bugs.python.org/issue12932> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15450] Allow dircmp.subdirs to behave well under subclassing
Change by Mitar : -- nosy: +mitar ___ Python tracker <https://bugs.python.org/issue15450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15450] Allow dircmp.subdirs to behave well under subclassing
Change by Mitar : -- pull_requests: +4962 ___ Python tracker <https://bugs.python.org/issue15450> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21363] io.TextIOWrapper always closes wrapped files
Mitar added the comment: I have a similar problem that text wrapper is closing the handle, and if I want to make a workaround, it also fails: buffer = io.Bytes() with io.TextIOWrapper(buffer, encoding='utf8') as text_buffer: write_content_to(text_buffer) text_buffer.flush() text_buffer.detach() Now this fails when context manager is trying to close the text_buffer with an error that it is already detached. If I do not detach it, then it closes buffer as well. -- nosy: +mitar ___ Python tracker <https://bugs.python.org/issue21363> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14653] Improve mktime_tz to use calendar.timegm instead of time.mktime
New submission from Mitar :
I would suggest improvement of mktime_tz to use calendar.timegm internally
instead of time.mktime. The problem is that on Windows mktime_tz fails with
"mktime argument out of range" for this code:
mktime_tz(parsedate_tz('Thu, 1 Jan 1970 00:00:00 GMT'))
if user is in GMT+X timezone. Obviously, "Thu, 1 Jan 1970 00:00:00 GMT" is not
out of range. But because mktime_tz uses internally time.mktime which takes
into the account local time (and local timezone) and then compensate for the
timeline, out of range condition happens. I would suggest such implementation:
def mktime_tz(data):
"""Turn a 10-tuple as returned by parsedate_tz() into a UTC timestamp."""
if data[9] is None:
# No zone info, so localtime is better assumption than GMT
return time.mktime(data[:8] + (-1,))
else:
t = calendar.timegm(data[:8] + (0,))
return t - data[9]
It does not raise and exception, and it is also much cleaner: directly using
GMT function and not localtime with timezone compensation.
--
components: Library (Lib)
messages: 159074
nosy: mitar
priority: normal
severity: normal
status: open
title: Improve mktime_tz to use calendar.timegm instead of time.mktime
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue14653>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15881] multiprocessing 'NoneType' object is not callable
Changes by Mitar : -- nosy: +mitar ___ Python tracker <http://bugs.python.org/issue15881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2504] Add gettext.pgettext() and variants support
Mitar added the comment: I would just like to add that I am also looking forwards to this feature. -- nosy: +mitar ___ Python tracker <http://bugs.python.org/issue2504> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9157] Allow inspection of used decorators on a function
New submission from Mitar : Sometimes it is useful to be able to check which decorators are already applied to a function, especially when you are constructing them dynamically. I am proposing that for all decorators in Python would be suggested that they maintain a list of used decorators on a function. It is most useful when all decorators do this. It is the same reasoning why `inspect` module is in Python - to be able to inspect Python structures, to have this possibility. If you do not want it then you do can use Python structures as they were given to you. But you have an option to inspect them. And I would like the same to see from decorators. It is not really so important that all decorators update this. If they would not then they would be hidden from inspection. But if developer wants to use inspection then he would choose such decorators which use this (or change them in this way). If all default Python's decorators would already be such it would be much easier to use them. This could be implement by changing `wraps` function to pass over also the (for example) `__DECORATORS__` attribute of a function to a wrapped function and add this new decorator to a list, `__DECORATORS__`. By default in a list ids of decorators would be maintained, but this could be overridden by `id` attribute of `wraps` function so that decorator can represent itself in some special way, for example as a tuple of its id and some significant parameters. -- messages: 109283 nosy: mitar priority: normal severity: normal status: open title: Allow inspection of used decorators on a function type: feature request ___ Python tracker <http://bugs.python.org/issue9157> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
