Vinay Sajip added the comment:
I believe the information is clear from this link in the documentation:
https://docs.python.org/3/howto/logging.html#logging-flow
However, if you can suggest alternative wording which you think is clearer,
I'll certainly take a look at it. Perhaps a link
Change by Vinay Sajip :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Vinay Sajip added the comment:
New changeset 3be19c082b7f0ba3cf6c28922d3577126871788e by Vinay Sajip (Miss
Islington (bot)) in branch '3.7':
bpo-35781: Changed references to deprecated 'warn' method in logging
documentation in favour of 'warning' (GH-11654)
Change by Vinay Sajip :
--
pull_requests: -11453
___
Python tracker
<https://bugs.python.org/issue35781>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vinay Sajip added the comment:
New changeset cda73a5af2ff064ca82140342b3158851d43868f by Vinay Sajip
(yuji38kwmt) in branch 'master':
bpo-35781: Changed references to deprecated 'warn' method in logging
documentation in favour of 'warning' (GH-11654)
https://gi
Change by Vinay Sajip :
--
pull_requests: -11452
___
Python tracker
<https://bugs.python.org/issue35781>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Vinay Sajip :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Vinay Sajip :
--
pull_requests: -11450
___
Python tracker
<https://bugs.python.org/issue35722>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Vinay Sajip :
--
pull_requests: -11449
___
Python tracker
<https://bugs.python.org/issue35722>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Vinay Sajip :
--
pull_requests: -11447
___
Python tracker
<https://bugs.python.org/issue35722>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vinay Sajip added the comment:
New changeset 552478bb1086ef371e4f1da0b430b90eba4785d5 by Vinay Sajip (Miss
Islington (bot)) in branch '3.7':
bpo-35722: Updated the documentation for the 'disable_existing_loggers'
parameter (GH-11525) (GH-11655)
https://github.com/p
Change by Vinay Sajip :
--
pull_requests: -11446
___
Python tracker
<https://bugs.python.org/issue35722>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Vinay Sajip :
--
pull_requests: -11443
___
Python tracker
<https://bugs.python.org/issue35781>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Vinay Sajip :
--
pull_requests: -11444
___
Python tracker
<https://bugs.python.org/issue35781>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vinay Sajip added the comment:
New changeset f0c743604fc841d35a48822b936ef2e5919e43c1 by Vinay Sajip (Géry
Ogam) in branch 'master':
bpo-35722: Updated the documentation for the 'disable_existing_loggers'
parameter (GH-11525)
https://github.com/p
Vinay Sajip added the comment:
Merged for 3.8, will add backport labels to PR in due course.
--
title: QueueHandler formating affects other handlers -> QueueHandler formatting
affects other handlers
___
Python tracker
<https://bugs.pyth
Vinay Sajip added the comment:
New changeset da6424e96ada72c15c91bddb0a411acf7119e10a by Vinay Sajip
(Manjusaka) in branch 'master':
bpo-35726: Prevented QueueHandler formatting from affecting other handlers
(GH-11537)
https://github.com/python/cpyt
Vinay Sajip added the comment:
Any idea why the same PR appears three times in the PR list? Is it because for
some reason you've added the issue link multiple times in the PR, when it's not
needed?
--
___
Python tracker
<https://bu
Change by Vinay Sajip :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue35530>
___
___
Vinay Sajip added the comment:
Duplicate of bpo-35328, which has a PR.
--
nosy: +vinay.sajip
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Vinay Sajip added the comment:
I don't believe there is enough value in this to do it. From PEP 8:
"Some other good reasons to ignore a particular guideline:
...
Because the code in question predates the introduction of the guideline and
there is no other reason to be modifying
Vinay Sajip added the comment:
See also bpo-35558.
--
___
Python tracker
<https://bugs.python.org/issue32409>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vinay Sajip added the comment:
This seems related to bpo-32409.
--
___
Python tracker
<https://bugs.python.org/issue35558>
___
___
Python-bugs-list mailin
Vinay Sajip added the comment:
> If this behaviour can't be changed for backwards compatibility reasons, then
> so be it.
It can't be changed for this reason.
> But I think it would be disingenuous to claim it's not a design flaw.
Do you think *I'm* being dis
Change by Vinay Sajip :
--
nosy: +BNMetrics
versions: +Python 3.6 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue35509>
___
___
Python-bugs-list m
Change by Vinay Sajip :
--
resolution: fixed ->
stage: resolved -> patch review
status: closed -> open
___
Python tracker
<https://bugs.python.or
Vinay Sajip added the comment:
Fixed, see bpo-32409 for commit information.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: -Python 3.6
___
Python tracker
<https://bugs.python.or
Vinay Sajip added the comment:
New changeset 881e273c795f2f5154b8afebfa299f0e830f3712 by Vinay Sajip (Miss
Islington (bot)) in branch '3.7':
bpo-32409: Fix regression in activate.bat on international Windows (GH-10295)
(GH-10377)
https://github.com/python/cpyt
Vinay Sajip added the comment:
New changeset c64583b6d3e8516a8cd2b5f84fc1e300bfac2206 by Vinay Sajip
(samstagern) in branch 'master':
bpo-32409: Fix regression in activate.bat on international Windows (GH-10295)
https://github.com/python/cpyt
Vinay Sajip added the comment:
> a better run time error message which clarifies that shlex.punctuation_chars
> is read-only
That it can be set only via the __init__(), yes.
--
___
Python tracker
<https://bugs.python.org/i
Vinay Sajip added the comment:
I agree that it's inconsistent, but quite a bit of setting up is done when
punctuation_chars is provided, as per the link in msg329312. One could convert
the attribute to a property and have a setter that does the equivalent set up,
but some of the set
Vinay Sajip added the comment:
So - are you saying that chcp prints "850." when asked for the current code
page but won't accept "850." when setting the code page, requiring just "850"?
--
___
Python tracker
Change by Vinay Sajip :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Vinay Sajip added the comment:
New changeset d730719b094cb006711b1cd546927b863c173b31 by Vinay Sajip (Miss
Islington (bot)) in branch '3.7':
bpo-35046: do only one system call per line (logging.StreamHandler) (GH-10042)
(GH-10050)
https://github.com/python/cpyt
Vinay Sajip added the comment:
New changeset b7d62050e7d5fc208ae7673613da4f1f2bc565c4 by Vinay Sajip (Josh
Snyder) in branch 'master':
bpo-35046: do only one system call per line (logging.StreamHandler) (GH-10042)
https://github.com/python/cpyt
Change by Vinay Sajip :
--
pull_requests: +9382
___
Python tracker
<https://bugs.python.org/issue35046>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vinay Sajip added the comment:
Documentation for 3.6/3.7/3.8 updated. 3.5 is out of scope for this.
--
nosy: +vinay.sajip
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bug
Change by Vinay Sajip :
--
keywords: +patch
pull_requests: +9296
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32789>
___
___
Py
Vinay Sajip added the comment:
Closing as per Serhiy's advice - assume that's OK.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs
Vinay Sajip added the comment:
Loggers are singletons, so the pickling operation just pickles the name.
Unpickling just leads to getting the pickled name and calling getLogger(name),
which will return the same object that was pickled (I'd forgotten about
issue30520).
I suggest
Vinay Sajip added the comment:
This doesn't appear to be inherently a logging problem - it seems to be a
change in how copy.copy() is working. If you update mocked_log to insert some
statements showing the id of the loggers involved in the copy:
def mocked_log(log_level):
# Ret
Vinay Sajip added the comment:
Unfortunately, setting the default value of validate to False would completely
negate the usefulness of the feature, because it would rely on people coming to
know about it and remembering to turn it on. Given that this feature is adding
error checking, and
Vinay Sajip added the comment:
Closing, as no specific proposals received.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Vinay Sajip :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Vinay Sajip added the comment:
New changeset 18fb1fb943b7dbd7f8a76017ee2a67ef13effb85 by Vinay Sajip
(BNMetrics) in branch 'master':
bpo-34844: logging.Formatter enhancement - Ensure style and format string
matches in logging.Formatter (GH-9703)
https://github.com/python/cpyt
Vinay Sajip added the comment:
I see a PR has been added, I'll start to review it after the CLA has been
signed.
--
___
Python tracker
<https://bugs.python.org/is
Vinay Sajip added the comment:
> Checking fmt to match the style in the constructor of logging.Formatter
This seems a reasonable change to want to make. You would need to parse the
format string for fields using the appropriate style. This should probably be
via a validate() method in e
Vinay Sajip added the comment:
It's not Gunicorn-specific - more a case of multiple processes writing to a
single log file. This is not supported directly, as documented here:
https://docs.python.org/3/howto/logging-cookbook.html#logging-to-a-single-file-from-multiple-processes
A
Vinay Sajip added the comment:
New changeset d345bb4d9b6e16c681cd8a4e1fff94ecd6b0bb09 by Vinay Sajip (Cheryl
Sabella) in branch 'master':
bpo-34334: Don't log traceback twice in QueueHandler (GH-9537)
https://github.com/python/cpython/commit/d345bb4d9b6e16c681cd8a4e1
Change by Vinay Sajip :
--
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue34334>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vinay Sajip added the comment:
> I'm wondering if there should be a change to `format()` to add an else
There's no need; the field is initialised to None in the LogRecord constructor
and then only set later if there is a traceback to be cached.
> I think the cutoff for 3.7
Vinay Sajip added the comment:
Having looked at it again, Adrian Dries might be right that setting exc_text to
None will also do the trick, and perhaps in a better way. The reasoning:
Handler.format() formats record.msg % record.args, and caches it in
record.message. If there is exception
Vinay Sajip added the comment:
As I said in msg284106, it seems that the __PYVENV_LAUNCHER__ should be removed
from the stub launcher and then tests should confirm that framework builds
aren't adversely affected. Unfortunately, I can't do this testing as I don't
have a Mac
Vinay Sajip added the comment:
> Should I make use of a single logger object in my library, multiple loggers
> in a tree, or multiple unrelated loggers? Since I have just one public module,
> I'm tempted to say that I should just use one logger object.
Yes. The advanced logging
Vinay Sajip added the comment:
Possibly a test needs to be added for this, as it appears to be a regression
that went unnoticed.
--
___
Python tracker
<https://bugs.python.org/issue34
Vinay Sajip added the comment:
> Patching QueueHandler.prepare() to set exc_text to None seems to fix this.
I'm not sure that's the right fix. The change appears to have come from this
commit:
https://github.com/python/cpython/commit/adfe3440f65dfd6cf4463db6cd02cdc78e77ce17
Change by Vinay Sajip :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: -Python 2.7
___
Python tracker
<https://bugs.python.or
Vinay Sajip added the comment:
New changeset 2e4ae8f1b3147d7f0a461b4ffdde9bcc9e6a2083 by Vinay Sajip (Miss
Islington (bot)) in branch '3.7':
bpo-34415: Updated logging.Formatter docstring. (GH-8811) (GH-8817)
https://github.com/python/cpython/commit/2e4ae8f1b3147d7f0a461b4ffdde9b
Vinay Sajip added the comment:
New changeset fed871835ee54f50cabcec6239271739ed4839f5 by Vinay Sajip (Miss
Islington (bot)) in branch '3.6':
bpo-34415: Updated logging.Formatter docstring. (GH-8811) (GH-8816)
https://github.com/python/cpython/commit/fed871835ee54f50cabcec62392717
Vinay Sajip added the comment:
New changeset d3d3171da895d8cb880f23fae6be778f0ac23be7 by Vinay Sajip in branch
'master':
bpo-34415: Updated logging.Formatter docstring. (GH-8811)
https://github.com/python/cpython/commit/d3d3171da895d8cb880f23fae6be77
Change by Vinay Sajip :
--
keywords: +patch, patch
pull_requests: +8288, 8289
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Vinay Sajip :
--
keywords: +patch
pull_requests: +8288
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34415>
___
___
Py
Vinay Sajip added the comment:
There aren't any changes planned to the fileConfig code, other than bug fixes.
If you need improved functionality, you can use dictConfig, which already
supports improved configuration features when compared to fileConfig.
The fileConfig API was present
Vinay Sajip added the comment:
The full module name isn't readily available. The value that sets the
LogRecord's pathname attribute [which is obtained from the Python code object
for the caller] is used to derive the filename attribute (by taking the
basename of the pathnam
Vinay Sajip added the comment:
Closing, as no response received.
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Vinay Sajip added the comment:
Closing this as rejected, as when using the recommended approach for naming
loggers, you get the full package name which can be output in logs.
--
resolution: -> rejected
stage: -> resolved
status: open -&g
Vinay Sajip added the comment:
The logging module-level convenience functions are specifically there for the
use of casual, short scripts where users don't want to be concerned with the
details of loggers and handlers.
Even if you accidentally configure logging in library code becaus
Vinay Sajip added the comment:
> I expected it to be a "dummy" handler that might accept any argument
I don't know why you expected that, but your expectation wasn't valid. You will
need to define your own BaseHandler which handles any arguments passed by your
Change by Vinay Sajip :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<https://bugs.python
Vinay Sajip added the comment:
> But, seems like one has no public api to reinitialize logging to a like-fresh
> state
For the use case of testing, you could use a context manager approach as
described here in the logging cookbook:
https://docs.python.org/3/howto/logging-cookboo
Vinay Sajip added the comment:
If you use the recommended approach of using
logger = logging.getLogger(__name__),
then the logger's name (the name field in the LogRecord) will be the full
module path.
--
___
Python tracker
&
Vinay Sajip added the comment:
Well, loggerDict is an internal implementation detail which shouldn't be
directly called by the code in borgbackup. Hence I'm not sure you can call it a
bug. When messing around with internals of objects, caveats apply.
Note that loggerDict isn'
Vinay Sajip added the comment:
What is your use case?
--
___
Python tracker
<https://bugs.python.org/issue34244>
___
___
Python-bugs-list mailing list
Unsub
Vinay Sajip added the comment:
New changeset 94487d45707772723ef19e86700a40a12743baa1 by Vinay Sajip in branch
'master':
bpo-34011: Update code copying DLLs and init.tcl into venvs. (GH-8253)
https://github.com/python/cpython/commit/94487d45707772723ef19e86700a40
Vinay Sajip added the comment:
This behaviour is as expected. If no handlers are configured for logging, an
internal "handler of last resort" is used, with just the message output. See:
https://docs.python.org/3/howto/logging.html#what-happens-if-no-configuration-is-provided
I
Vinay Sajip added the comment:
> Here's some evidence that this is true
I'm not sure that's evidence. That example page you linked to has 4 instances
of handleError: 2 are definitions of overrides, and the other two are calls to
the superclass method from those overrid
Vinay Sajip added the comment:
For the crash to occur, it would have to be a handleError() called wrongly,
when something didn't apparently go wrong (i.e. a call from outside an
exception handling clause). So I'm not sure I follow your logic.
I agree the change you propose is s
Vinay Sajip added the comment:
See the comments on bpo-31853. I agree with the consensus there that these
changes aren't worth doing:
msg314518
msg314520
msg314521
So, I propose to close this as "not a bug" which in this context means "not an
enhancemen
Change by Vinay Sajip :
--
keywords: +patch
pull_requests: +7785
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Vinay Sajip added the comment:
It seems innocuous enough, but the documentation for handleError() does say:
"This method should be called from handlers when an exception is encountered
during an emit() call."
That documentation is the same for 2.x and 3.x. This is not how you are
Change by Vinay Sajip :
--
versions: -Python 3.4, Python 3.5
___
Python tracker
<https://bugs.python.org/issue34086>
___
___
Python-bugs-list mailing list
Unsub
Vinay Sajip added the comment:
Hmmm. I managed to find a machine to install Python3.3.0 on, and it appears
that even with that copy suite removed, the tests still work. So possibly it's
something that changed between 3.3.0 alpha and 3.3.0 final.
I can try removing the copy code for 3.
Vinay Sajip added the comment:
The code that does the copy is the original PEP 405 implementation code (from
26 May 2012). I'm fairly sure that these files were copied over only because
(at least prior to the Python 3.3 release in September 2012) they were needed
to be in the venv fo
Vinay Sajip added the comment:
> The first thing people do is set the format to
> '%(asctime)s:%(levelname)s:%(name)s:%(message)s' or like after importing
> logging module.
"People" - you don't claim to speak for *everyone*, right?
basicConfig() takes a
Change by Vinay Sajip :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.or
Vinay Sajip added the comment:
New changeset b6c1989168efeb8b6320bec958e7e339270ac0ce by Vinay Sajip (Xtreak)
in branch '3.6':
[3.6] bpo-33978: Close existing handlers before logging (re-)configuration.
(GH-8008). (GH-8045)
https://github.com/python/cpyt
Vinay Sajip added the comment:
New changeset 6f49afc3d983350f4f04d221a26573721f23c475 by Vinay Sajip (Miss
Islington (bot)) in branch '3.7':
bpo-33978: Close existing handlers before logging (re-)configuration. (GH-8008)
(GH-8044)
https://github.com/python/cpyt
Vinay Sajip added the comment:
New changeset 087570af6d5d39b51bdd5e660a53903960e58678 by Vinay Sajip (Xtreak)
in branch 'master':
bpo-33978: Close existing handlers before logging (re-)configuration. (GH-8008)
https://github.com/python/cpython/commit/087570af6d5d39b51bdd5e660a5390
Change by Vinay Sajip :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Vinay Sajip added the comment:
New changeset cf67d6a934b51b1f97e72945b596477b271f70b8 by Vinay Sajip (Dong-hee
Na) in branch 'master':
bpo-33897: Add a 'force' keyword argument to logging.basicConfig(). (GH-7873)
https://github.com/p
Vinay Sajip added the comment:
OK, let's go with "force", then. There are plenty of other places in Python
where it's used, so there's that:
https://github.com/python/cpython/search?l=Python&q=force
--
___
Python trac
Vinay Sajip added the comment:
> Perhaps "clear_handlers" or "replace_handlers" would be more self-descriptive.
Except that it doesn't *just* clear the handlers - the act of clearing also
lets e.g. the level to be set and the form
Vinay Sajip added the comment:
You would just clear all handlers added to the root logger before calling the
existing code:
try:
# new code to be added, not tested
for h in root.handlers[:]:
root.removeHandler(h)
h.close()
# existing code
Vinay Sajip added the comment:
I'm closing this, as it's not a bug in the venv module.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs
Vinay Sajip added the comment:
This should be addressed by the fix for bpo-33165 - addition of a stacklevel
parameter to the logging APIs.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracke
Vinay Sajip added the comment:
You can't make the proposed change (removing call to basicConfig() from
logging.debug() etc.) without breaking backwards compatibility.
The inconsistency is just a consequence of how you choose to mix and match
calls to the module-level convenience func
Change by Vinay Sajip :
--
nosy: +vinay.sajip
___
Python tracker
<https://bugs.python.org/issue33802>
___
___
Python-bugs-list mailing list
Unsubscribe:
Vinay Sajip added the comment:
I'm +0 on the idea.
--
___
Python tracker
<https://bugs.python.org/issue22454>
___
___
Python-bugs-list mailing list
Unsubscr
Vinay Sajip added the comment:
I'm closing this, please reopen if you have more information which might change
my view.
--
resolution: -> not a bug
stage: patch review -> resolved
status: open -> closed
___
Python t
Change by Vinay Sajip :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
501 - 600 of 2033 matches
Mail list logo
