[issue37598] Don't use _ as a function name in logging documentation cookbook
Change by Vinay Sajip : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37598] Don't use _ as a function name in logging documentation cookbook
Vinay Sajip added the comment: > Since order of kwargs is guaranteed from Python 3.6 can this be removed? Well, the statement about order isn't inaccurate when talking about Python in general and the cookbook is a resource meant to be useful across multiple Python implementations and versions, so I'd be inclined to leave it as is. -- ___ Python tracker <https://bugs.python.org/issue37598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37598] Don't use _ as a function name in logging documentation cookbook
Vinay Sajip added the comment: The comment at the end of the "_ = ..." line indicates clearly that it's optional to do that, and I assume that any reader will realise that they can use any suitable variable name rather than "_". There's no particular "recommendation" to use "_" and cookbook recipes are generally regarded as starting points for one's own code, rather than being copied verbatim into production scenarios. I specifically picked "_", despite knowing its other uses, because: * One use of "_" is as a function that does some form of translation on a passed string argument - language translation being the most common example - and this recipe is a very loose analogue of that type of usage * A very brief notation assists readability because once you've looked at the "_" definition, you can use constructions like the one further down in the recipe. Since "_" wasn't picked at random, I'd rather not change it - if people decide to use this recipe, it would be better for brevity and standardisation if "_" were to be used, IMO. I don't believe the usage of "_" in interactive interpreter sessions is relevant to this cookbook recipe and shouldn't, in my opinion, cause confusion, any more than where the use of "_" for language translations is being explored in an interactive session. In summary - please don't waste your time on this, though I appreciate the intent behind your suggestion - thanks. -- ___ Python tracker <https://bugs.python.org/issue37598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37563] Documentation - default for StreamHandler
Vinay Sajip added the comment: > This is a fallacy. What fallacy? I was responding to "does anyone else have opinions on this?" I can't read minds of people all over the world, so I have to go by my best guess, which is based on how many times this issue has been reported before - which I believe is zero. > It's also assuming you have seen and remember every single bug report related > to this from the past 16 years which, nothing personal, seems incredibly > unlikely given how poor humans are at remembering things in the first place. Feel free to do a search on here to see if you can find an earlier issue about this. > I'm presuming to speak for end-users yes, why not? Because they're a very diverse bunch who don't all speak with one voice. I, too, am a user (of other people's code) as much as a developer. I don't see things the same way as you do, here, and it's not because it's my code. I'd probably feel the same way if you'd pointed to some other instance of Python code which does the same kind of thing. There are numerous examples in the stdlib where None is passed in and some other value (e.g. 'utf-8' for an encoding) are used as a default, without that value appearing in any documented argument list. -- ___ Python tracker <https://bugs.python.org/issue37563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37563] Documentation - default for StreamHandler
Vinay Sajip added the comment: > the prose clearly say that the default is sys.stderr, however the code > doesn't show that Which code are you looking at? Here is the entirety of StreamHandler.__init__: def __init__(self, stream=None): """ Initialize the handler. If stream is not specified, sys.stderr is used. """ Handler.__init__(self) if stream is None: stream = sys.stderr self.stream = stream > We users Do. Not. Care. about how wonderfully clever your implementation is, > we care about how it actually works. Whatever Rube-Goldbergian implementation > details there are behind the scenes are of no interest to us. I'm not sure your tone is particularly constructive here. I don't regard the code you say you've read, reproduced above, is particularly Rube-Goldbergian, or even Heath-Robinsonish. And are you presuming to speak for all Python users here? > Fine, lets try this another way - does anyone else have opinions on this? As far as I can remember, you're the first person to bring this up since logging was added to Python in 2003. In all that time, no-one appears to have been confused by that prose, which has been there since pretty much the beginning, though there was a spelling change and a logging documentation reorganisation around 9 years ago. -- ___ Python tracker <https://bugs.python.org/issue37563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37563] Documentation - default for StreamHandler
Vinay Sajip added the comment: The devil is in the detail. If stream=sys.stderr is specified, that takes effect at import time. If stream=None is specified and the implementation chooses to treat that as sys.stderr, that takes effect at the time of the call. The two are not equivalent. It was a conscious choice by me to implement it this way, and I believe it's clearly documented what happens, which should be sufficiently clear for users. Which part of "If stream is specified, the instance will use it for logging output; otherwise, sys.stderr will be used." is unclear? -- resolution: -> not a bug status: open -> closed ___ Python tracker <https://bugs.python.org/issue37563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37563] Documentation - default for StreamHandler
Vinay Sajip added the comment: If None is passed, that is interpreted to mean whatever the implementation default is, and that is sys.stderr. For backwards compatibility, that won't change: and I don't see any need to update the documentation, as it makes it perfectly clear that sys.stderr will be used if None is specified. Nor do I see a need to change the default parameter value from its current value of None. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37563> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37470] Make it explicit what happens when using a bounded queue with QueueHandler
Change by Vinay Sajip : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37470] Make it explicit what happens when using a bounded queue with QueueHandler
Vinay Sajip added the comment: New changeset 91f9f098fcdb023dbb89d06c8833e89a11cbae4c by Vinay Sajip (Miss Islington (bot)) in branch '3.8': bpo-37470: Document more clearly the error handling for QueueHandler.emit(). (GH-14532) (GH-14533) https://github.com/python/cpython/commit/91f9f098fcdb023dbb89d06c8833e89a11cbae4c -- ___ Python tracker <https://bugs.python.org/issue37470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37470] Make it explicit what happens when using a bounded queue with QueueHandler
Vinay Sajip added the comment: New changeset 844a9d64a4f640d1b20dc6ea54ab375680332d93 by Vinay Sajip (Miss Islington (bot)) in branch '3.7': bpo-37470: Document more clearly the error handling for QueueHandler.emit(). (GH-14532) (GH-14534) https://github.com/python/cpython/commit/844a9d64a4f640d1b20dc6ea54ab375680332d93 -- ___ Python tracker <https://bugs.python.org/issue37470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37470] Make it explicit what happens when using a bounded queue with QueueHandler
Vinay Sajip added the comment: New changeset 0f4e8132820947d93eccf31b9e526b81c6ffa53d by Vinay Sajip in branch 'master': bpo-37470: Document more clearly the error handling for QueueHandler.emit(). (GH-14532) https://github.com/python/cpython/commit/0f4e8132820947d93eccf31b9e526b81c6ffa53d -- ___ Python tracker <https://bugs.python.org/issue37470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37470] Make it explicit what happens when using a bounded queue with QueueHandler
Change by Vinay Sajip : -- keywords: +patch pull_requests: +14345 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14532 ___ Python tracker <https://bugs.python.org/issue37470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37469] Make it explicit that logging QueueHandler / QueueListener accepts a SimpleQueue.
Change by Vinay Sajip : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37469> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37469] Make it explicit that logging QueueHandler / QueueListener accepts a SimpleQueue.
Vinay Sajip added the comment: New changeset 6cde61369e8174c493ca240cb52ebc9c2a2fe667 by Vinay Sajip (Miss Islington (bot)) in branch '3.8': bpo-37469: Document usability of SimpleQueue with QueueHandler and QueueListener. (GH-14521) (GH-14525) https://github.com/python/cpython/commit/6cde61369e8174c493ca240cb52ebc9c2a2fe667 -- ___ Python tracker <https://bugs.python.org/issue37469> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37469] Make it explicit that logging QueueHandler / QueueListener accepts a SimpleQueue.
Vinay Sajip added the comment: New changeset b0ab95bbe792b38e952688f8fa1657a78b35410e by Vinay Sajip (Miss Islington (bot)) in branch '3.7': bpo-37469: Document usability of SimpleQueue with QueueHandler and QueueListener. (GH-14521) (GH-14526) https://github.com/python/cpython/commit/b0ab95bbe792b38e952688f8fa1657a78b35410e -- ___ Python tracker <https://bugs.python.org/issue37469> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37469] Make it explicit that logging QueueHandler / QueueListener accepts a SimpleQueue.
Vinay Sajip added the comment: New changeset e6b64b756f940147728ea7808fb686ffcae89176 by Vinay Sajip in branch 'master': bpo-37469: Document usability of SimpleQueue with QueueHandler and QueueListener. (GH-14521) https://github.com/python/cpython/commit/e6b64b756f940147728ea7808fb686ffcae89176 -- ___ Python tracker <https://bugs.python.org/issue37469> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37469] Make it explicit that logging QueueHandler / QueueListener accepts a SimpleQueue.
Change by Vinay Sajip : -- keywords: +patch pull_requests: +14335 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14521 ___ Python tracker <https://bugs.python.org/issue37469> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified
Change by Vinay Sajip : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified
Vinay Sajip added the comment: New changeset 471d785dc759eb2e9c06f077f323cf136d32506b by Vinay Sajip (Miss Islington (bot)) in branch '3.7': bpo-32934: Clarified meaning of 'capacity' for BufferingHandler and MemoryHandler. (GH-14498) (GH-14508) https://github.com/python/cpython/commit/471d785dc759eb2e9c06f077f323cf136d32506b -- ___ Python tracker <https://bugs.python.org/issue32934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified
Vinay Sajip added the comment: New changeset 3db5c5c7630af92336a8c0a269e05607cd68f9e7 by Vinay Sajip (Miss Islington (bot)) in branch '3.8': bpo-32934: Clarified meaning of 'capacity' for BufferingHandler and MemoryHandler. (GH-14498) (GH-14507) https://github.com/python/cpython/commit/3db5c5c7630af92336a8c0a269e05607cd68f9e7 -- ___ Python tracker <https://bugs.python.org/issue32934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified
Vinay Sajip added the comment: New changeset 84de34e39eb9e49b2ae691c6f67df8d7da3561de by Vinay Sajip in branch 'master': bpo-32934: Clarified meaning of 'capacity' for BufferingHandler and MemoryHandler. (GH-14498) https://github.com/python/cpython/commit/84de34e39eb9e49b2ae691c6f67df8d7da3561de -- ___ Python tracker <https://bugs.python.org/issue32934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified
Change by Vinay Sajip : -- keywords: +patch pull_requests: +14314 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14498 ___ Python tracker <https://bugs.python.org/issue32934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34556] Add --upgrade-deps to venv module
Vinay Sajip added the comment: > Is there any way other than discussing with the release manager to have this > considered? I don't believe so. -- ___ Python tracker <https://bugs.python.org/issue34556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34556] Add --upgrade to venv module
Vinay Sajip added the comment: > included with latest 3.8 or is there no chance of that? Unfortunately not, I think, as it missed the cut for 3.8beta1. Never mind! Thanks for your contribution. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue34556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34556] Add --upgrade to venv module
Vinay Sajip added the comment: Can this issue be closed now? -- ___ Python tracker <https://bugs.python.org/issue34556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified
Vinay Sajip added the comment: Python isn't a low-level language, and there isn't *in general* a particular intention "to give a bound to memory usage". When using "buffer" in a general sense, rather than a buffer object (which is more akin to a byte-array), it's usually understood to mean a Python list (used as an array) and the capacity refers to the number of elements. You may struggle to see a use case for specifying a buffer capacity as a number of elements rather than a byte size, but that doesn't mean that such use cases don't exist. Are you perhaps using MicroPython in a constrained-memory environment? In the 17 years that this code has been in Python, it's the first time AFAIK that anyone has raised the term "capacity" as potentially confusing, so I don't think such confusion is common. However, I'll be happy to update the documentation to clarify that "capacity" means "number of records buffered". -- assignee: -> vinay.sajip components: +Documentation -Library (Lib) stage: -> needs patch type: behavior -> ___ Python tracker <https://bugs.python.org/issue32934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37354] Write PowerShell Activate.ps1 to be static so it can be signed
Vinay Sajip added the comment: > It's stored in pyvenv.cfg. Is it? $ python3.8maint -m venv --prompt "foo bar" /tmp/venv $ more /tmp/venv/pyvenv.cfg home = /home/vinay/projects/python/3.8 include-system-site-packages = false version = 3.8.0 prompt = 'foo bar' The source Python location is stored, but not, from what I can see, the venv path itself ... though of course that can be worked out from $PSScriptRoot or similar. > How will this interact with EnvBuilder.install_scripts() (which explicitly > states that it performs textual substitution)? If there's nothing to substitute (because the script source has no placeholders), that won't constitute a problem, AFAIK. -- ___ Python tracker <https://bugs.python.org/issue37354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37349] venv.EnvBuilder environmental variable hooks
Vinay Sajip added the comment: > I'll take a stab at implementing this [custom_script_path] I'll certainly look at a PR for this functionality. -- ___ Python tracker <https://bugs.python.org/issue37349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28890] logging.handlers: Document that QueueListener is a daemon thread
Change by Vinay Sajip : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue28890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37349] venv.EnvBuilder environmental variable hooks
Vinay Sajip added the comment: > Is there an architecture that would be less objectionable? One thing I would consider is the ability to configure a custom_script_path in the same way as other parameters are now. It would be used as follows: If not None, it should specify a directory, and the files in there would be copied to the target venv *after* the standard scripts are copied (possibly overwriting ones already there, such as "activate"), with the same variable substitutions that are currently done. This approach allows for other things than just custom environment variable setting, and so it seems a more generic solution to the issue of customisability. While it involves the developers who require such functionality to maintain those scripts, it seems fair to place the onus on them, and not on stdlib maintainers. -- ___ Python tracker <https://bugs.python.org/issue37349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37354] Write PowerShell Activate.ps1 to be static so it can be signed
Vinay Sajip added the comment: How would you plan to replace the functionality where the venv's bin path is substituted into the script? Purely through introspecting its own path? I see that PowerShell is/will be portable to e.g. Linux environments, but I presume the security requirements you refer to are purely a Windows constraint - is that right? -- ___ Python tracker <https://bugs.python.org/issue37354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37349] venv.EnvBuilder environmental variable hooks
Vinay Sajip added the comment: > Common python libraries that make use of environmental variables I didn't say environment variables weren't commonly used. I'm talking about the specific functionality this issue is about. > Overriding setup scripts is hardly a trivial task. One has to completely > recreate the activate script to achieve the desired behavior. Not trivial, but not overly onerous either, e.g. just point to your own scripts subtree in the overridden method. Isn't your proposal to submit a different activate script? > the functionality I am requesting already exists across all shells I'm talking about the code to set, reset your custom environment variables - where is that already existent across all shells? I'm not saying what you want is unreasonable - it's just putting it into the stdlib this way that I'm not sure about. -- ___ Python tracker <https://bugs.python.org/issue37349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35185] Logger race condition - loses lines if removeHandler called from another thread while logging
Vinay Sajip added the comment: > I'd prefer correctness to be always there automatically, rather than > something the user must remember to enable by setting a flag such as > lockCallHandling Yes, I agree, I was just looking at different approaches while mulling all this over. Correctness-by-default can of course always be implemented by setting lockCallHandling to True by default, which is what I have currently in my benchmark testing. Re. your change: - self.handlers.remove(hdlr) + newhandlers = list(self.handlers) + newhandlers.remove(hdlr) + self.handlers = hdlr Did you mean self.handlers = newhandlers in that last line? That's what I assumed you meant, but you've posted that twice now, so I'm not sure what you're getting at. I agree that having a slower add/removeHandler is acceptable - certainly better than slowing down Logger.handle(). But I'm not sure about > so without relying on any GIL locking callHandlers will still see the old > list or the new list on platforms other than CPython, since we can't be sure where thread pre-emption might happen (i.e. it could happen inside a source code line boundary) and locking at least has the benefit of having defined semantics. The other issue is where someone might have subclassed and overridden add/removeHandler methods, for whatever reason. I know it's unlikely, but one never knows. I think we're broadly on the same page. I'm just not yet sure what the best approach is :-) -- ___ Python tracker <https://bugs.python.org/issue35185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37349] venv.EnvBuilder environmental variable hooks
Vinay Sajip added the comment: I'm not very keen on this approach, because it needs to be implemented across all shells and maintenance in this area can be a headache because not everyone has knowledge of multiple shells. There already are hooks for customising behaviour - you can subclass EnvBuilder and override e.g. setup_scripts to update the venv with the exact scripts you want. This puts the maintenance cost onto the people who need this functionality (it doesn't seem like a very common use case). -- ___ Python tracker <https://bugs.python.org/issue37349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35185] Logger race condition - loses lines if removeHandler called from another thread while logging
Vinay Sajip added the comment: > I'd definitely suggest we go for a solution that doesn't hit performance of > normal logging I agree, but correctness is important. I'm tending to the following: 1. Introduce a lockCallHandling module-level variable, defaulting to False to maximise logging performance (and follow current behaviour) and settable to True for situations such as your example, where adding/removing handlers from threads is wanted. 2. In Logger.handle, add an extra check for lockCallHandling to decide whether to lock/release around callHandlers(). BTW a simple benchmark of performance of locking around callHanders vs. not locking, using a FileHandler and default StreamHandler, showed an average difference of ~ 480 usec per iteration (mean time of 47.310 secs unlocked vs. 47.784 locked, for a million iterations of logger.debug() - a 1% increase). > the second idea I suggested should do that Yes, but the copying seems to make things slower, as suggested by the output of your script (in terms of the iteration counts in a fixed amount of time). -- ___ Python tracker <https://bugs.python.org/issue35185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37258] Logging cache not cleared properly when setting level
Change by Vinay Sajip : -- stage: -> resolved ___ Python tracker <https://bugs.python.org/issue37258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37258] Logging cache not cleared properly when setting level
Change by Vinay Sajip : -- stage: resolved -> ___ Python tracker <https://bugs.python.org/issue37258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29001] logging.handlers.RotatingFileHandler rotation broken under gunicorn
Vinay Sajip added the comment: Closing, as per last comment. -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue29001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35185] Logger race condition - loses lines if removeHandler called from another thread while logging
Vinay Sajip added the comment: The other alternative would be to lock around callHandlers(). With the change you propose to addHandler/removeHandler, there are no errors, but the output of your test program is (with the lock acquisition/release in place): Thread finished after 468 iterations Thread finished after 488 iterations Thread finished after 476 iterations Thread finished after 462 iterations If the lock acquisition/release is removed from addHandler/removeHandler, then there are still no errors, and the output is: Thread finished after 479 iterations Thread finished after 453 iterations Thread finished after 468 iterations Thread finished after 469 iterations If I leave addHandler/removeHandler as they were and add locking around callHandlers(), there are no errors and the output is: Thread finished after 566 iterations Thread finished after 608 iterations Thread finished after 612 iterations Thread finished after 605 iterations This seems to suggest that locking around callHandlers() is better (more performant) than the copying of handler lists involved in your suggestion. Any comments on that? Also it will work in non-GIL environments like Jython/IronPython. The callHandlers() locking will of course add a cost even for those situations where handlers aren't added and removed in multi-threading scenarios, but I haven't benchmarked it yet. It's generally not good practice to add/remove handlers willy-nilly in threads, though of course it's not forbidden (e.g. the configuration functionality allows a thread to listen for configuration changes at runtime and then reconfigure logging, which adds/removes handlers in the thread. However, loggers are disabled while the reconfiguration is in progress, and some loss of messages would be expected to be tolerable in such a case). -- ___ Python tracker <https://bugs.python.org/issue35185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28890] logging.handlers: Document that QueueListener is a daemon thread
New submission from Vinay Sajip : Why does that particularly need documenting? If it were a non-daemon thread, that might need documenting as the program would have to join() it or else seem to hang, but what does it matter if it's a daemon thread? -- ___ Python tracker <https://bugs.python.org/issue28890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36033] logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings
Vinay Sajip added the comment: Closing, as no further feedback from issue reporter. Feel free to reopen if you have a good response to my last comment. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35995] logging.handlers.SMTPHandler
Vinay Sajip added the comment: Closing, as no answer has been received to the last question. -- resolution: -> not a bug status: open -> closed ___ Python tracker <https://bugs.python.org/issue35995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37331] logging.handlers.DatagramHandler sends bad data to socketserver.DatagramRequestHandler
Change by Vinay Sajip : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37331] logging.handlers.DatagramHandler sends bad data to socketserver.DatagramRequestHandler
Vinay Sajip added the comment: New changeset d7232f0e4646803f0bbaede6e1fa124156135512 by Vinay Sajip (Miss Islington (bot)) in branch '3.8': bpo-37331: Clarify format of socket handler messages in the documentation. (GH-14234) (GH-14235) https://github.com/python/cpython/commit/d7232f0e4646803f0bbaede6e1fa124156135512 -- ___ Python tracker <https://bugs.python.org/issue37331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37331] logging.handlers.DatagramHandler sends bad data to socketserver.DatagramRequestHandler
Vinay Sajip added the comment: New changeset b64e42e931a3598d6f0605ec78673772f97ecd4c by Vinay Sajip (Miss Islington (bot)) in branch '3.7': bpo-37331: Clarify format of socket handler messages in the documentation. (GH-14234) (GH-14236) https://github.com/python/cpython/commit/b64e42e931a3598d6f0605ec78673772f97ecd4c -- ___ Python tracker <https://bugs.python.org/issue37331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36704] logging.FileHandler currently hardcodes errors='strict'
Vinay Sajip added the comment: Fixed as part of the fix for bpo-37111. -- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.9 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue36704> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Change by Vinay Sajip : -- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.8 -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37331] logging.handlers.DatagramHandler sends bad data to socketserver.DatagramRequestHandler
Vinay Sajip added the comment: New changeset f06b569305cf604f070776ea3f800ed61fdd7d61 by Vinay Sajip in branch 'master': bpo-37331: Clarify format of socket handler messages in the documentation. (GH-14234) https://github.com/python/cpython/commit/f06b569305cf604f070776ea3f800ed61fdd7d61 -- ___ Python tracker <https://bugs.python.org/issue37331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37331] logging.handlers.DatagramHandler sends bad data to socketserver.DatagramRequestHandler
Change by Vinay Sajip : -- keywords: +patch pull_requests: +14070 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14234 ___ Python tracker <https://bugs.python.org/issue37331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37331] logging.handlers.DatagramHandler sends bad data to socketserver.DatagramRequestHandler
Vinay Sajip added the comment: It is mentioned here: https://docs.python.org/3/library/logging.handlers.html?highlight=datagramhandler#logging.handlers.SocketHandler.makePickle although that doesn't go into the detail of the struct.pack format. I'll update the documentation to rectify this. -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python ___ Python tracker <https://bugs.python.org/issue37331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37258] Logging cache not cleared properly when setting level
Change by Vinay Sajip : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37258] Logging cache not cleared properly when setting level
Vinay Sajip added the comment: New changeset 95ff622028b4f5d2eefbff557eadbb08fbcd42b1 by Vinay Sajip (Miss Islington (bot)) in branch '3.8': bpo-37258: Not a bug, but added a unit test and updated documentation. (GH-14229) (GH-14230) https://github.com/python/cpython/commit/95ff622028b4f5d2eefbff557eadbb08fbcd42b1 -- ___ Python tracker <https://bugs.python.org/issue37258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37258] Logging cache not cleared properly when setting level
Vinay Sajip added the comment: New changeset 9eb4b2c8a3387ea901dad793e8d5586880a5968e by Vinay Sajip (Miss Islington (bot)) in branch '3.7': bpo-37258: Not a bug, but added a unit test and updated documentation. (GH-14229) (GH-14231) https://github.com/python/cpython/commit/9eb4b2c8a3387ea901dad793e8d5586880a5968e -- ___ Python tracker <https://bugs.python.org/issue37258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37258] Logging cache not cleared properly when setting level
Vinay Sajip added the comment: New changeset 015000165373f8db263ef5bc682f02d74e5782ac by Vinay Sajip in branch 'master': bpo-37258: Not a bug, but added a unit test and updated documentation. (GH-14229) https://github.com/python/cpython/commit/015000165373f8db263ef5bc682f02d74e5782ac -- ___ Python tracker <https://bugs.python.org/issue37258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37258] Logging cache not cleared properly when setting level
Change by Vinay Sajip : -- keywords: +patch pull_requests: +14065 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14229 ___ Python tracker <https://bugs.python.org/issue37258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37258] Logging cache not cleared properly when setting level
Vinay Sajip added the comment: This is not actually a bug, but happens because the logger is instantiated directly, rather than through logging.getLogger(...). Because of the direct instantiation, the logger cache isn't tracked via setLevel() - because the logger doesn't end up in logging.manager.loggerDict. However, I will incorporate Karthikeyan's test (modified to avoid direct instantiation), and update the documentation to strengthen the information to avoid direct instantiation of loggers. -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue37258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37111] Logging - Inconsistent behaviour when handling unicode
Change by Vinay Sajip : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 -Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue37111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37111] Logging - Inconsistent behaviour when handling unicode
Vinay Sajip added the comment: New changeset ca7b504a4d4c3a5fde1ee4607b9501c2bab6e743 by Vinay Sajip in branch 'master': bpo-37111: Add 'encoding' and 'errors' parameters to logging.basicCon… (GH-14008) https://github.com/python/cpython/commit/ca7b504a4d4c3a5fde1ee4607b9501c2bab6e743 -- ___ Python tracker <https://bugs.python.org/issue37111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37111] Logging - Inconsistent behaviour when handling unicode
Vinay Sajip added the comment: > On the other hand, couldn't we use different default error handler? "replace" or "backslashescape" seems better default error handler for the logging. I've left it as is using the same rationale as I guess open() has at the moment - "Errors should never pass silently. Unless explicitly silenced". -- ___ Python tracker <https://bugs.python.org/issue37111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37111] Logging - Inconsistent behaviour when handling unicode
Change by Vinay Sajip : -- pull_requests: +13871 pull_request: https://github.com/python/cpython/pull/14008 ___ Python tracker <https://bugs.python.org/issue37111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37111] Logging - Inconsistent behaviour when handling unicode
Change by Vinay Sajip : -- keywords: +patch pull_requests: +13798 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/13932 ___ Python tracker <https://bugs.python.org/issue37111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37111] Logging - Inconsistent behaviour when handling unicode
Vinay Sajip added the comment: Different people have different ideas of what a default should be. You can pretty much guarantee that whatever a default is, someone will think it should be something else. The basicConfig functionality has been around in its present form since 2003, and people in general haven't had a problem with the current defaults. There is no case for changing a default unless there is a consensus among lots of people that a default needs changing. -- stage: resolved -> ___ Python tracker <https://bugs.python.org/issue37111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37111] Logging - Inconsistent behaviour when handling unicode
Vinay Sajip added the comment: Learning is not a waste of time. You're entitled to your opinion, but this is not a bug in logging. We'll have to agree to disagree. -- ___ Python tracker <https://bugs.python.org/issue37111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Vinay Sajip added the comment: New changeset 56624a99a916fd27152d5b23364303acc0d707de by Vinay Sajip (Evan) in branch 'master': bpo-28595: Allow shlex whitespace_split with punctuation_chars (GH-2071) https://github.com/python/cpython/commit/56624a99a916fd27152d5b23364303acc0d707de -- ___ Python tracker <https://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37117] Simplify customization of the logging time through datefmt
Change by Vinay Sajip : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37111] Logging - Inconsistent behaviour when handling unicode
Vinay Sajip added the comment: > This seems like an attempt at victim blaming. Er, no, it was a straight question about whether you'd read the documentation. > I'm afraid this line of reasoning is suffering from selection bias, cherry > picking, confirmation bias, and probably some others too. Er, no, it was stating that lots of people have successfully used logging on Windows with utf-8, as a way of justifying my opinion that there's no deficiency here that needs addressing. > Sure "stream" is on there, but then you need to know about streams and make > the association with logging which I apparently don't. You have to remember > not everyone has your level of proficiency in the language. In fact, most > Python users don't. Sure, and that's fine. Experienced developers learn stuff every day too. But responding to issues takes time (notice how many people will have been notified about this issue from the "nosy list" above; each would have to spend at least some time looking at it), so raising issues should be done only after exhausting other resources to make sure that the problem isn't in one's own level of knowledge or understanding, but an actual problem with the software. This is why I earlier suggested Stack Overflow and python-list as useful resources for improving one's knowledge and understanding. > Lets put this another way - is there a reason NOT to have Unicode logging as > the default? I have no idea what you mean by this. As my example illustrated, it's quite easy to log Unicode in log files. A simple Internet search for "basicConfig encoding" yields for me as the second result this Stack Overflow question https://stackoverflow.com/questions/21402530 for which the accepted answer is a slight variation on what I suggested earlier. -- ___ Python tracker <https://bugs.python.org/issue37111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37117] Simplify customization of the logging time through datefmt
Vinay Sajip added the comment: > AFAIK, the converter attribute is only to "be set" with a function of such > signature. It is not documented that it can be used and it is only used on > the format time function. What do you mean by "it is not documented"? It is documented here: https://docs.python.org/3/library/logging.html#logging.Formatter.formatTime See also questions on Stack Overflow relating to it: https://stackoverflow.com/search?q=%5Bpython%5D+%5Blogging%5D+converter Not sure what you mean by "only to be set". Obviously, it is also read *somewhere* - otherwise why would you set it? > The only situation where this might break someone is if they inherit from > formatter, substitute the formatTime function by their own implementation and > rely on the function returning a time tuple. Doing that is relying on the > implementation of the formatter though, as the docs explain is just something > to be set. But the converter is documented as returning a time tuple, and there conceivably exists code that relies on that. There is no reason why someone couldn't have implemented a Formatter subclass with an overridden formatTime method that assumes the converter returns a time tuple. We can't know the impact of this change in terms of the number of people/amount of software affected, but that it might break *someone's* code is IMO enough reason not to proceed with it. > Note how you need to split the formatting of time into two different parts. It's still a one-liner both ways in your example - just a slightly different format string. Also, note that %f doesn't give you all that much flexibility - you get six places whether you like it or not. So it's hardly something which will meet everybody's formatting requirements. So "hey, just use datefmt" won't cut it for all scenarios. Ditto for timezone display - there is a school of thought that says logs should only hold UTC time. Users can always override formatTime in their Formatter subclass to do exactly what they want - it could be a one-time thing that they can then use wherever they want. I don't want to give the impression that I'm against *any* change - I'm not. You can see lots of changes in the logging codebase contributed by various people. A recent example in the area of logging Formatter is https://github.com/python/cpython/pull/9703 So by all means I welcome contributions, but you might find me a bit more conservative than you would like! -- ___ Python tracker <https://bugs.python.org/issue37117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37111] Logging - Inconsistent behaviour when handling unicode
Vinay Sajip added the comment:
> Doing something as basic as logging unicode shouldn't require knowledge of
> "handlers" - that's failing "simple is better than complex".
I reiterate my statement that it appears that you aren't sufficiently familiar
with how logging is designed to work. Logging is more complex than print() or
open() because it has to work flexibly in lots of different scenarios. Handlers
are part of this, as are Formatters and Filters.
See my 2009 blog post
https://plumberjack.blogspot.com/2009/09/python-logging-101.html
for more information for why logging is designed the way it is.
If you want to configure a stream with utf-8 encoding, without explicitly using
handlers, this is easily doable, as follows:
C:\Users\Vinay> \python37\python
Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> logging.basicConfig(stream=open(r'c:\temp\my_log.log', 'w',
>>> encoding='utf-8'))
>>> logging.error('จุด1')
>>> ^Z
and, lo and behold, the file c:\temp\my_log.log contains
ERROR:root:จุด1
The use of the stream keyword parameter is clearly documented at
https://docs.python.org/3/library/logging.html#logging.basicConfig
Did you look at the basicConfig documentation before raising this issue?
--
___
Python tracker
<https://bugs.python.org/issue37111>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37117] Simplify customization of the logging time through datefmt
Vinay Sajip added the comment: The documentation mentions that the converter attribute of the formatter should be signature-compatible with time.localtime() and time.gmtime(), and some users will have set this attribute with one or the other or a compatible function. Doesn't your change break backward compatibility by changing the signature of the converter? If one wants to implement the functionality you're suggesting, one could implement a Formatter subclass that does it, isn't that right? That wouldn't cause backward compatibility problems, and could be added in a cookbook recipe. -- ___ Python tracker <https://bugs.python.org/issue37117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37111] Logging - Inconsistent behaviour when handling unicode
Vinay Sajip added the comment: > Given that the file created by the logger is utf-8, it's unclear why it > doesn't work ... I found a workaround by using a Handler Loggers don't create files - handlers do. The file that you attached seems to be just a text file containing ASCII text. Any ASCII is also utf-8, so Notepad++'s assertion doesn't mean anything in this situation. > so that people don't get unpleasant surprises that even more painful to debug > when things only break in certain logging modes? People have been using logging, on Windows, without problems, for years, often using utf-8 to encode their log files. Perhaps you need to read the documentation and look at examples more carefully - I'm not intending to be rude, but say that because using a handler isn't some kind of workaround, and you thinking that it was indicates that you're not sufficiently familiar with the documentation. I'd suggest posting questions on Stack Overflow or the python-list mailing list, to establish whether there really seems to be a Python bug, before actually logging a Python issue. I appreciate that you're trying to improve Python. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37092] LoggerAdapter doesn't have fatal() like Logger
Vinay Sajip added the comment: FATAL and fatal() are synonyms for CRITICAL and critical(), and they are only around because of backward compatibility constraints on the Logger class at the time logging was added to Python. Because LoggerAdapter has no backward compatibility constraints, fatal() wasn't provided there - but critical() is, and can be used equivalently. Note that FATAL, fatal() are not documented as they are a legacy and not intended to be used - use CRITICAL and critical() instead. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37104] logging.Logger.disabled is not documented
Vinay Sajip added the comment: As it's not documented, people would come across it by browsing the source. I'd just mention in the source (Logger constructor) that it's for internal use, and leave it at that. -- ___ Python tracker <https://bugs.python.org/issue37104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37101] Filterer.filter can be rewritten using built-ins just as efficient much more readable
Vinay Sajip added the comment: I grant that your version is more compact, but I don't find it more readable in general (perhaps it is for very experienced Python developers/developers who like a functional style, but I persoanlly don't think it improves readability). Since the rationale proposed for making this change is "efficiency", I would like to see some real-world performance numbers to back this up. Can you please provide some quantitative data on the amount of speedup achievable in real-world scenarios? -- ___ Python tracker <https://bugs.python.org/issue37101> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37104] logging.Logger.disabled is not documented
Vinay Sajip added the comment: Thanks for looking at this, Mario, but I'd rather not document this attribute, for the reason stated on the PR when I closed it: "I'd like to avoid documenting this attribute, as it's really meant for internal use by the configuration machinery. I realise that it's named disabled rather than _disabled, which might indicate that it's public, but it isn't meant to be, and the name can't be changed now for compatibility reasons, in case some code somewhere is relying on it! I don't want someone to ask for "disabled" to be explicitly supported in configurations, for instance - I can currently argue that it's not meant to be public, as it isn't documented." -- nosy: +vinay.sajip resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22454] Adding the opposite function of shlex.split()
Vinay Sajip added the comment: New changeset ca804955927dddb6ae5a846dbc0248a932be9a4e by Vinay Sajip (Bo Bayles) in branch 'master': bpo-22454: Add shlex.join() (the opposite of shlex.split()) (GH-7605) https://github.com/python/cpython/commit/ca804955927dddb6ae5a846dbc0248a932be9a4e -- ___ Python tracker <https://bugs.python.org/issue22454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler cannot represent streams with an integer as name
Change by Vinay Sajip : -- resolution: not a bug -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler cannot represent streams with an integer as name
Vinay Sajip added the comment: New changeset 78dd781ef4d41dfefad53aa3bc52c39b0d443b19 by Vinay Sajip (Miss Islington (bot)) in branch '3.7': bpo-36015: Handle StreamHandler representaton of stream with an integer name (GH-11908) (GH-13183) https://github.com/python/cpython/commit/78dd781ef4d41dfefad53aa3bc52c39b0d443b19 -- ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler cannot represent streams with an integer as name
Vinay Sajip added the comment: New changeset ca87eebb22d202c33f3317cbf85059cadc64fa9f by Vinay Sajip (Riccardo Magliocchetti) in branch 'master': bpo-36015: Handle StreamHandler representaton of stream with an integer name (GH-11908) https://github.com/python/cpython/commit/ca87eebb22d202c33f3317cbf85059cadc64fa9f -- ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33456] site.py: by default, a virtual environment is *not* isolated from the system-level site-packages directories
Change by Vinay Sajip : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33456> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33456] site.py: by default, a virtual environment is *not* isolated from the system-level site-packages directories
Vinay Sajip added the comment: New changeset c324c748871804f31f56b3bd02a8650b3bf1bae7 by Vinay Sajip (Lukas Waymann) in branch 'master': bpo-33456: site module documentation - fix wrong default for key in pyvenv.cfg (GH-6755) https://github.com/python/cpython/commit/c324c748871804f31f56b3bd02a8650b3bf1bae7 -- ___ Python tracker <https://bugs.python.org/issue33456> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35726] QueueHandler formatting affects other handlers
Vinay Sajip added the comment: New changeset 2dad96013ca24abdc5ba5a369ea42d70ff02487a by Vinay Sajip (Xtreak) in branch 'master': bpo-35726: Add test for QueueHandler with multiple handlers (GH-11659) https://github.com/python/cpython/commit/2dad96013ca24abdc5ba5a369ea42d70ff02487a -- ___ Python tracker <https://bugs.python.org/issue35726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35726] QueueHandler formatting affects other handlers
Change by Vinay Sajip : -- pull_requests: -11458 ___ Python tracker <https://bugs.python.org/issue35726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35726] QueueHandler formatting affects other handlers
Change by Vinay Sajip : -- pull_requests: -11459 ___ Python tracker <https://bugs.python.org/issue35726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35726] QueueHandler formatting affects other handlers
Change by Vinay Sajip : -- pull_requests: -11460 ___ Python tracker <https://bugs.python.org/issue35726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36532] Example of logging.formatter with new str.format style
Vinay Sajip added the comment: But there is an example in the cookbook already: https://docs.python.org/3/howto/logging-cookbook.html#use-of-alternative-formatting-styles It's right there in the first code sample in that section. You might want to amend your change to point to this section from the one where you want to make the change. -- ___ Python tracker <https://bugs.python.org/issue36532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig
Vinay Sajip added the comment: > If the `disabled` attribute should not be part of the public API it should > have been name `_disabled`. A bit late for that now, and AFAIK it hasn't caused people insuperable problems heretofore - the code has been like this pretty much since the logging package was added to Python. > So it should be doable from `logging.config.dictConfig` too in my opinion. Let's just agree to disagree on this for now. It's certainly not a common use case, there are other ways to achieve the desired result in those uncommon cases, and the argument seems to come back to "consistency". I'd rather leave this as it is. -- ___ Python tracker <https://bugs.python.org/issue36318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig
Vinay Sajip added the comment: > Actually people do this all the time, to deactivate the logging of some > third-party libraries (me included). It would be better to set the level of those loggers to e.g. ERROR or CRITICAL rather than disabling them altogether - presumably if something bad happens in those packages, one would want to know! > In addition, all public attributes ... can be set from > `logging.config.dictConfig`, except the `disabled` attribute, which is > inconsistent. I don't especially want people to use `disabled` for this type of thing - the main reason for having it is that following an on-the-fly reconfiguration in a long-running process, some threads might still be active that contain references to now-unwanted loggers, and disabling makes those references inactive without the need to track them down. I would recommend using e.g. CRITICAL as a level for the use case you mention. -- ___ Python tracker <https://bugs.python.org/issue36318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36272] Recursive logging crashes Interpreter in Python 3
Change by Vinay Sajip : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.6 ___ Python tracker <https://bugs.python.org/issue36272> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36272] Recursive logging crashes Interpreter in Python 3
Vinay Sajip added the comment: New changeset 6a7a9f1d83cef628d2bacd71ee568b93f53fd6b4 by Vinay Sajip (Miss Islington (bot)) in branch '3.7': bpo-36272: Logging now propagates RecursionError (GH-12312) (GH-12391) https://github.com/python/cpython/commit/6a7a9f1d83cef628d2bacd71ee568b93f53fd6b4 -- ___ Python tracker <https://bugs.python.org/issue36272> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36318] Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig
Vinay Sajip added the comment: I don't see any value in configuring a logger which starts as disabled - making it completely useless - why would one want to do this? I don't think the "consistency" argument flies in this case. -- ___ Python tracker <https://bugs.python.org/issue36318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36272] Recursive logging crashes Interpreter in Python 3
Vinay Sajip added the comment: New changeset 65f64b1903ae85b97a30f514bbc1b7ce940c3af2 by Vinay Sajip (Rémi Lapeyre) in branch 'master': bpo-36272: Logging now propagates RecursionError (GH-12312) https://github.com/python/cpython/commit/65f64b1903ae85b97a30f514bbc1b7ce940c3af2 -- ___ Python tracker <https://bugs.python.org/issue36272> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler cannot represent streams with an integer as name
Vinay Sajip added the comment: Sorry, Riccardo, been very busy lately and not had time to look at it :-( Soon, I hope. -- ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36193] Redirected stderr not reset properly when using logging
Vinay Sajip added the comment: The StreamHandler allows you to specify *exactly* which stream you want to use to log to; sys.stderr is provided as a convenient default argument because that's what a lot of people want a lot of the time. This is typically done at logging configuration time, or whenever a StreamHandler is created. This is done implicitly by your logging.warning() call (as documented, this calls logging.basicConfig(), which adds a StreamHandler using whatever sys.stderr is set to at the time the StreamHandler is instantiated). Also documented is that basicConfig() is only effective once (it will not do anything if a handler has already been added to the root logger - it is only meant to be use for simple one-off scripts). The documentation for basicConfig() is clear: "Does basic configuration for the logging system by creating a StreamHandler with a default Formatter and adding it to the root logger. The functions debug(), info(), warning(), error() and critical() will call basicConfig() automatically if no handlers are defined for the root logger. This function does nothing if the root logger already has handlers configured for it." If you want to use the real console streams, don't use logging.warning(), but instead explicitly call basicConfig() using __stderr__, as Peter says. Alternatively, use the approach suggested in the cookbook for context-sensitive logging: https://docs.python.org/3/howto/logging-cookbook.html#using-a-context-manager-for-selective-logging Closing, as this is not a bug in logging. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35995] logging.handlers.SMTPHandler
Vinay Sajip added the comment: The existing implementation supports doing an SSL handshake using STARTTLS, which provides encryption for the actual email traffic. You are asking, it seems, to support a server that only listens on an already encrypted connection, and doesn't use STARTTLS. That would, in my book, be an *enhancement request* and not a bug. Your PR has removed the STARTTLS support - what is supposed to happen when connecting to a server that listens unencrypted and expects to use STARTTLS to initiate encypted traffic? -- ___ Python tracker <https://bugs.python.org/issue35995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36033] logging.makeLogRecord should update "rv" using a dict defined with bytes instead of strings
Vinay Sajip added the comment: If the arguments are retrieved from a byte source, why can't they be converted to strings before passing to logging? This may be an issue for OpenStack. It's not logging's job to convert bytes passed to APIs that expect strings. -- ___ Python tracker <https://bugs.python.org/issue36033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler cannot represent streams with an integer as name
Change by Vinay Sajip : -- title: streamhandler canont represent streams with an integer as name -> streamhandler cannot represent streams with an integer as name ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler canont represent streams with an integer as name
Vinay Sajip added the comment: > That is, when opening a file descriptor the name is set to the value of that > file descriptor as an integer. I see. But I wonder if there is anything that relies on the name being an integer? It seems pretty counter-intuitive for a 'name' attribute to be set to something other than a string. -- ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36015] streamhandler canont represent streams with an integer as name
Vinay Sajip added the comment: I'm not sure this is a problem with logging. The code immediately preceding the failure is: name = getattr(self.stream, 'name', '') if name: name += ' ' So, the failure occurs because the stream has a name attribute which is not a string. Even if sys.stderr itself is an unbuffered file, why is its 'name' attribute not a string? I don't imagine the name would be actually used for I/O, and having it set to an integer is a surprise. I propose to close this (and the associated PR) unless a good reason is given why we have to support non-string names here. -- resolution: -> not a bug status: open -> pending ___ Python tracker <https://bugs.python.org/issue36015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35821] Clarify when logging events are propagated when propagate is true
Vinay Sajip added the comment:
> I'm not sure which part of what I wrote you think is inaccurate.
It's just that language can be tricky. When you said "pass to the parent
logger" this might be misconstrued as some kind of call to a method of the
parent logger.
Your OP says that you think "logged to this logger" means (2), but actually it
means (1). Expanding with examples:
If the propagate attribute of the logger named A.B.C evaluates to true, any
event logged to A.B.C via a method call such as
logging.getLogger('A.B.C').error(...) will [subject to passing that logger's
level and filter settings] be passed in turn to any handlers attached to
loggers named A.B, A and the root logger, after first being passed to any
handlers attached to A.B.C. If any logger in the chain A.B.C, A.B, A has its
propagate attribute set to false, then that is the last logger whose handlers
are offered the event to handle, and propagation stops at that point.
--
___
Python tracker
<https://bugs.python.org/issue35821>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35821] Clarify when logging events are propagated when propagate is true
Vinay Sajip added the comment: That isn't quite accurate. A logger's attached handlers will always be offered a chance to handle an event if the logger's level and filters allow. However, the event is not actually passed to ancestor loggers - it is directly offered to any handlers attached to ancestor loggers, until a logger is encountered where propagate is false - and that is the last logger whose handlers are offered the event. All handlers have their own levels and filters and may or may not process an event according to those levels and filters. -- ___ Python tracker <https://bugs.python.org/issue35821> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
