[issue28446] pyvenv generates malformed hashbangs for scripts
Vinay Sajip added the comment: As an extra data point, note the behaviour on Windows: C:\Users\Vinay> \python34\python -m venv "\Temp\aaa bbb" C:\Users\Vinay> "\Temp\aaa bbb\Scripts\pip" --version pip 6.0.8 from C:\Temp\aaa bbb\lib\site-packages (python 3.4) C:\Users\Vinay> pyzzer -i "\Temp\aaa bbb\Scripts\pip.exe" There is a launcher. Shebang: #!"C:\Temp\aaa bbb\Scripts\python.exe" Archive contents: __main__.py C:\Users\Vinay> "\Temp\aaa bbb\Scripts\python" -m pip install -U pip You are using pip version 6.0.8, however version 9.0.1 is available. You should consider upgrading via the 'pip install --upgrade pip' command. Collecting pip from https://pypi.python.org/packages/b6/ac/7015eb97dc749283ffdec1c3a88ddb8ae03b8fad0f0e611408f1 96358da3/pip-9.0.1-py2.py3-none-any.whl#md5=297dbd16ef53bcef0447d245815f5144 Using cached pip-9.0.1-py2.py3-none-any.whl Installing collected packages: pip Found existing installation: pip 6.0.8 Uninstalling pip-6.0.8: Successfully uninstalled pip-6.0.8 Successfully installed pip-9.0.1 C:\Users\Vinay> "\Temp\aaa bbb\Scripts\pip" --version pip 9.0.1 from C:\Temp\aaa bbb\lib\site-packages (python 3.4) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28446> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
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/issue22490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28446] pyvenv generates malformed hashbangs for scripts
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 as is, as on Windows the Python launcher should honour spaces in the interpreter path. Spaces in shebang lines are not supported where they're not supported by the underlying POSIX implementation - which includes Linux and OS X, AFAICT. -- resolution: -> not a bug status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28446> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
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). It would be helpful if a Mac person could try removing it and seeing if the resulting framework builds of Python on OS X are adversely affected. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29056] logging.Formatter doesn't respect more than one formatException()
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 the whole reasonably short section to be scanned before going to the trouble of raising an issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27650] Implement `__repr__` methods for logging.Logger and others
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/issue27650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29056] logging.Formatter doesn't respect more than one formatException()
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29056] logging.Formatter doesn't respect more than one formatException()
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 across the wire, but you should be careful if you have more than one Formatter subclass which customizes the formatting of exception information. In this case, you will have to clear the cached value after a formatter has done its formatting, so that the next formatter to handle the event doesn’t use the cached value but recalculates it afresh." So, your suggested workaround is following the approach suggested in the documentation. We could change the implementation to allow a cache_exception_text attribute (defaulting to True, set in the Handler class), then it could be set to False for individual instances by application developers. This does introduce another attribute to the handler class, so this would have to be added in 3.7 and not in 3.6. I'm not sure it's worth making this change, because the use case for it is not that common. -- resolution: -> not a bug status: open -> pending ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28499] Logging module documentation needs a rework.
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 "Important" right at the top, which says: "This page contains the
API reference information. For tutorial information and discussion of more
advanced topics, see ..." and then links to the basic and advanced tutorials
and cookbook.
The basic tutorial starts with information on when to use logging (including
links to the convenient-for-beginners logging.XXX() functions), discusses the
different logging levels, and then gives a simple example:
import logging
logging.warning('Watch out!') # will print a message to the console
logging.info('I told you so') # will not print anything
So I don't see where your statement "No example of quick usage (the first one
is for `Logger.debug`, and that's not a generic one)" comes from, nor "The
top-level function are documented at the end of the document, albeit they are
the quickest way to use and understand `logging`". Although they are *listed*
low down, there are *links* to them very early in the basic tutorial - in the
very first paragraph of "When to use logging".
With reference to your rough proposed structure,
"Introduction to logging (with short example)" - the beginning of the basic
tutorial does this.
"Configuration (a separated chapter to describe file format, dict schema, and
stuff)" - outline is described in the advanced tutorial, details are found in
the specific page on the API reference for the logging.config module.
"Module references (logging, logging.config, logging.handler, etc.)" - this is
as it is now.
"Cookbook & Tutorials" - these are separated from the reference documentation
but otherwise seem to broadly follow what you're referring to here.
Bear in mind that opinions on (and reactions to) documentation are fairly
subjective. For example, you seem to find the Django documentation problematic,
but I don't, and it's widely regarded as one of the best documentation sets for
any Python project, and has contributed a lot to Django's success.
If you really want to take this on, I don't think a patch is the best way to
proceed, because there will be a *lot* of changes due to things moving around,
etc. and one would need to build the documentation from the changed sources to
get the full effect of the changes, unlike when reviewing source code. Instead,
you could create a project on ReadTheDocs which takes copies of the logging
documentation source pages and changes them to provide your alternative vision
of how the documentation should look. This will allow easier side-by-side
comparison for anyone who wants to review and compare the alternatives. If it's
generally felt (e.g. by people on python-dev) that the new version is better
than the current, then bringing the changes back shouldn't be too hard. What do
you think?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28499>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28524] Set default argument of logging.disable() to logging.CRITICAL
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 verbose when in production mode. Then if an issue crops up in production, verbosity could be temporarily turned up in the production configuration while diagnosing the issue, then turned down again later, without making code changes. Remember that verbosity can be set at the handler level too, which sometimes gives finer-grained control of logging verbosity. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28499] Logging module documentation needs a rework.
Vinay Sajip added the comment: s/leaving the details/leaving the more narrative aspects/ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28499] Logging module documentation needs a rework.
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 that the documentation provided too much detail for simple usage, and numerous people at the time responded positively to that set of changes. I'm happy to look at any proposals to improve the layout of the logging documentation, but remember that it must satisfy a lot of different audiences at different levels. Is there a link to Florian's talk somewhere? I couldn't find anything on the PyCon-fr 2016 website. Is it in English, and if not, is there a translation / transcript in English available? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28443] Logger methods never use kwargs
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 "extra" parameter, which writes those to the LogRecord. This can be inspected by filters in the same way as you propose, so there seems no reason to provide another way of doing this. N.B. Removed larry from the nosy list, as he was apparently added by accident when the "Argument Clinic" component was selected in error. -- nosy: -larry ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28404] Logging SyslogHandler not appending '\n' to the end
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.python.org/issue28404> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28335] Exception reporting in `logging.config`
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://bugs.python.org/issue28335> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28335] Exception reporting in `logging.config`
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': {
'()': 'foo',
},
}
}
logging.config.dictConfig(config)
if __name__ == '__main__':
sys.exit(main())
The exception printouts with/without "raise ... from" are shown in this Gist:
https://gist.github.com/vsajip/a17b51695bbe16bd3c9e156405388e57
I can't see much difference in terms of figuring out where the exception came
from. The only substantial difference is one line "During handling of the above
exception, another exception occurred:" with another "The above exception was
the direct cause of the following exception:".
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28335>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build
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://bugs.python.org/file44737/fix-6087.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
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 added the patch in 3.3. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build
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 the time ... will look at updating the patch with updated tests. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15452] Improve the security model for logging listener()
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 stdlib, and as this ticket has been quiet since 2012, I suppose there's no real concern about the eval() being a security issue. If there is such a concern, then my proposal to add lookup_eval() to the ast module should be considered (it didn't get any review comments when I proposed it). -- status: pending -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27930] logging's QueueListener drops log messages
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/issue27930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27935] logging level FATAL missing in _nameToLevel
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/issue27935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23105] os.O_SHLOCK and os.O_EXLOCK are not available on Linux
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" can removed from the existing section and these two flags moved to it. How does that sound? My preference would be for the latter. -- nosy: +vinay.sajip ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23105> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23746] sysconfg.is_python_build() is buggy
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 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23746> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19504] Change "customise" to "customize".
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- nosy: -vinay.sajip ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue19504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27837] Logging Cookbook Improvement
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-threading or multiprocessing and the various gotchas that can cause problems (e.g. the state of threading locks after fork). Whole books could be written about this stuff, and no doubt have been. > Just to clarify, my understanding is that the child loggers on separate > processes pass records to the main logger No, you're mixing up loggers and handlers. Look at the basic and advanced tutorial in the stdlib docs, and e.g. https://plumberjack.blogspot.co.uk/2009/09/python-logging-101.html to get an idea of the difference between them. The other posts on that site are also worth looking at, though many of those posts have been incorporated into the logging cookbook over time. > Thanks for your patience with my inexperience. You're welcome. If further discussion is needed, it's best to continue it on e.g. Stack Overflow or the python-list mailing list. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27837] Logging Cookbook Improvement
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 certain scenarios. For example, multiprocessing works differently on different platforms such as POSIX and Windows, which can lead to problems with simpler approaches. There are plenty of simpler examples in the logging tutorial and cookbook, which might be worth reviewing first if you are new to logging in Python. See this post for a discussion on using logging with multiprocessing: https://plumberjack.blogspot.co.uk/2010/09/using-logging-with-multiprocessing.html This was the original source of the example in the cookbook. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27837] Logging Cookbook Improvement
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 the object of this example (for example, there's no QueueListener in your version). So I wouldn't want to implement your proposed change in its current form. Just to clarify, a diff of the cookbook ought to be a diff of the .rst file rather than just a changed code example within it - a direct comparison needs to be possible in order to see the changes easily in a side-by-side view. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12713] argparse: allow abbreviation of sub commands by users
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- assignee: vinay.sajip -> ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12713] argparse: allow abbreviation of sub commands by users
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- priority: release blocker -> normal ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12713] argparse: allow abbreviation of sub commands by users
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 tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12713] argparse: allow abbreviation of sub commands by users
Vinay Sajip added the comment: *Mea culpa. Autocorrect :-( -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25785] TimedRotatingFileHandler missing rotations
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- stage: -> resolved status: pending -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13516] Gzip old log files in rotating handlers
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 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17153] tarfile extract fails when Unicode in pathname
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. Which platform have you seen failures on? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH 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> <http://bugs.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux
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.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27373] logging.handlers.SysLogHandler with TCP not working on rsyslog5.8
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://bugs.python.org/issue27373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27650] Implement `__repr__` methods for logging.Logger and others
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> <http://bugs.python.org/issue27650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25459] EAGAIN errors in Python logging module
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: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21699] Windows Python 3.4.1 pyvenv doesn't work in directories with spaces.
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.python.org/issue21699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25785] TimedRotatingFileHandler missing rotations
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 track of when the program is interrupted and restarted. If you need this, it is best to subclass the handler. -- resolution: -> not a bug status: open -> pending ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21999] shlex: bug in posix mode handling of empty strings
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...@bugs.python.org> <http://bugs.python.org/issue21999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27373] logging.handlers.SysLogHandler with TCP not working on rsyslog5.8
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.python.org/issue27373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
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 and 3.3 through to 3.6. -- versions: +Python 3.3 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
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. I'll apply this patch if I don't hear any objections or suggested improvements before Friday 2016-08-05. -- resolution: remind -> stage: resolved -> patch review Added file: http://bugs.python.org/file43993/patch-vms-1.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- assignee: steve.dower -> vinay.sajip ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27650] Implement `__repr__` methods for logging.Logger and others
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.org> <http://bugs.python.org/issue27650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24940] RotatingFileHandler uses tell in non-binary mode to determine size of the file in bytes
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- stage: -> resolved status: pending -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27424] Failures in test.test_logging
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 close this issue. -- status: open -> pending ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17310] Ctypes callbacks shows problem on Windows Python (64bit)
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 (large structs) ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- nosy: +vinay.sajip ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux
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.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux
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.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux
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. The documentation makes clear that the behaviour of find_library is system-dependent and makes no promises of a particular level of consistency, either with dlopen() or across platforms. Nor can we guarantee in the documentation that find_library() will exactly emulate dlopen(), since that may not hold on all platforms - and in fact, since Windows is in the mix, there is little point in trying to tie find_library() behaviour to that of dlopen() directly. My documentation update makes clear that for Linux only, LD_LIBRARY_PATH will be searched if the existing mechanisms give no joy. This request has been around since 2010, and in my view implementing this long-overdue patch will improve matters for Linux users and IIUC meet the goals of the issue creator and other commenters who concurred with his sentiment. This does not preclude improving the functionality on other platforms later, but I think we should implement this patch unless someone can point out that it makes things worse in some way. If anyone can improve it, that is also to be welcomed, of course. > As such, I would oppose a patch that only addresses the specifics of one > platform. Why would improving behaviour on one platform, without any API changes or needing additional work by users, be worthy of opposition? > What is needed is a "design" clarification of the purpose of find_library. > If we can agree on that "implementation" can follow. The purpose of find_library as currently documented seems adequately described, and the documentation update in my latest patch clarifies things further. IMO this is an area where the underlying platform features which find_library() relies on, as well as the run-time dynamic linking facilities available, are quite different across platforms. I'm not sure the agreement you seek will come any time soon, as it has not come in the last five years; it doesn't seem possible to aim for e.g. exact behaviour of dlopen(), because (a) it's not the same on Windows and (b) potentially varies too widely across POSIX platforms. Can you propose some change to the find_library() contract which you can assure will be implementable across all platforms? Certainly, fidelity with dlopen() isn't it. > IMHO - trying to get a patch in for the convenience of one platform is not an > architectural enhancement. We're not trying for an architectural enhancement here, AFAIK. I would welcome some input from others! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- hgrepos: -130 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux
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 like to get this patch committed in the short window we have before 3.6 goes into beta. Please review! -- assignee: theller -> vinay.sajip title: ctypes find_library should search LD_LIBRARY_PATH on linux -> ctypes find_library should search LD_LIBRARY_PATH on Linux versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file43929/refresh-2016.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521950] shlex.split() does not tokenize like the shell
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- assignee: -> vinay.sajip ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1521950> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521950] shlex.split() does not tokenize like the shell
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 <rep...@bugs.python.org> <http://bugs.python.org/issue1521950> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521950] shlex.split() does not tokenize like the shell
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.org/issue1521950> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26533] logging.config does not allow disable_existing_loggers=True
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 dictConfig(). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26533] logging.config does not allow disable_existing_loggers=True
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. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27493] logging module fails with unclear error when supplied a (Posix)Path
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 logging would need to have a minimal awareness of PEP 519 or else call str() on any putative filename passed in, and be completely unaware of it (assuming that str() on a Path would return the same as __fspath__(). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1521950] shlex.split() does not tokenize like the shell
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 -Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1521950> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27493] logging module fails with unclear error when supplied a (Posix)Path
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 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27493> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26348] activate.fish sets VENV prompt incorrectly
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27373] logging.handlers.SysLogHandler with TCP not working on rsyslog5.8
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 not sure I'll be able to reproduce this, so you may need to identify what you think logging is doing wrong (there have been no changes in SysLogHandler for quite a while, AFAIK). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27251] TypeError in logging.HTTPHandler.emit; possible python 2 to 3 conversion issue
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- resolution: -> fixed status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27148] Make VENV_DIR relative to Script directory
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 less to think about when switching to pyvenv. 2. Virtual environments (venvs) aren't meant to be movable. Scripts installed into virtual environments have the venv's absolute path hard-coded into their shebang. This is true for both virtualenv and pyvenv. However, a venv can always be created at another location and have the same stuff installed into it, and the old venv discarded. 3. Making changes like this would not be backwards compatible - they would probably break existing code which relies on a common layout between virtualenv and pyvenv, or the existing relative locations of script files. -- resolution: -> wont fix status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()
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 tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()
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 - nothing more. -- resolution: -> wont fix status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26999> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
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 current behaviour. Pau Tallada's point about wanting to use a cross-platform invocation also seems reasonable. Remember, if you know the exact library you want to use, you don't *need* find_library: and this issue is about making find_library useful in a wider set of cases than it currently is. > The problem I see with using find_library() to blindly load a library Nobody is saying that the result of find_library() has to be used to blindly load a library. The point you make about the code in the uuid module is orthogonal to the proposal in this issue - even the behaviour of find_library never changed, that code could break for the reasons you give. For that, it's not unreasonable to raise a separate issue about possible fragility of the code in uuid. I asked a question which I think is relevant to this enhancement request - "is emulating a build-time linker the most useful thing? In the context of Python binding to external libraries, why is build-time linking behaviour better than run-time linking behaviour?" Do you have an answer to that? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26705] logging.Handler.handleError should be called from logging.Handler.handle
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 implementations out there (i.e. not in the stdlib) which don't call handleError in their emit() (i.e. allow exceptions to propagate upwards), their behaviour would change, wouldn't it? That's not backwards-compatible. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26664] find a bug in activate.fish of venv of cpython3.6
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/issue26664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26606] logging.baseConfig is missing the encoding parameter
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 that would not be a normal way of using logging. The use of stream= should be clear from the documentation for basicConfig() parameters. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26348] activate.fish sets VENV prompt incorrectly
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/issue26348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26606] logging.baseConfig is missing the encoding parameter
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() > instead of just open() codecs.open() for older versions of Python, perhaps, but in newer Pythons (this issue is marked for Python 3.5), open is io.open which takes an encoding parameter. basicConfig() is meant for the simplest cases, so you have to draw the line somewhere as to what "basic" means. I don't propose to change where the line is drawn - and AFAIK this is the first time it's come up, so it looks as if the many non-English speaking Python users are managing just fine with basicConfig() as it is ... note that this kind of thing is always a judgement call. > The complexity of the code grows and increases a danger of "more code, more > bugs". Maybe that's why I'm choosing not to increase the complexity of my code ;-) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26606] logging.baseConfig is missing the encoding parameter
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.org/issue26606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26606] logging.baseConfig is missing the encoding parameter
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.python.org/issue26606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26664] find a bug in activate.fish of venv of cpython3.6
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 environment variable __VENV_PROMPT__, whereas "__VENV_PROMPT__" would just resolve to the literal string "__VENV_PROMPT__" which doesn't seem like what is wanted. Can you explain the reasoning by which you assert that the $ isn't wanted? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
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 behaviour better than run-time linking behaviour? This is an enhancement request, not a bug request: so if a change was to be applied, the documentation could be updated to indicate any change in behaviour. The use case is that a shared library needed by a Python extension is available on LD_LIBRARY_PATH such that a non-ctypes linking operation would find it, but ctypes.util.find_library() won't, so a user of the extension (who may not be its developer) can't load the extension easily. See also my comment http://bugs.python.org/issue9998#msg165806 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25668] Deadlock in logging caused by a possible race condition with "format"
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 be helpful for diagnosis; the stack trace you provide isn't enough for this, as I have seen similar traces many a time due to mismatched format string and arguments. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25351] pyvenv activate script failure with specific bash option
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> <http://bugs.python.org/issue25351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25833] pyvenv: venvs cannot be moved because activate scripts hard-code paths
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. You're better off making the Jenkins job build the environment in its workspace before using it - venvs are intended to be reproducible and, consequently, disposable. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26348] activate.fish sets VENV prompt incorrectly
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://bugs.python.org/issue26348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25226] "suffix" attribute not documented in logging.TimedRotatingFileHandler
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 functionality other than the default, the way to do this is by creating a subclass and changing its behaviour appropriately. IMO the accepted SO answer you linked to doesn't give correct advice. -- resolution: -> not a bug status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26203] nesting venv in virtualenv segfaults
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 not using 'hack' as a pejorative here - it's just what virtualenv has to do). Thus, you cannot use venv to create an environment from a virtualenv venv's Python. For this to work seamlessly, there would probably need to be coupling between venv and virtualenv - virtualenv has potentially to be updated with additional hacks every time there is a new Python release, in order to keep working. It doesn't make sense to couple the stdlib closely with a third-party package. Does it work the other way around? I realise this doesn't help you with tox, and of course tox has to use virtualenv because of supporting older versions of Python ... -- nosy: +carljm resolution: -> not a bug ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25668] Deadlock in logging caused by a possible race condition with "format"
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 propose to make changes to the stdlib to cater for it. You can, as I've suggested earlier, subclass the handlers you need and implement their emit methods as per your needs. Any changes to the stdlib code along the lines you've proposed could well break existing code for other people, so making these changes is not warranted. -- resolution: -> not a bug status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26061] logging LogRecordFactory allow kwargs
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 - which is to pass a dictionary in the "extra" keyword argument containing the additional fields to add. -- resolution: -> not a bug status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26070] Launcher fails to find in-place built binaries from earlier Python versions
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 change by Mark seems reasonable. It's really only for us devs anyway. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25664] Logging cannot handle Unicode logger names
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.org/issue25664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25664] Logging cannot handle Unicode logger names
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 names ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25789] py launcher stderr is not piped to subprocess.Popen.stderr
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- nosy: +vinay.sajip ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25668] Deadlock in logging caused by a possible race condition with "format"
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 will need to have a customised handler to deal with your somewhat unusual use case, and do whatever you need in there. Threading is a complex area and while logging is one specific case you may have come across, it's entirely possible to have a situation with any other lock (e.g. in your application) where acquiring the lock and calling __unicode__() on one of your objects will also result in a deadlock. So your proposal wouldn't fix the problem in a general way - just move it so that you might avoid the problem, but a more esoteric use of locks wouldn't necessarily work. In general, to avoid deadlocks, you have to acquire locks in a fixed order, and only you know what those locks are - so you can implement the appropriate acquisition and release code in your handle(). -- resolution: -> not a bug status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25664] Unexpected UnicodeDecodeError in logging module
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 could be found for logger "测试" -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25405] User install of 3.5 removes py.exe from C:\Windows
Changes by Vinay Sajip <vinay_sa...@yahoo.co.uk>: -- nosy: +vinay.sajip ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24940] RotatingFileHandler uses tell in non-binary mode to determine size of the file in bytes
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 <rep...@bugs.python.org> <http://bugs.python.org/issue24940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25344] Enhancement to Logging - Logging Stack
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. Flushing the buffer to the other handler can be customised by subclassing and overriding shouldFlush() and perhaps flush() methods. https://docs.python.org/2/library/logging.handlers.html#memoryhandler I can perhaps add a cookbook recipe to illustrate, so I'll leave this issue open for now, as a reminder. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
