Vinay Sajip added the comment:
The pyvenv pydoc script should be in the venv's Scripts folder, which is not
(normally) on sys.path - the venv's Lib\site-packages is. Can you provide a
small script which demonstrates the problem while confirming that the venv's
Scripts folder has not been
Vinay Sajip added the comment:
I would change the reverted test_logging to add
print(logging._warnings_showwarning) before the failing assertions. If this
is bound to the original warnings.showwarning implementation, all should be
well. If it points to e.g. idle_showwarning, you would expect
Vinay Sajip added the comment:
Recent changes to the launcher mean that for a shebang line of #!/usr/bin/env
python, the path is searched for a Python executable. This will include the
Python executable in an activated venv, so I am closing this issue. The change
is already available
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17010
Vinay Sajip added the comment:
Is there any discussion which lead to this change?
http://mail.python.org/pipermail/python-dev/2013-May/125939.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17010
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17903
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
Added file: http://bugs.python.org/file30480/34974b9bc4d0.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11959
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
Added file: http://bugs.python.org/file30441/d7c50c15468d.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11959
Vinay Sajip added the comment:
Patch now updated to revert asyncore changes. The changes are now:
smtpd.py - changed SMTPChannel and SMTPServer to accept map argument
test_logging.py - removed subclassed SMTPChannel, not needed since the base
SMTPChannel class now accepts a map
New submission from Vinay Sajip:
This string contains DOMAIN\username, which is talking about Windows
and is a valid string in Python 2.x but not in 3.x. However, 2to3 passes
this string through unchanged, and it causes a SyntaxError when
interpreted by Python 3.x, because it contains what
Vinay Sajip added the comment:
I wasn't suggesting changing the signature of create_socket, I just thought
that it needed to be reimplemented because it didn't pass a map to set_socket.
I've had a look at it again, and a reimplementation of create_socket doesn't
seem to be needed, after all
Vinay Sajip added the comment:
The python-daemon documentation states, about files_preserve:
Elements of the list are file descriptors (as returned by a file object's
`fileno()` method) or Python `file` objects. Each specifies a file that is not
to be closed during daemon start.
Notice
Vinay Sajip added the comment:
I see what you're saying now, but there's no explicit close in logging, so it's
coming from somewhere lower down. Let's examine what happens when we try to
emit the record:
- def emit(self, record):
(Pdb)
/usr/lib/python2.7/logging/handlers.py(791)emit()
- msg
Vinay Sajip added the comment:
We'll try this with a simple script which doesn't use logging at all:
import os
import socket
MSG1 = '14Hi, \x00'
MSG2 = '14there!\x00'
sock = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
sock.connect('/dev/log')
sock.send(MSG1)
os.close(sock.fileno
Vinay Sajip added the comment:
The old socket's destructor closes the fd of the new socket.
Aha! Nice one. But what's the correct fix? I suppose a
self.sock = None
before every self.sock = socket.socket call would fix seem this, and while I
can certainly make this change in SysLogHandler
Vinay Sajip added the comment:
Isn't this a case of handles being closed in the child after a fork, by the
daemon module? Have you investigated the files_preserve option in DaemonContext?
--
resolution: - invalid
status: open - pending
___
Python
New submission from Vinay Sajip:
Track implementation of logger hierarchy introspection as per
http://plumberjack.blogspot.co.uk/2012/04/introspecting-logger-hierarchy.html
--
assignee: vinay.sajip
components: Library (Lib)
messages: 187904
nosy: vinay.sajip
priority: normal
severity
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
hgrepos: +186
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17855
___
___
Python-bugs-list
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
keywords: +patch
Added file: http://bugs.python.org/file30032/64df448c183d.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17855
Vinay Sajip added the comment:
Added Brandon to nosy list, as his logging_tree is what set the ball rolling on
this one. Brandon, your comments on the patch would be very welcome.
--
nosy: +brandon-rhodes
stage: - patch review
___
Python tracker
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
Added file: http://bugs.python.org/file29970/cd970801b061.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17795
Vinay Sajip added the comment:
Okay, I made the change to default socktype=None. Please try out the latest
patch (ideally on all Python versions you can test with) to confirm it's OK.
Then I can apply to 2.7/3.2/3.3/default. Thanks.
--
___
Python
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
hgrepos: +183
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17795
___
___
Python-bugs-list
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
Added file: http://bugs.python.org/file29950/6e46f4e08717.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17795
Vinay Sajip added the comment:
I've attached an alternative patch. The default socktype stays as
socket.SOCK_DGRAM, but you can specify socktype=None to get the SOCK_DGRAM
falling back to SOCK_STREAM behaviour.
Can you confirm that this alternative approach works in your environment
Vinay Sajip added the comment:
Does that mean that if I just change the default back to socktype=None, that
will be good enough?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17795
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
assignee: - vinay.sajip
nosy: +vinay.sajip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17795
Vinay Sajip added the comment:
No, this behaviour is as expected. The sequence of events:
1. You call setup_logging(), which creates a logger with level DEBUG, and add a
file handler to it.
2. You import m2, which calls logging.info(), which adds a handler to the root
logger (via basicConfig
Vinay Sajip added the comment:
In this case couldn't symlinks be automatically used on Windows Vista or
newer?
It seems simpler if the default behaviour is the same on all Windows flavours -
you can specify --symlinks if you're on Windows Vista or later
Vinay Sajip added the comment:
This looks to me as if it will need a patch in distutils. Unlike virtualenv,
which contains a patched copy of distutils (and hence allows having a .cfg
adjacent to it), pyvenv does not create patched modules in the venv. It does
not make sense to change
Vinay Sajip added the comment:
On second thought, there is probably no good reason to ignore the build-*
settings.
I was just about to mention this. I'm not an expert on distutils internals and
whether this is the best way to accomplish what's needed, but the approach
seems reasonable
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
assignee: - vinay.sajip
components: +Library (Lib)
type: - behavior
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17713
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
nosy: -vinay.sajip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17453
___
___
Python-bugs
Vinay Sajip added the comment:
Removing myself from nosy, as it appears to be a ConfigParser issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17453
Vinay Sajip added the comment:
As suggested in the documentation, you could assign the importer as an
attribute of the configurator *instance*, in which case it shouldn't be treated
as a bound method. What happens if you use the suggestion in the documentation
change referred to here
Vinay Sajip added the comment:
The logger obtained by logging.getLogger('root') is not the root logger, but a
child of the root logger.
Please post your configuration, ideally the smallest version which allows you
to reproduce the failure
Vinay Sajip added the comment:
Yes, this fails because it tries to construct the MemoryHandler first. Because
the constructing is done in order of the keys, you can get it to work by
renaming the 'fileGlobal' to 'afileGlobal' - this gets constructed before
'bufferGlobal'. I agree
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
type: crash - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17508
___
___
Python-bugs
Vinay Sajip added the comment:
What is your intent in setting up a configuration like that? How do you expect
it to behave?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17453
Vinay Sajip added the comment:
I don't believe this is logging-related - it relates to how you can rename open
files on POSIX. Both loggers use the same file, until rollover - thereafter,
they use different files, resulting in the behaviour you saw. To illustrate,
run the following script
Vinay Sajip added the comment:
BTW in the example script I do fa.flush() a couple of times when I meant to do
fb.flush() (in the i == 3 clause). The result is the same after correcting this.
--
___
Python tracker rep...@bugs.python.org
http
Vinay Sajip added the comment:
My approach was just as outlined in the first few paragraphs
The not-recommended approach I'm referring to is that of having a two
RotatingFileHandlers *with the same filename* attached to two loggers.
It's perfectly OK to follow the recommendation of naming
Vinay Sajip added the comment:
I'm not sure it's related to #11557 - it's more likely to be my changes last
week to fix #17313, where I changed those tests to add
self.addCleanup(os.remove, 'test.log')
There's also an addCleanup that closes the handler which opens the file, which
should
Vinay Sajip added the comment:
I'm OK with changing the logging cookbook to remove explicit subclassing from
object in the examples.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17351
Vinay Sajip added the comment:
Closing, as the errors seem to have gone away after the cleanup update.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17384
Vinay Sajip added the comment:
I believe the case is covered by the block:
[snip]
Ah, right. I wasn't sure that was the exact same code path that was being
exercised. But I didn't look very closely.
If you think it is worthwhile?
Only if it exercises a different code path
Vinay Sajip added the comment:
There are only three logging tests that open a handler to test.log:
test_filename, test_filemode and test_incompatible.
AFAIK those tests have remained unchanged over several years, if not months. Is
the failure repeatable? Which platform did the failure occur
Vinay Sajip added the comment:
I investigated a little further. The file is created in the test directory
(build/test_python_/) and, I assume, the dir is wiped at the end of the
test.
I can go through and do an addCleanup(os.remove, 'test.log') in the relevant
tests; that should do
Vinay Sajip added the comment:
Plus, the standalone launcher has already been updated (the version displayed
in the installer and the resource version should be 1.0.1.2):
https://bitbucket.org/vinay.sajip/pylauncher/downloads
--
___
Python tracker
Vinay Sajip added the comment:
Can you provide a couple of examples of that notation?
entry_points =
[console_scripts]
pybabel = babel.messages.frontend:main
[distutils.commands]
compile_catalog = babel.messages.frontend:compile_catalog
extract_messages
Vinay Sajip added the comment:
Please post, on a machine where the problem is occurring, the contents of the
following keys in the registry. What I have shown below is what you should have
(allowing for differing locations for Windows):
[HKEY_CLASSES_ROOT\.py]
@=Python.File
Vinay Sajip added the comment:
The .pys entry needn't be there - I left it in by mistake.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17290
Vinay Sajip added the comment:
Does the error occur with the standalone launcher downloadable from BitBucket?
The value not set for shell\open is not good.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17290
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17290
___
___
Python-bugs-list
Vinay Sajip added the comment:
Good catch, Mark!
I'll wait for confirmation that your patched pyw.exe works, then make the
changes in the Python repository and also update the standalone launcher.
--
___
Python tracker rep...@bugs.python.org
http
Vinay Sajip added the comment:
It's not a bug - the reason it's like that is that it allows conversion and
format specifiers to be given - {field_name!conversion:format_spec}.
Of course a more robust solution using regular expressions could be
implemented, but it's not really worth
Vinay Sajip added the comment:
It is by design that logging accepts arbitrary objects, rather than just
strings, see
docs.python.org/howto/logging.html#arbitrary-object-messages
and, as documented, the instance's __str__ will be called by logging calling
str() on the instance. If people
New submission from Vinay Sajip:
The attached file failing.tar.gz contains a path with UTF-8-encoded Unicode.
This causes extractall() to fail, but only when the destination path is
Unicode. That's because it leads to a implicit str-unicode conversion using
ASCII.
Test script:
import shutil
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
Added file: http://bugs.python.org/file28988/failing.tar.gz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17153
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
nosy: +lars.gustaebel
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17153
___
___
Python-bugs
New submission from Vinay Sajip:
The wrap_socket function in ssl.py (unlike the method of the same name in
SSLContext) doesn't accept a server_hostname argument, despite the fact that
it's a one-liner calling SSLSocket, which does take that argument. It it like
this for a reason, or just
Vinay Sajip added the comment:
A test would also be nice :-)
I do test the launcher in a standalone environment, but it's not
straightforward to test in a standard build or buildbot environment. For
example, it needs 4 sets of Python (Python 2.x and 3.x, 32-bit and 64-bit
builds for each
Vinay Sajip added the comment:
When using an activated virtual environment, there is no need to use py -
just use python. Primarily, the launcher looks for a shebang line in a script
to determine which interpreter to use for the script. If no shebang line can be
found, it will launch
Vinay Sajip added the comment:
Your suggestions are good, and I implemented them more or less as you
suggested. Additional comments:
it never makes sense to add more than one filter
Except for readability. Although in theory one filter could do the work of
several, it may be that different
Vinay Sajip added the comment:
Looking at Phil Elson's patch:
I didn't see a test case relating to the example in his comment, namely
f.format({0:{}}, 'foo', 5)
Did I miss it? The documentation also needs to be updated.
--
___
Python tracker rep
Vinay Sajip added the comment:
Thanks for hunting these down. With the latest version, neither variant of the
teardown script produces any error message on my system, either with 3.3 or 3.4
(default).
--
___
Python tracker rep...@bugs.python.org
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
hgrepos: +171
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16613
___
___
Python-bugs-list
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
keywords: +patch
Added file: http://bugs.python.org/file28694/951243de359a.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16613
Vinay Sajip added the comment:
Can you write-up a patch with tests and a doc change?
Done.
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16613
Vinay Sajip added the comment:
d if d is not None else {}
Your intention makes sense, though I would prefer to write it as:
if d is None:
d = {}
return self.__class__(d, *self.maps)
--
___
Python tracker rep...@bugs.python.org
http
Vinay Sajip added the comment:
I agree this is a reasonable expectation, but I've not encountered this problem
before. Can you provide a short script demonstrating the problem?
Which platform did you encounter these problems on, and what was the logging
configuration
Vinay Sajip added the comment:
Oh, I see what you mean now. I guess the approach you used is straightforward,
and perhaps something could be added to test.support. It's only an aesthetic
thing, though, IIUC.
I normally don't run into this because I log to file when running unit tests,
or run
Vinay Sajip added the comment:
I had in mind outside projects and the larger community for this request
Fair enough - then the best place for the specialisation of stream and handler
would seem to be unittest/unittest2. So I'll add Michael Foord to the nosy list.
--
nosy
Vinay Sajip added the comment:
Although there is no versionadded directive, the HOWTO documentation does state
that the behaviour relates to Python 3.2 and later, and how to obtain the
earlier behaviour.
I will add documentation (including a versionadded) to the reference docs and
also
Vinay Sajip added the comment:
You are apparently not using the logging in stdlib, but the older, standalone
logging package intended to be used in versions of Python older than 2.3 - note
the presence of site-packages/logging-0.4.9.6-py2.6.egg in the traceback.
If you are using Python 2.6
Vinay Sajip added the comment:
Passing a globals() instance looks hackish.
Agreed it's not ideal, but we're constrained by what's available to compare
against via the frame. Apart from globals() there's only really the filename,
which isn't ideal either
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
Added file: http://bugs.python.org/file28486/aecafebb7880.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16778
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
hgrepos: +166
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16778
___
___
Python-bugs-list
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
keywords: +patch
Added file: http://bugs.python.org/file28472/8756372f0f5f.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16778
Vinay Sajip added the comment:
I will give this some thought, but it won't be possible to add it to Python 2.x
(which is closed for feature additions). Any enhancement in this area would
apply to Python 3.4 and later.
--
versions: +Python 3.4 -Python 2.7
Vinay Sajip added the comment:
What about subclassing Logger? Then you could override findCaller() to do
whatever you need, as well as adding a notice() method, for example.
I agree using the source filename isn't ideal, but it's hard to know how people
might arbitrarily wrap logging calls
Vinay Sajip added the comment:
FTR, distutils only recommends and supports running “python setup.py”, i.e.
relative path in the script’s directory.
Right, but this behaviour is seen even when the script is in the current
directory.
--
___
Python
New submission from Vinay Sajip:
If a script is run directly, the value of __file__ in it is relative to the
current directory. If run via runpy.run_module, the value of __file__ is an
absolute path. This is a problem in certain scenarios - e.g. if the script is a
distribution's setup.py
Vinay Sajip added the comment:
I'd use runpy.run_path if I could, but it's not available on Python 2.6 -
that's why I'm using run_module.
A lot of setup.py files out there use __file__ to compute additional package
names, package data locations etc. - this can lead to bogus package names
Vinay Sajip added the comment:
Even when posix_local becomes the default scheme on Debian python builds,
it's not clear whether the suggested fix is the correct one to make, unless
posix_local is added to sysconfig's list of _INSTALL_SCHEMES. Matthias
comment makes sense when considering
Vinay Sajip added the comment:
The sentinel starts with a _, which to a casual reader (me) suggests
that it's a private implementation detail that I should not have to
touch. (am I right on this?)
Python is a language for consenting adults, so nothing is off-limits, except
that you need
Vinay Sajip added the comment:
Why do you think None is a valid value to send for normal operation? Since the
queue is only meant for sending logging events (records), it seems reasonable
to send None as a sentinel - it should never be seen during operation.
The QueueListener is *supposed
Vinay Sajip added the comment:
In terms of the venv code, I don't see how doing the test in that way would
cause problems - as long as the value of sys.executable doesn't change, then as
I see it, the venv code should operate as it's meant
Vinay Sajip added the comment:
Vinay, do you think dereferencing sys.executable could lead to trouble with
venvs?
It could - the venv code looks for a venv configuration file relative to
sys.executable, which could be a symlink into a system-wide Python
installation. Resolving the symlink
New submission from Vinay Sajip:
ChainMap.new_child could IMO be improved through allowing an optional dict to
be passed, which is used to create the child. The use case is that you
sometimes need to temporarily push a new non-empty mapping in front of an
existing chain. This could
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
assignee: - vinay.sajip
nosy: +vinay.sajip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16521
Vinay Sajip added the comment:
This is not a valid issue. The approach to use is documented:
http://docs.python.org/2.6/library/logging.html#configuring-logging-for-a-library
http://docs.python.org/2.7/howto/logging.html#configuring-logging-for-a-library
--
resolution: - invalid
Vinay Sajip added the comment:
IIUC, Debian Experimental is not a complete distribution. Are there other,
non-experimental OS variants where posix_local is used with Python 3.x?
On my Ubuntu Oneiric and Precise 64-bit machines, the default install scheme on
the official Python 3.2
Vinay Sajip added the comment:
as far as I know virtualenv does not create links for local/bin and friends
either.
AFAIK it never used to, but it seems to do so since 1.6.3, in an attempt to fix
a problem with the posix_local install scheme. I just tested with virtualenv
1.6.4, and when I
Vinay Sajip added the comment:
Whoops, mouse glitch led to components being wrongly set.
--
components: +Library (Lib) -2to3 (2.x to 3.x conversion tool), Benchmarks,
Build, Cross-Build, ctypes
___
Python tracker rep...@bugs.python.org
http
Vinay Sajip added the comment:
I've added the ability to set handler properties via configuration slightly
more easily, see the code in changeset a81ae412174a (the unit test shows how
the configuration looks in practice). This enhancement cannot be added to
earlier Python versions (no feature
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16391
Vinay Sajip added the comment:
Well, the config file format is older and fileConfig() does not cover as much
as dictConfig() does. (For example, filters). I don't propose to spend time
enhancing fileConfig(), now that dictConfig() is available. If you are forced
to use fileConfig(), you can
Vinay Sajip added the comment:
I don't understand what you mean. For example, defining
def my_handler(*args, **kwargs):
terminator = kwargs.pop('terminator', '!\n')
h = logging.StreamHandler(*args, **kwargs)
h.terminator = terminator
return h
you can use with a definition
Vinay Sajip added the comment:
Thanks for the patch, but I'm closing this as 'wontfix', as per the points made
by Antoine and David. If you need logging from an embedded system, please
consider using one of the socket-based logging handlers, if that's feasible in
the specific situation
1101 - 1200 of 2016 matches
Mail list logo
