Vinay Sajip added the comment:
As an extra data point, note the behaviour on Windows:
C:\Users\Vinay> \python34\python -m venv "\Temp
Vinay Sajip added the comment:
Thanks. It's worth checking what shebang was written to a script that was
installed into the venv - e.g. cherryd.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Vinay Sajip added the comment:
To reiterate Alex Regueiro's point, I don't think this is a bug, but a
shortcoming of the underlying Berkeley exec(2) implementation. See this post:
https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html
We can leave the implementation
Vinay Sajip added the comment:
I'm not sure if msg230947 is still correct, and it seems neater to remove
__PYVENV_LAUNCHER__ from where it's defined in the first place (the stub
launcher C file) if it was just a shim needed around the time the functionality
was developed (pre the 3.3 release
Vinay Sajip added the comment:
Perhaps I will try to make it even clearer, but to be fair, the format()
documentation is just a few paragraphs above the formatException()
documentation. It's all in the section entitled "Formatter Objects", and it's
IMO reasonable to expect
Vinay Sajip added the comment:
This sounds like a Celery bug, so I don't propose to change anything in this
area.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29056>
___
_
Vinay Sajip added the comment:
I don't consider this a bug, as the logging documentation for the
Handler.format() method states:
"Note that the formatted exception information is cached in attribute exc_text.
This is useful because the exception information can be pickled and sent a
Vinay Sajip added the comment:
I'm not sure this issue tracker is the best place to have an extended
discussion about documentation - perhaps we should move this to a mailing list
such as python-list.
I'm not sure what you read first, but the logging documentation main page has a
box marked
Vinay Sajip added the comment:
> The use case I've found is that I often have logging enabled while writing
> code, and then want to shut it off once I've finished.
You could do this by having a configuration which is quite verbose while doing
development and then less verbos
Vinay Sajip added the comment:
s/leaving the details/leaving the more narrative aspects/
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Vinay Sajip added the comment:
The current documentation makes it very simple for naive users, with the main
section being a reference and leaving the details to the basic and advanced
tutorials and the cookbook. This was deliberately done in response to earlier
feedback
Vinay Sajip added the comment:
Those signatures have **kwargs for potential extension of the logging API
itself (without extending the existing argument list), not for passing
arguments to filters.
You can already filter completely flexibly by passing additional values in the
"
Vinay Sajip added the comment:
> So I think it must be a Fluentd error.
So I'll close this.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Vinay Sajip added the comment:
Patch as posted will not work (contains a syntax error), and was thus never
tested. Never mind, I will address this soon.
--
assignee: -> vinay.sajip
___
Python tracker <rep...@bugs.python.org>
<http://bug
Vinay Sajip added the comment:
This is marked as relevant to Python 3.7, so I ran a test script using the
latest Python sources:
import logging
import logging.config
import sys
def main():
config = {
'version': 1,
'formatters': {
'default
Vinay Sajip added the comment:
Updated patch to cover tests, and changed the implementation slightly. Tests
pass on Linux and Windows (I'm not able to build on OS X). The patch is against
the default branch but the diff should apply equally well to 3.6.
--
Added file: http
Vinay Sajip added the comment:
> This bug is clearly not a security issue.
I'm not sure it's all that clear - the bug could cause a crash (observed in
practice - not theoretical), which perhaps could be exploited. See Steve
Dower's message msg272008 in this thread. That's why I ad
Vinay Sajip added the comment:
> Ok, so we need to figure out whether the tests are wrong, or the 'fix' is
> wrong.
The tests were never updated, so most likely they will need changing. I was
waiting for feedback about my point about _CONFIG_VARS['srcdir'], but I never
got any at th
Vinay Sajip added the comment:
> Can this ticket be closed?
I suppose so - I didn't implement the addition of lookup_eval() to the ast
module as I thought it might be a slight overkill. Given that the calls to
eval() from fileConfig() have been there from when logging was added to the
std
Vinay Sajip added the comment:
Removed 3.3 and 3.4 as they are not in scope for non-security issues.
--
versions: -Python 3.3, Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Vinay Sajip added the comment:
As this is an (admittedly small) change in behaviour, I'll apply in 3.6.
--
versions: +Python 3.6 -Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Vinay Sajip added the comment:
The existing docs have a section "These constants are GNU extensions and not
present if they are not defined by the C library."
There could be a corresponding section for BSD extensions to which O_EXLOCK and
O_SHLOCK are moved, or the word "GNU&qu
Vinay Sajip added the comment:
It's not *only* used in test - it's also used in third party libraries. For
example, it's used in distlib (which is vendored by pip) to determine whether
it's being run from a source build.
--
nosy: +vinay.sajip
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
nosy: -vinay.sajip
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue19504>
___
Vinay Sajip added the comment:
The thing about queues does not relate just to logging - it relates to all
communication between different multiprocessing processes, of which logging is
just an example. The logging cookbook is not the place to provide tutorial
information on e.g. multi
Vinay Sajip added the comment:
> Since a queue isn't necessary for logging with multiprocessing
IMO a queue with QueueHandler/QueueListener is best practice when working with
multiprocessing and logging. If you don't use them, things may seem to work
some of the time but could fail in cert
Vinay Sajip added the comment:
I specifically wanted to illustrate a separate listener process - the purpose
here is not to show what might be the most efficient code, but to show
communication via a queue between listener process and worker processes. You've
removed this, which defeats
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
assignee: vinay.sajip ->
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
priority: release blocker -> normal
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Vinay Sajip added the comment:
Mean culpa - I have jumped the gun on this. Sorry to all for the
inconvenience. I have just got back after being away for a few days, and will
revert the change shortly, if no one beats me to it.
--
___
Python
Vinay Sajip added the comment:
*Mea culpa. Autocorrect :-(
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12713>
___
___
Pyth
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
stage: -> resolved
status: pending -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Vinay Sajip added the comment:
You don't need a subclass - you can specify your own function to do it, as in
the cookbook example:
https://docs.python.org/3/howto/logging-cookbook.html#using-a-rotator-and-namer-to-customize-log-rotation-processing
Vinay Sajip added the comment:
Could you point to some suitable projects from GitHub whose tarballs fail on
3.5 / 3.6? My script in the first post, with the replacing of "unicode(...)"
with "str(...)" and my original failing archive, works on Python 3.5 and 3.6 on
Linux.
Vinay Sajip added the comment:
Updated the last patch with code for handling the case where ld is not
available.
--
Added file: http://bugs.python.org/file44052/refresh-2016-08-08.diff
___
Python tracker <rep...@bugs.python.org>
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
Added file: http://bugs.python.org/file44036/refresh-2016-08-07.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Vinay Sajip added the comment:
IMO it's not really worth adding tests for __repr__() - because no external
code should depend on the exact representation of instances of these kinds of
classes.
--
___
Python tracker <rep...@bugs.python.org>
Vinay Sajip added the comment:
I will close this as not a bug. If you have custom signal handling which
interacts with logging in an undesirable way, you will need to subclass the
handler. The use case isn't common enough to be addressed in the base handler,
IMO.
--
resolution
Vinay Sajip added the comment:
I'll close this as it doesn't seem to be a Python bug.
--
resolution: -> not a bug
stage: test needed -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Vinay Sajip added the comment:
This is not a bug. For example, if you set up a rotating handler to rollover
every minute but only log once every two minutes, you won't get any empty log
files for the minutes where logging didn't happen.
The behaviour of the handler isn't expected to keep
Vinay Sajip added the comment:
After the patch for issue 1521950 was applied, this problem no longer occurs on
default/3.6.
Removing 3.4 as it's in "security patches only" mode.
--
versions: -Python 3.4
___
Python tracker <rep...@bu
Vinay Sajip added the comment:
If no more information is available, I will close this issue soon as "not a
bug".
--
status: open -> pending
___
Python tracker <rep...@bugs.python.org>
<http://bugs
Vinay Sajip added the comment:
According to PEP 398, we should patch the source for security updates for 3.3
until September 2017, though no new binary release needs to be made. I'm not
sure if expedited binary releases are needed for 3.4 and 3.5. I will look at
applying the patch in 2.7
Vinay Sajip added the comment:
I've uploaded a new patch which adds a test. I've confirmed that *without* the
patch to Modules/_ctypes/libffi_msvc/ffi.c, the test passes on win32 and fails
on amd64. *With* the patch to Modules/_ctypes/libffi_msvc/ffi.c, the test
passes on both win32 and amd64
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
assignee: steve.dower -> vinay.sajip
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Vinay Sajip added the comment:
See attached patch for proposed changes.
--
assignee: -> vinay.sajip
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file43991/patch-1.diff
___
Python tracker <rep...@bugs.python.o
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
stage: -> resolved
status: pending -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Vinay Sajip added the comment:
I am unable to reproduce this under Windows with either 32-bit or 64-bit
Python, using revision 26dd6e7f. I used Windows 10 rather than 7 as that's all
I can test on, but I don't believe it would make a difference. Is this error
still reproducible? If not, I'll
Vinay Sajip added the comment:
I'm closing this as a duplicate of issue 20160 - it appears to be the same bug.
--
resolution: -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder: -> broken ctypes calling convention on MSVC / 64-bit Windows
(l
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20160>
___
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
nosy: +vinay.sajip
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20160>
___
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
Added file: http://bugs.python.org/file43937/refresh-2016-07-29.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
Vinay Sajip added the comment:
Added belopolsky and meador.inge to nosy as they are listed as ctypes experts
in the experts index (Amaury was already there).
--
nosy: +meador.inge
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Vinay Sajip added the comment:
In my view, the best should not be the enemy of the good, and pragmatism beats
purity. I don't have the resources to test this functionality on all platforms
- just Windows and Linux - and am not familiar with other platforms like AIX,
Solaris or the BSDs
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
hgrepos: -130
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9998>
___
_
Vinay Sajip added the comment:
I have updated the patch to apply against 3.6, and changed it to be more
conservative: it only uses ld and LD_LIBRARY_PATH when trying to find a library
if the existing gcc-based method fails.
Seeing that this issue has been around for so long, I would really
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
assignee: -> vinay.sajip
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
Vinay Sajip added the comment:
Okay, I've updated with a new patch addressing SilentGhost's comments, and
addressed the comments on that patch. If I don't hear any objections by Friday,
I plan to commit this change.
--
___
Python tracker <
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
Added file: http://bugs.python.org/file43831/refresh-2016.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.o
Vinay Sajip added the comment:
> That's not really what this is about.
As I see it, it's about the ability to configure disabling of existing loggers
on reconfiguration via the listener. While it can't be done using fileConfig(),
it *can* be done using dictCon
Vinay Sajip added the comment:
I think this is just a documentation issue. You can send a dictionary suitable
for dictConfig() as JSON over the listen() socket. This is supported by 2.7 and
3.2+ - the documentation doesn't mention this, though
Vinay Sajip added the comment:
> the answer would be "not at all".
Not sure about that. If all logging did were to pass the path to lower levels
such as open or abspath, that may be true. However, some handlers do path
computations (e.g. the rotating file handlers) and so loggi
Vinay Sajip added the comment:
This has been knocking around since 3.3, but never got enough attention to make
it in. Barring objections from anyone, I'd like to commit this patch once I
check that it applies cleanly against 3.6, before we get into 3.6 beta.
--
versions: +Python 3.6
Vinay Sajip added the comment:
> We could possibly add PEP 519 support to the logging module for Python 3.6
Seems like a reasonable enhancement for 3.6.
--
stage: -> needs patch
type: -> enhancement
versions: +Python 3.6 -Python 3.5
_
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26348>
___
_
Vinay Sajip added the comment:
If it works fine with rsyslog 8.19 but fails with rsyslog 5.8, what exactly is
logging doing wrong? How is rsyslog configured in the two cases? How exactly
was the fail.log generated (I know you said tcpdump was used, but can you
provide more detail)?
I'm
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.
Vinay Sajip added the comment:
Thanks for the suggestion, but I don't propose to change the way things work in
this area, for the following reasons:
1. pyvenv tries to use the same directory layout/location of scripts as
virtualenv does. This allows users who are used to virtualenv to have
Vinay Sajip added the comment:
> However, if you still think that this is not, what the logging library is
> meant for, I'd appreciate to know.
Confirmed. I would advise against using logger names in this way.
--
___
Python tracke
Vinay Sajip added the comment:
This is a change with wide-ranging ramifications. I don't propose to do this,
as the use of '.' as a logging separator mirrors the separator used in the
Python package namespace.
Logger names are supposed to indicate the "where" of a logging event
Vinay Sajip added the comment:
> Does anyone have any valid use cases where they want to use a shared library
> on LD_LIBRARY_PATH or similar
I presume that would include this issue's creator and other people who have
commented here about what they see as a drawback in find_library's c
Vinay Sajip added the comment:
Thanks for the suggestion, but I'm not sure this can be accepted without
violating backward compatibility. It forces each handler implementation to
either accept the base implementation of handleError(), or to override it. And
if there are existing handler
Vinay Sajip added the comment:
I've asked the person who sent in the patch for #26348 to comment on this issue.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Vinay Sajip added the comment:
> and almost no one shows how to use the stream.
Because most examples out there don't care about Unicode, etc.
> I understand the redirection in the following way (also shown in the Dive
> Into Python book)
There's certainly no need to do that, and t
Vinay Sajip added the comment:
Implementing this patch has led to another issue being raised: #26664. Dan -
would you care to take a look and comment? Thanks.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Vinay Sajip added the comment:
> you have also to remember to restore sys.stdout
I'm not sure you understand how it works. The value of sys.stdout isn't
changed, so why does it need to be restored?
> for non-English languages it would be more appropriate to use codecs.open()
>
Vinay Sajip added the comment:
> requires much more coding
Much more? How so? It just seems like one open() call and passing the result to
basicConfig().
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Vinay Sajip added the comment:
But you can open a stream using the encoding you want and pass it as the
stream= parameter to basicConfig(). Why does that not work for you?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Vinay Sajip added the comment:
The change you mention was in response to Issue #26348. The patch supplied
there introduced the $ characters you say aren't required. I'm not a fish user,
but it would seem that "$__VENV_PROMPT__" would resolve to the *value* of the
environmen
Vinay Sajip added the comment:
> find_library() is documented as emulating a build-time linker, not run-time
It may be documented as that, but is emulating a build-time linker the most
useful thing? In the context of Python binding to external libraries, why is
build-time linking behavi
Vinay Sajip added the comment:
@Oliver Ruiz Dorantes I don't see how yuou reach that conclusion from what
you're showing - it just looks like s mismatch bertween format string and
arguments. If you can shrink it down to a small standalone script that
demonstrates the problem, it would
Vinay Sajip added the comment:
Can you try the attached script in place of the current activate script and see
if it meets the requirements?
--
Added file: http://bugs.python.org/file41925/activate
___
Python tracker <rep...@bugs.python.org>
Vinay Sajip added the comment:
Indeed, and in fact *all* scripts written to a venv's bin directory hard-code
the path to that venv's interpreter. This confers the benefit that such scripts
never need the venv to be explicitly activated - you can e.g. point crontab
entries to them directly
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Vinay Sajip added the comment:
It's not documented, and not intended to be changeable by the user, because it
is not set to a fixed value - the value depends on the "when" (to rollover) and
"interval" arguments to the handler initializer. If you really need to have
func
Vinay Sajip added the comment:
By design, the stdlib venv functionality expects to work from an installed
Python. However, the Python in a virtualenv venv is not an installed Python -
it copies some files from the Python it was installed from and does various
other hacks in order to work (I'm
Vinay Sajip added the comment:
Logging has been in the Python stdlib for over a dozen years, and in all that
time, no one else has had a problem with the way handler locks and formatting
work in logging. Your problem arises because your use case is very unusual, and
this is why I don't
Vinay Sajip added the comment:
That the LogRecord receives kwargs is an internal implementation detail - note
that it is not mentioned in the documentation, and not even currently used
there. If you want to pass additional information to be stored in the record,
use the documented approach
Vinay Sajip added the comment:
Hey, Steve, don't shut me out, I'm still here ;-)
I've had a heavy consulting load for the past year or so which means I can't
always deal with issues as quickly as before. If someone else fixes issues
before I get to them, it's fine by me :-)
IMO the proposed
Vinay Sajip added the comment:
> Why not doing that in record constructor?
You're right, that's probably better. Perhaps I was too hasty ...
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Vinay Sajip added the comment:
The problem is that logger names which are Unicode are not handled correctly,
leading to the error.
--
assignee: -> vinay.sajip
title: Unexpected UnicodeDecodeError in logging module -> Logging cannot handle
Unicode logger
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
nosy: +vinay.sajip
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25789>
___
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10141>
___
_
Vinay Sajip added the comment:
handle() and emit() are high level methods of a handler, and format() is at a
lower level. Not all emit() methods will call format(). For example,
socket-based and queue-based handlers don't. So it is not in general possible
to separate format() out - you
Vinay Sajip added the comment:
I cannot reproduce, see below. Which exact version of Python are you using, and
on what platform, and with what locale?
$ more logtest9.py
# coding=utf-8
import logging
logger = logging.getLogger(u'测试')
logger.error(u'测试')
$ python2.7 logtest9.py
No handlers
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>:
--
nosy: +vinay.sajip
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25405>
___
Vinay Sajip added the comment:
But this is a change in behaviour which might cause people a problem. The way
it is now, the size may be approximate rather than exact, which is reasonable
for the use case.
--
___
Python tracker <
Vinay Sajip added the comment:
This is already supported. There is a logging.handlers.MemoryHandler which
allows you to buffer logging events and then pass the buffered events to
another handler when some condition is met, such as e.g. buffer full or some
severity threshold is exceeded
801 - 900 of 2016 matches
Mail list logo
