[issue43749] venv module does not copy the correct python exe
Vinay Sajip added the comment: 3.10 and 3.9 - OK, but 3. is security fixes only, I'm afraid. -- ___ Python tracker <https://bugs.python.org/issue43749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43749] venv module does not copy the correct python exe
Vinay Sajip added the comment: *3.8, I meant. -- ___ Python tracker <https://bugs.python.org/issue43749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43749] venv module does not copy the correct python exe
Vinay Sajip added the comment: New changeset bb8d645f3a09645686cf8f66bd46dcfa4efac713 by Miss Islington (bot) in branch '3.10': [3.10] bpo-43749: Ensure current exe is copied when using venv on windows (GH-25216) (GH-30034) https://github.com/python/cpython/commit/bb8d645f3a09645686cf8f66bd46dcfa4efac713 -- ___ Python tracker <https://bugs.python.org/issue43749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43749] venv module does not copy the correct python exe
Vinay Sajip added the comment: New changeset bad16f0cf71a6b11ef62f86be6b3d3567cd70a16 by Miss Islington (bot) in branch '3.9': [3.9] bpo-43749: Ensure current exe is copied when using venv on windows (GH-25216) (GH-30033) https://github.com/python/cpython/commit/bad16f0cf71a6b11ef62f86be6b3d3567cd70a16 -- ___ Python tracker <https://bugs.python.org/issue43749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46063] TimedRotatingFileHandler deletes wrong files
Change by Vinay Sajip : -- keywords: +patch pull_requests: +28316 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30093 ___ Python tracker <https://bugs.python.org/issue46063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Vinay Sajip added the comment: > This is the intended behaviour, and yes it's changed from previous versions > ... The previous value was incorrect, hence it was marked as an internal > field. But the value as it's calculated now seems to give a file that doesn't exist - how can that be correct? -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46063] TimedRotatingFileHandler deletes wrong files
Vinay Sajip added the comment: New changeset cb589d1b6bad4b75852c2e2a471a3800d5efdca7 by Vinay Sajip in branch 'main': bpo-46063: Improve algorithm for computing which rolled-over log file… (GH-30093) https://github.com/python/cpython/commit/cb589d1b6bad4b75852c2e2a471a3800d5efdca7 -- ___ Python tracker <https://bugs.python.org/issue46063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46063] TimedRotatingFileHandler deletes wrong files
Vinay Sajip added the comment: New changeset f84e2f6c0aca97c59ec8ce21715ae9bd89893307 by Miss Islington (bot) in branch '3.10': [3.10] bpo-46063: Improve algorithm for computing which rolled-over log file… (GH-30093) (GH-30094) https://github.com/python/cpython/commit/f84e2f6c0aca97c59ec8ce21715ae9bd89893307 -- ___ Python tracker <https://bugs.python.org/issue46063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46063] TimedRotatingFileHandler deletes wrong files
Vinay Sajip added the comment: New changeset 94234228abbb84945a48049a7515dea960bc9834 by Miss Islington (bot) in branch '3.9': [3.9] bpo-46063: Improve algorithm for computing which rolled-over log file… (GH-30093) (GH-30095) https://github.com/python/cpython/commit/94234228abbb84945a48049a7515dea960bc9834 -- ___ Python tracker <https://bugs.python.org/issue46063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46063] TimedRotatingFileHandler deletes wrong files
Change by Vinay Sajip : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig
Change by Vinay Sajip : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue23010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: sys._base_executable is wrong, breaks venv - it wasn't under 3.11.0a2
Change by Vinay Sajip : -- title: 3.11.0a3: under tox, sys._base_executable is wrong -> 3.11.0a3: sys._base_executable is wrong, breaks venv - it wasn't under 3.11.0a2 ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46063] TimedRotatingFileHandler deletes wrong files
Vinay Sajip added the comment: Ah ... forgot to set delay=True for the handlers. Will look at this soon. -- ___ Python tracker <https://bugs.python.org/issue46063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46063] TimedRotatingFileHandler deletes wrong files
Change by Vinay Sajip : -- pull_requests: +28326 pull_request: https://github.com/python/cpython/pull/30103 ___ Python tracker <https://bugs.python.org/issue46063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46063] TimedRotatingFileHandler deletes wrong files
Vinay Sajip added the comment: New changeset 850aefc2c651110a784cd5478af9774b1f6287a3 by Vinay Sajip in branch 'main': bpo-46063: Add 'delay=True' to file handler initialization. (GH-30103) https://github.com/python/cpython/commit/850aefc2c651110a784cd5478af9774b1f6287a3 -- ___ Python tracker <https://bugs.python.org/issue46063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46063] TimedRotatingFileHandler deletes wrong files
Vinay Sajip added the comment: New changeset 908fd691f96403a3c30d85c17dd74ed1f26a60fd by Miss Islington (bot) in branch '3.10': [3.10] bpo-46063: Add 'delay=True' to file handler initialization. (GH-30103) (GH-30104) https://github.com/python/cpython/commit/908fd691f96403a3c30d85c17dd74ed1f26a60fd -- ___ Python tracker <https://bugs.python.org/issue46063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46063] TimedRotatingFileHandler deletes wrong files
Vinay Sajip added the comment: New changeset 17260e44b5ed3508e3c15f1b7ded761879e91d3e by Miss Islington (bot) in branch '3.9': [3.9] bpo-46063: Add 'delay=True' to file handler initialization. (GH-30103) (GH-30105) https://github.com/python/cpython/commit/17260e44b5ed3508e3c15f1b7ded761879e91d3e -- ___ Python tracker <https://bugs.python.org/issue46063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46200] Discourage logging f-strings due to security considerations
Vinay Sajip added the comment: Another (minor) point against using f-strings or .format is that formatting prematurely might be doing unnecessary work - by default, logging formats messages lazily, waiting until a message actually needs to be output. This could perhaps be more prominently emphasized in the docs where formatting is first introduced. -- ___ Python tracker <https://bugs.python.org/issue46200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46251] logger.config.configure_formatter executes arbitrary code
Vinay Sajip added the comment: > "Dont load untrusted config files" is the answer I expected. Yes. It's the usual convenience vs. security trade-off. To make configuration convenient, configurable factories with configurable parameters are provided. Can this be misused? Of course. Digital signing has its place where auditability and accountability are important, but it would normally only be used in production where configuration changes are subject to a strict process with signoffs. There could definitely be stronger warnings in the documentation about trust and configurations. > Is it reasonable to say that all classes by _resolve() and resolve() should > have "logger." at the top of them? If not perhaps the object could have a > permitted list of top level packages that defaults to just "logger." but > could be extended to others by the developer. I would think that's going too far, and perhaps it only moves the problem. In any case, dictConfig has a mechanism using the "()" key which allows any callable, not just a class. This is for a not uncommon use case where the callable is a function that returns a logging object (handler/formatter/filter) that has been tweaked in some way. But that feature can of course also be used with untrusted inputs to produce surprises. -- ___ Python tracker <https://bugs.python.org/issue46251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46251] logger.config.configure_formatter executes arbitrary code
Change by Vinay Sajip : -- keywords: +patch pull_requests: +28617 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30411 ___ Python tracker <https://bugs.python.org/issue46251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46251] logger.config.configure_formatter executes arbitrary code
Vinay Sajip added the comment: I've created a PR to add a "Security Considerations" section in the configuration documentation. Comments on the PR are welcome. -- stage: patch review -> ___ Python tracker <https://bugs.python.org/issue46251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46251] logger.config.configure_formatter executes arbitrary code
Vinay Sajip added the comment: New changeset 46c7a6566bca2e974a89c90c35ed1c498d9d3b02 by Vinay Sajip in branch 'main': bpo-46251: Add 'Security Considerations' section to logging configura… (GH-30411) https://github.com/python/cpython/commit/46c7a6566bca2e974a89c90c35ed1c498d9d3b02 -- ___ Python tracker <https://bugs.python.org/issue46251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46251] logger.config.configure_formatter executes arbitrary code
Vinay Sajip added the comment: New changeset db60ed1170a02189a4fd4b7574e0722dd22c658b by Miss Islington (bot) in branch '3.10': [3.10] bpo-46251: Add 'Security Considerations' section to logging configura… (GH-30411) (GH-30447) https://github.com/python/cpython/commit/db60ed1170a02189a4fd4b7574e0722dd22c658b -- ___ Python tracker <https://bugs.python.org/issue46251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46251] logger.config.configure_formatter executes arbitrary code
Vinay Sajip added the comment: New changeset 188fbdee0d6721a948eabb81cdcacac371614793 by Miss Islington (bot) in branch '3.9': [3.9] bpo-46251: Add 'Security Considerations' section to logging configura… (GH-30411) (GH-30448) https://github.com/python/cpython/commit/188fbdee0d6721a948eabb81cdcacac371614793 -- ___ Python tracker <https://bugs.python.org/issue46251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46251] logger.config.configure_formatter executes arbitrary code
Vinay Sajip added the comment: I'm closing with the assumption that the addition to the documentation covers this. If that needs to be improved, this can be reopened with specific suggestions. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41011] [venv] record which executable and command were used to create a virtual environment
Vinay Sajip added the comment: New changeset f4e325c21d6d9c2bf70224dc69d707b226f87872 by andrei kulakov in branch 'main': bpo-41011: venv -- add more variables to pyvenv.cfg (GH-30382) https://github.com/python/cpython/commit/f4e325c21d6d9c2bf70224dc69d707b226f87872 -- ___ Python tracker <https://bugs.python.org/issue41011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46292] Add microseconds to logging.LogRecord
Change by Vinay Sajip : -- versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue46292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46292] Add microseconds to logging.LogRecord
Vinay Sajip added the comment: Thanks for the patch. We're need to get contributors to sign a Contributor License Agreement (CLA) before we can accept their patches. Would you be willing to do this? The process could be smoother, but it's not too bad, and here's where you get started: https://www.python.org/psf/contrib/contrib-form/ -- ___ Python tracker <https://bugs.python.org/issue46292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42378] logging reopens file with same mode, possibly truncating
Vinay Sajip added the comment: I guess it got missed during the 3.10 beta cycle by not being backported - it might have needed to be cherry-picked. I'll see about getting it backported to 3.10. -- ___ Python tracker <https://bugs.python.org/issue42378> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42378] logging reopens file with same mode, possibly truncating
Vinay Sajip added the comment: New changeset e35430bec528dfb1a653cd457ea58b5a08543632 by Miss Islington (bot) in branch '3.10': [3.10] bpo-42378: fixed log truncation on logging shutdown (GH-27310) (GH-30468) https://github.com/python/cpython/commit/e35430bec528dfb1a653cd457ea58b5a08543632 -- ___ Python tracker <https://bugs.python.org/issue42378> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46377] TimedRotatingFileHandler "midnight" misleading when interval > 1
Vinay Sajip added the comment: Making a change without considering backward compatibility is premature. I've closed the PR as there appears to be something wrong with it - it references hundreds of changed files. Did you look at the 'atTime' keyword parameter of TimedRotatingFileHandler? -- ___ Python tracker <https://bugs.python.org/issue46377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46377] TimedRotatingFileHandler "midnight" misleading when interval > 1
Vinay Sajip added the comment: Unfortunately, you can't rely on people always doing "the sensible thing", for any number of good reasons. If a particular set of parameter values didn't cause failure, it is probably used somewhere. Anyway, your problem goes away if interval == 1, right? If we were to tighten things up (e.g. disallowing interval > 1 with "midnight"), then it would have to be done on a deprecation cycle at the very least, ISTM. -- ___ Python tracker <https://bugs.python.org/issue46377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41906] logging.config.dictConfig does not work with callable filters
Vinay Sajip added the comment: > Vinay would you consider a patch for logging where dictConfig allows taking > objects directly in addition to the reference id? Sorry I didn't respond to this; it dropped off my radar. Certainly, I would consider such a patch. -- ___ Python tracker <https://bugs.python.org/issue41906> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41906] logging.config.dictConfig does not work with callable filters
Vinay Sajip added the comment: > If you have any preference about the implementation or any pointer Nothing particular, just try to fit in with the existing code conventions even where they don't follow modern idioms (e.g. a lot of the code in this package predates PEP 8 and new styles of string formatting). -- ___ Python tracker <https://bugs.python.org/issue41906> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41906] logging.config.dictConfig does not work with callable filters
Change by Vinay Sajip : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.11 -Python 3.10 ___ Python tracker <https://bugs.python.org/issue41906> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46557] Logging captured warnings with a format string unnecessarily groups warnings together
Change by Vinay Sajip : -- type: behavior -> enhancement versions: -Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46557> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46914] On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work
Vinay Sajip added the comment: > If so, then it probably good to adjust ... since it still talks about it > being expected. Do you mean just adding a note to the effect that SysLogHandler won't work on macOS 12.2 because of changes to the syslog daemon on that platform? IIRC using the syslog module was not an option at the time SysLogHandler was added, I think because of both thread-safety and lack-of-functionality issues. -- ___ Python tracker <https://bugs.python.org/issue46914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1765140] logging: delay_fh option and configuration kwargs
Vinay Sajip added the comment: Thanks for the patch. I think it would be simpler to just implement an optional delay parameter in FileHandler and its subclasses: then the configuration stuff need not be touched at all, since the delay parameter can be specified in the configuration file. There would then be no need for a callback or a file-opening closure: If delay is False (the default), FileHandler would behave as it does now. If True, then the open code in FileHandler's constructor would be deferred until the time emit() was called on the instance. Would this meet your needs? _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1765140> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1765140] logging: delay_fh option and configuration kwargs
Vinay Sajip added the comment: I'm not sure I agree with "If fileConfig has no delay_fh option, fileConfig() would create the FileHandlers with delay_fh as False". fileConfig will create the FileHandlers using the args= section entry to pass to the constructor. Hence, by specifying True for this parameter, you get the FileHandlers to delay opening the files. In fact you get more control - you can specify True for some FileHandlers and False for others. The relevant code is in config.py in _install_handlers: ... klass = eval(klass, vars(logging)) args = cp.get(sectname, "args") args = eval(args, vars(logging)) h = apply(klass, args) ... _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1765140> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1197] logging: formatter does not accept %(funcName)s properly
Vinay Sajip added the comment: This is not a logging bug, but related to #1180193. See http://bugs.python.org/issue1180193 -- assignee: -> vsajip nosy: +vsajip resolution: -> duplicate status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1197> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1760556] logging.FileHandler may throw exception in flush()
Vinay Sajip added the comment: Fix checked in to trunk: r58268 -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1760556> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1021] logging.basicConfig does not allow to set NOTSET level
New submission from Vinay Sajip: Fix checked in to trunk - r58269. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1021> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1752539] RotatingFileHandler.doRollover behave wrong vs. log4j's
Vinay Sajip added the comment: I have now had some more time to think about this issue. I don't believe any changes are warranted, because "Errors should never pass silently. Unless explicitly silenced." and since rename errors are usually due to application- or environment-specific conditions, you need to handle these in application code. If logging continues to use the existing log file because renaming fails, then it does not behave according to expectations - e.g. maximum sizes on log files will not be honoured. Likewise, logging does not attempt to use makedirs() to ensure that the parent directory path is created first - a typo in the path would lead to an unexpected location for the log file. While Python logging borrowed a lot from log4j, it is far from a straight port; the Zen of Python is different from the Zen of Java. -- resolution: -> invalid status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1752539> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1711603] syslog syscall support for SysLogLogger
Vinay Sajip added the comment: It's only a bug when it doesn't work according to design. The present design seems adequate in that it allows syslogging via UDP or domain sockets. No one else has asked for the functionality of using system calls. BTW I note that Metalog's home page says it's a modern replacement for syslogd and klogd - so one might have reasonably expected socket support. You can avoid having to patch Python each time by the simple expedient of creating a SysLogHandler subclass (a one-time operation) and using it in place of the included SysLogHandler. -- status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1711603> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1206] logging/__init__.py
Vinay Sajip added the comment: Fix checked into trunk: r58272 -- nosy: +vsajip resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1206> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1321] TimedRotatingFileHandler logic for day of week is wrong
Vinay Sajip added the comment: Fixed checked into trunk: r58628. Also checked into release25-maint. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1321> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined
Vinay Sajip added the comment: This is not a bug: I think you are missing something. In the first example (interactive usage), the lines "import logging" and "import logging.handlers" do not magically introduce RotatingFileHandler into your interactive session's globals. To do this, you would have to say "from logging.handlers import RotatingFileHandler". An analogous example unrelated to logging: ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import httplib >>> HTTP Traceback (most recent call last): File "", line 1, in ? NameError: name 'HTTP' is not defined >>> httplib.HTTP >>> In the second example (using fileConfig), the documentation in http://docs.python.org/lib/logging-config-fileformat.html clearly states that the class and arguments are evaluated using the logging package's namespace. This means that for a handler defined in the logging package itself (such as StreamHandler) no qualification is required, but for a handler defined in the handlers subpackage, you should specify "handlers.RotatingFileHandler" in the configuration file rather than "RotatingFileHandler" or "logging.handlers.RotatingFileHandler". __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1436> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined
Changes by Vinay Sajip: -- resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1436> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1436] logging.config.fileConfig, NameError: name 'RotatingFileHandler' is not defined
Vinay Sajip added the comment: No, it doesn't. See this post: http://groups.google.com/group/comp.lang.python/browse_thread/thread/21be57fae7e9381a __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1436> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1484] logging: callHandlers tests handler levels instead of logger levels?
Vinay Sajip added the comment: The behaviour you describe is intentional. To achieve what you want, you can either set levels on the handlers or use Filters on loggers and/or handlers (if level-based filtering is not sufficient for your needs). -- nosy: +vsajip resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1484> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12386] packaging fails in install_distinfo when writing RESOURCES
Vinay Sajip added the comment: I looked at this bug again - I was getting a little confused about it ;-) The problem is happening not when writing out a resource, but the RESOURCES file listing the resources installed. This is a text file, of course, so my suggested fix of using open(resources_path, 'w', encoding='utf-8') would be reasonable. -- ___ Python tracker <http://bugs.python.org/issue12386> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13036] time format in logging is wrong
Vinay Sajip added the comment: Logging's date/time representation is supposed to conform to ISO 8601. >From ISO Standard 8601 (Third Edition, dated 2004-12-01): 4.2.2.4 Representations with decimal fraction If necessary for a particular application a decimal fraction of hour, minute or second may be included. If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign. -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue13036> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1164953] logging.basicConfig creates phantom handler
Vinay Sajip added the comment: @anatoly: What failure do you mean? The behaviour that logistix described is not a failure, it's by design. See my closing comment. -- ___ Python tracker <http://bugs.python.org/issue1164953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1164953] logging.basicConfig creates phantom handler
Vinay Sajip added the comment: > anatoly techtonik added the comment: > > I know that it is by design, but from all logging users you may be the only > one > who keeps this behaviour in mind. The message why basicConfig() failed will > be > more user-friendly. You're not likely to be aware of all the feedback I get from other users of the logging package, so I'm not sure what your inference "you may be the only one" is based on. Since basicConfig() didn't "fail" (behaviour is as designed), I'm not planning any changes in this area. Also note: this issue was raised and closed in March 2005, and there have been no requests since then to change the existing behaviour (nor would it be possible to accommodate such requests without compromising backward compatibility). -- ___ Python tracker <http://bugs.python.org/issue1164953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Vinay Sajip added the comment:
I added the line in the suggested place:
#ifdef HAVE_LINUX_TIPC_H
# include
#endif
#ifdef HAVE_LINUX_CAN_H
#include /* the line I added - line 76 */
#include
#endif
#ifdef HAVE_LINUX_CAN_RAW_H
#include
#endif
Strangely, it seems to make no difference! I copied out the actual gcc line
from the make file and ran it from the command line to just pre-process:
gcc -pthread -fPIC -g -O0 -Wall -Wstrict-prototypes -IInclude -I. -I./Include
-I/usr/local/include -I/home/vinay/projects/python/default -E
/home/vinay/projects/python/default/Modules/socketmodule.c >/tmp/tmp.c
(I assume /usr/include is always searched, as it's not explicitly named in a -I
parameter.)
Looking at the tmp.c file produced, here's the relevant section:
# 182 "/usr/include/linux/tipc.h" 3 4
struct sockaddr_tipc {
unsigned short family;
unsigned char addrtype;
signed char scope;
union {
struct tipc_portid id;
struct tipc_name_seq nameseq;
struct {
struct tipc_name name;
__u32 domain;
} name;
} addr;
};
# 73 "/home/vinay/projects/python/default/Modules/socketmodule.h" 2
# 1 "/usr/include/linux/can.h" 1 3 4
After the tipc.h include, the can.h include comes next, as if I hadn't added
the linux/socket.h line at all! What is this I don't even ...
I pasted the whole socketmodule.h file to a gist here:
https://gist.github.com/1270436
Tell me I'm not going mad!
--
___
Python tracker
<http://bugs.python.org/issue10141>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Vinay Sajip added the comment:
Just to test, I added the full absolute path name in socketmodule.h:
#ifdef HAVE_LINUX_CAN_H
#include "/usr/include/linux/socket.h"
#include
#endif
Now, the snippet from pre-processing is:
# 182 "/usr/include/linux/tipc.h" 3 4
struct sockaddr_tipc {
unsigned short family;
unsigned char addrtype;
signed char scope;
union {
struct tipc_portid id;
struct tipc_name_seq nameseq;
struct {
struct tipc_name name;
__u32 domain;
} name;
} addr;
};
# 73 "/home/vinay/projects/python/default/Modules/socketmodule.h" 2
# 1 "/usr/include/linux/socket.h" 1
# 77 "/home/vinay/projects/python/default/Modules/socketmodule.h" 2
# 1 "/usr/include/linux/can.h" 1 3 4
# 41 "/usr/include/linux/can.h" 3 4
This implies that the linux/socket.h file is not being read at all. First part
of linux/socket.h is:
#ifndef _LINUX_SOCKET_H
#define _LINUX_SOCKET_H
--
___
Python tracker
<http://bugs.python.org/issue10141>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Vinay Sajip added the comment: Ok, I found that linux/socket.h *is* actually included earlier, from /usr/include/linux/netlink.h. However, the AF_CAN definition appears only under the condition #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) ... #define AF_CAN 29 /* Controller Area Network */ ... #endif /* not kernel and not glibc */ #endif /* _LINUX_SOCKET_H */ which would imply that on this system at least, the AF_CAN definition is supposed to come from elsewhere. I did a recursive grep in /usr/include: the only place AF_CAN is defined is linux/socket.h. -- ___ Python tracker <http://bugs.python.org/issue10141> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1164953] logging.basicConfig creates phantom handler
Vinay Sajip added the comment: > There were no request to change the behaviour, because there is already this > closed issue where it is clearly said that this won't be fixed. Sure, but this issue seldom comes up as a point of confusion on comp.lang.python. If you think the documentation is confusing or not sufficiently explicit, you can propose a patch. Since configuration preferences and styles tend to be very much a matter of personal taste, I'm pretty sure that any change in this area which will be liked by some people won't be liked by others. So, it's best if people roll their own or publish on PyPI or elsewhere some code [to configure logging "optimally"] which others can use: if a widely-used pattern emerges as a no-brainer from actual usage out there, we can revisit this discussion. -- ___ Python tracker <http://bugs.python.org/issue1164953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Vinay Sajip added the comment:
PF_CAN is defined by
#define PF_CAN AF_CAN
in linux/socket.h :-(
Making the change in configure.in didn't lead to any change: no error when I
ran configure (which is ./configure --with-py-debug in my case), and when I
build, the same error (AF_CAN undefined) occurs. Just to eliminate any
extraneous variables and be absolutely sure, the program
#include
#include
int main(int argc, char ** argv)
{
printf("AF_CAN is %d\n", AF_CAN);
}
also fails with the same error.
--
___
Python tracker
<http://bugs.python.org/issue10141>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Vinay Sajip added the comment: > Did you run autoconf (or autoreconf) before? D'oh! I didn't realise I had to, though in retrospect it should have been obvious ... autoconf isn't even installed on my system, and I can't install it at the moment because of some problem with the Ubuntu repos for Jaunty. -- ___ Python tracker <http://bugs.python.org/issue10141> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10141] SocketCan support
Vinay Sajip added the comment: That did the trick - I can now build the socket module. Thanks! I noticed that the module initialisation code uses #ifdef AF_CAN and #ifdef PF_CAN rather than #ifdef HAVE_LINUX_CAN_H :-) -- ___ Python tracker <http://bugs.python.org/issue10141> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12386] packaging fails in install_distinfo when writing RESOURCES
Vinay Sajip added the comment:
I got the problem when installing a package with resources using pysetup3.
Here's the relevant part of the console session:
(venv) vinay@eta-natty:~/projects$ pysetup3 install nemo
Installing from source directory: /home/vinay/projects/nemo
running install_dist
running build
running build_py
running build_scripts
running install_lib
creating /tmp/venv/lib/python3.3/site-packages
creating /tmp/venv/lib/python3.3/site-packages/virtualenvwrapper
byte-compiling
/tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/hook_loader.py to
hook_loader.pyc
byte-compiling
/tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/user_scripts.py to
user_scripts.pyc
byte-compiling
/tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/__init__.py to
__init__.pyc
byte-compiling /tmp/venv/lib/python3.3/site-packages/nemo.py to nemo.pyc
running install_scripts
changing mode of /tmp/venv/bin/nemo to 755
running pre_hook hooks.pre_install_data for command install_data
running install_data
running install_distinfo
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/METADATA
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/INSTALLER
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/REQUESTED
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/RESOURCES
Traceback (most recent call last):
File "/tmp/venv/bin/pysetup3", line 6, in
rc = packaging.run.main() # None interpreted as 0
File "/usr/local/lib/python3.3/packaging/run.py", line 653, in main
return dispatcher()
File "/usr/local/lib/python3.3/packaging/run.py", line 642, in __call__
return func(self, self.args)
File "/usr/local/lib/python3.3/packaging/run.py", line 91, in wrapper
return f(*args, **kwargs)
File "/usr/local/lib/python3.3/packaging/run.py", line 164, in _install
return not install_local_project(target)
File "/usr/local/lib/python3.3/packaging/install.py", line 122, in
install_local_project
return _run_install_from_dir(path)
File "/usr/local/lib/python3.3/packaging/install.py", line 160, in
_run_install_from_dir
func(source_dir)
File "/usr/local/lib/python3.3/packaging/install.py", line 87, in
_run_packaging_install
dist.run_command('install_dist')
File "/usr/local/lib/python3.3/packaging/dist.py", line 709, in run_command
cmd_obj.run()
File "/usr/local/lib/python3.3/packaging/command/install_dist.py", line 508,
in run
self.run_command(cmd_name)
File "/usr/local/lib/python3.3/packaging/command/cmd.py", line 330, in
run_command
self.distribution.run_command(command)
File "/usr/local/lib/python3.3/packaging/dist.py", line 709, in run_command
cmd_obj.run()
File "/usr/local/lib/python3.3/packaging/command/install_distinfo.py", line
113, in run
writer.writerow(row)
TypeError: 'str' does not support the buffer interface
This is the relevant code in install_distinfo.run():
resources_path = os.path.join(self.distinfo_dir,
'RESOURCES')
logger.info('creating %s', resources_path)
if not self.dry_run:
#with open(resources_path, 'w', encoding='utf-8') as f:
with open(resources_path, 'wb') as f:
writer = csv.writer(f, delimiter=',',
lineterminator='\n',
quotechar='"')
for row in install_data.get_resources_out():
writer.writerow(row)
If I substitute the commented out line above which replaces 'wb' with 'w' and
encoding, I get this result:
(venv) vinay@eta-natty:~/projects$ pysetup3 install nemo
Installing from source directory: /home/vinay/projects/nemo
running install_dist
running build
running build_py
running build_scripts
running install_lib
byte-compiling
/tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/hook_loader.py to
hook_loader.pyc
byte-compiling
/tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/user_scripts.py to
user_scripts.pyc
byte-compiling
/tmp/venv/lib/python3.3/site-packages/virtualenvwrapper/__init__.py to
__init__.pyc
byte-compiling /tmp/venv/lib/python3.3/site-packages/nemo.py to nemo.pyc
running install_scripts
changing mode of /tmp/venv/bin/nemo to 755
running pre_hook hooks.pre_install_data for command install_data
running install_data
running install_distinfo
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info
creating /tmp/venv/lib/python3.3/site-packages/nemo-0.1.dist-info/METADATA
creating /tmp/venv/lib/python3.3/
[issue12405] packaging does not record/remove directories it creates
Vinay Sajip added the comment: > I share that opinion. So, the first step would be to record created > directories. We could extend PEP 376 and write entries without hash nor > length > record for directories in RECORD, or use another file in the dist-info dir. IMO using RECORD would be preferable to another file, otherwise RECORD is not a complete record :-( -- ___ Python tracker <http://bugs.python.org/issue12405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12393] Packaging should provide support for extensible categories
Vinay Sajip added the comment: > Can you add tests? https://bitbucket.org/vinay.sajip/pythonv/changeset/f7c5098e3c3b -- ___ Python tracker <http://bugs.python.org/issue12393> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13151] pysetup3 run bdist_wininst fails
New submission from Vinay Sajip : When you run pysetup3 run bdist_wininst in a project directory with a valid setup.cfg, it fails with error: Invalid command install after the build, build_py and build_scripts steps. For info, pysetup3 run bdist_dumb runs without error. -- assignee: tarek components: Distutils2, Library (Lib) messages: 145339 nosy: alexis, eric.araujo, tarek, vinay.sajip priority: normal severity: normal status: open title: pysetup3 run bdist_wininst fails versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13151> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10881] test_site and macframework builds fails
Vinay Sajip added the comment: IIRC what I did was clone the repo, configure and build, then sudo make frameworkinstall For me (on Leopard), this installed Python 3.3 in /Library/Frameworks/Python.framework, leaving my system Python (2.5.1) alone. Then you can just invoke the regression tests using python3.3 Lib/test/regrtest.py test_site from the appropriate directory. But note that this is a case where the test needs fixing, not the code being tested. -- ___ Python tracker <http://bugs.python.org/issue10881> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12393] Packaging should provide support for extensible categories
Vinay Sajip added the comment: > Great. Do you want to update the docs (packaging/setupscript and maybe > packaging/commandref too) or shall I do it? Feel free to do it, if that's OK with you. I've got a couple of other pythonv issues which are taking my time at the moment, plus I am also looking at Windows binary packaging as discussed recently on python-dev. -- ___ Python tracker <http://bugs.python.org/issue12393> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13151] pysetup3 run bdist_wininst fails
Vinay Sajip added the comment:
> On line 118, replacing 'install' with 'install_dist' should fix it.
Sadly, it just defers the problem:
vinay@eta-natty:~/projects/dory$ pysetup3 run bdist_wininst
running bdist_wininst
running build
running build_py
running build_scripts
installing to build/bdist.linux-i686/wininst
running install_lib
creating build/bdist.linux-i686
creating build/bdist.linux-i686/wininst
creating build/bdist.linux-i686/wininst/PURELIB
creating build/bdist.linux-i686/wininst/PURELIB/apackage
running install_scripts
creating build/bdist.linux-i686/wininst/SCRIPTS
changing mode of build/bdist.linux-i686/wininst/SCRIPTS/dory to 755
running install_distinfo
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/METADATA
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/INSTALLER
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/REQUESTED
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/RECORD
Traceback (most recent call last):
File "/usr/local/bin/pysetup3", line 4, in
sys.exit(main())
File "/usr/local/lib/python3.3/packaging/run.py", line 653, in main
return dispatcher()
File "/usr/local/lib/python3.3/packaging/run.py", line 642, in __call__
return func(self, self.args)
File "/usr/local/lib/python3.3/packaging/run.py", line 91, in wrapper
return f(*args, **kwargs)
File "/usr/local/lib/python3.3/packaging/run.py", line 288, in _run
dist.run_command(cmd, dispatcher.command_options[cmd])
File "/usr/local/lib/python3.3/packaging/dist.py", line 709, in run_command
cmd_obj.run()
File "/usr/local/lib/python3.3/packaging/command/bdist_wininst.py", line 175,
in run
self.create_exe(arcname, fullname, self.bitmap)
File "/usr/local/lib/python3.3/packaging/command/bdist_wininst.py", line 243,
in create_exe
cfgdata = self.get_inidata()
File "/usr/local/lib/python3.3/packaging/command/bdist_wininst.py", line 202,
in get_inidata
info = (metadata.long_description or '') + '\n'
AttributeError: 'Metadata' object has no attribute 'long_description'
It appears that there is some confusion as to whether to use attribute or item
access. The failing code above needs to be replaced with something like
if 'long_description' in metadata:
info = metadata['long_description']
else:
info = metadata.get('description', '')
info += '\n'
--
___
Python tracker
<http://bugs.python.org/issue13151>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13151] pysetup3 run bdist_wininst fails
Vinay Sajip added the comment:
> I don’t have Windows yet, so either we wait or we iterate I make a patch -
> you report failures - I make a patch etc.
Actually I'm finding these failures on Ubuntu :-)
Although there are MBCS encoding issues which will also need to be fixed before
you can build a pure-Python .exe installer on Linux (which is possible with
distutils, so should work in packaging too), these failures occur before you
get to that point. That last part can be fixed on Linux by doing (in
bdist_wininst.create_exe):
try:
cfgdata = cfgdata.encode("mbcs")
except LookupError:
cfgdata = cfgdata.encode("latin-1")
which is at least better than what we have now.
--
___
Python tracker
<http://bugs.python.org/issue13151>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12405] packaging does not record/remove directories it creates
Vinay Sajip added the comment: > If one project creates a/b/thing and another project uses > a/b/otherthing, then the directories would be recorded in the first > project’s RECORD, but they should be removed only when both projects > are removed. I'm not sure what you mean by "using". AFAIK, each distribution's files (recorded in RECORD) would be unique to that distribution (else distros like Debian will have problems, since files are owned by one package and one package only). I think all that is needed is as follows: 1. Record any directories that are created in RECORD, ideally bottom-up. 2. On uninstallation, remove all .pyc/.pyo files and __pycache__ directories, and remove all directories named in RECORD, unless they are non-empty (once .pyc/.pyo and __pycache__ are removed). If you are talking about dependencies between dependencies, I still don't see what your point is. IIUC, if distA depends on distB, distA's RECORD will contain all files which were installed as part of the installation of distA, and likewise for distB. -- ___ Python tracker <http://bugs.python.org/issue12405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12405] packaging does not record/remove directories it creates
Vinay Sajip added the comment: s/dependencies between dependencies/dependencies between distributions/ -- ___ Python tracker <http://bugs.python.org/issue12405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13182] pysetup run bdist_wininst does not work (tries to use "install" command)
Vinay Sajip added the comment: Closing as a duplicate of #13151, which also identifies other problems with this command. -- components: +Library (Lib) nosy: +vinay.sajip resolution: -> duplicate status: open -> closed superseder: -> pysetup3 run bdist_wininst fails ___ Python tracker <http://bugs.python.org/issue13182> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13175] packaging uses wrong line endings in RECORD files on Windows
Vinay Sajip added the comment: I'm trying to reproduce this too, but have failed so far. Which version(s) of Windows did the problems appear on? -- nosy: +vinay.sajip ___ Python tracker <http://bugs.python.org/issue13175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13172] pysetup run --list-commands fails with a traceback
Vinay Sajip added the comment: > so I guess that handling the issue gracefully isn't really important. Then should this issue be closed? -- nosy: +vinay.sajip ___ Python tracker <http://bugs.python.org/issue13172> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12406] msi.py needs updating for Python 3.3
Vinay Sajip added the comment: Another problem in creating the MSI is that Lib\test\keycert.passwd.pem and Lib\test\keycert.pem both lead to a short name of 'KEYCERT.PEM', which is causing an assertion failure in msilib.Directory.make_short(). The other clashing pair is Lib\test\ssl_key.passwd.pem and Lib\test\ssl_key.pem, at least at the moment, both of which map to 'SSL_KEY.PEM'. -- ___ Python tracker <http://bugs.python.org/issue12406> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12406] msi.py needs updating for Python 3.3
Vinay Sajip added the comment: I also noticed that subdirectories in packaging/tests/ need to be added (e.g. fake_dists), otherwise packaging tests fail when run in an installed Python. -- ___ Python tracker <http://bugs.python.org/issue12406> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12405] packaging does not record/remove directories it creates
Vinay Sajip added the comment: >s/directory that existed before Python was installed/directory that existed >before any distribution was installed/ IMO there is no need to remember any directory which isn't actually created by pysetup3. Deleting a __pycache__ in a directory created by pysetup3 would be implicit, and not need to be recorded. -- ___ Python tracker <http://bugs.python.org/issue12405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12405] packaging does not record/remove directories it creates
Vinay Sajip added the comment: > I did not propose such a thing. Sorry, I misunderstood your reference to /usr/lib/python2.7/site-packages. -- ___ Python tracker <http://bugs.python.org/issue12405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12405] packaging does not record/remove directories it creates
Vinay Sajip added the comment: > Let me rephrase my example with real paths. Okay, now I see what you're getting at. > Python creates /usr/lib/python3.3/site-packages. (I’ll call this $stdlib.) > > pysetup3.3 install paste.script creates $stdlib/paste/script/ and files > therein. The paste and paste/script directories are recorded. > > pysetup3.3 install PasteUtil creates $stdlib/paste/util/ and files therein. > Only the paste/script directory is recorded. I think you mean "Only the paste/util directory is recorded." > The $stdlib/paste directory is created by either distribution when it is > installed, but if it’s recorded only by one of the distributions, then it > can’t > be removed when the other distribution is removed last. This is the problem > I’m > seeing. Yes, it's a valid point. How about if you record all directories that you would create if they didn't exist, as well as those actually created? That way, you would record the paste directory under both distributions, but would only delete it when deleting the last distribution which uses it (paste/util in your example), because you're checking for emptiness (not including bytecode files and directories). -- ___ Python tracker <http://bugs.python.org/issue12405> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12174] Multiprocessing logging levels unclear
Vinay Sajip added the comment: > Should there be another issue opened to do something about the extra logging > levels? IMO they shouldn't have been added in the first place, but I'm not sure if they're part of the public API and hence subject to backward-compatibility constraints. It would be nice to hear a justification for them from Jesse (or someone else). Of course levels are a bit subjective and logging supports user-defined levels for special cases, but using multiple libs with different added levels would be a headache. I think at least the stdlib should stick to the standard levels. -- ___ Python tracker <http://bugs.python.org/issue12174> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13225] Failing packaging hooks should not stop operation
Vinay Sajip added the comment: > An option (--strict) would be needed to switch from logging messages to > exceptions; I wonder if an elegant way to do that would be a custom logging > handler. I'm not sure a custom logging handler is the way to go. I think it would be better to log the exception condition in all cases, raising it if --strict is specified, and swallowing it otherwise. An application developer can configure loggers/handlers appropriately if they want. -- ___ Python tracker <http://bugs.python.org/issue13225> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13232] Logging: Unicode Error
Vinay Sajip added the comment: Can you tell me what the actual data was which failed to be decoded? Is there more than one encoding in effect (e.g. one for the filesystem, and another for the other data in the exception being logged)? -- nosy: +vinay.sajip ___ Python tracker <http://bugs.python.org/issue13232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12915] Add inspect.locate and inspect.resolve
Vinay Sajip added the comment:
The version in logging.config appears to be doing the same job, but is shorter:
def _resolve(name):
"""Resolve a dotted name to a global object."""
name = name.split('.')
used = name.pop(0)
found = __import__(used)
for n in name:
used = used + '.' + n
try:
found = getattr(found, n)
except AttributeError:
__import__(used)
found = getattr(found, n)
return found
The line "used = used + '.' + n" could of course be improved.
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue12915>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13235] logging.warn() is not documented
Vinay Sajip added the comment: That's deliberate. The original code (before incorporation into Python) had warn(), which was kept for backward compatibility. The docs refer to warning() because that's what everyone is supposed to use. The method names map to the lower case of the appropriate logging level name. -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue13235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13235] logging.warn() is not documented
Vinay Sajip added the comment: It is deprecated by not being documented. It certainly isn't going to have documentation added for it. Which code was calling the warn() method? Is it not possible to change this to call warning()? - Original Message - > From: anatoly techtonik > To: vinay_sa...@yahoo.co.uk > Cc: > Sent: Thursday, 20 October 2011, 20:32 > Subject: [issue13235] logging.warn() is not documented > > > anatoly techtonik added the comment: > > I've got a traceback, because forgot to implement this method in logging > wrapper. It should be either deprecated and removed or documented. > > -- > status: closed -> open > > ___ > Python tracker > <http://bugs.python.org/issue13235> > ___ > -- ___ Python tracker <http://bugs.python.org/issue13235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13235] logging.warn() is not documented
Vinay Sajip added the comment: > Just to me it clear - why do you want warn() to be removed aside from code > duplication? > > My argument to leave it and document is that it is convenient and makes lines > shorter (and won't break existing code). From logging module I also see that > there are also logging.WARN aliases that you'll need to deprecate also. Sorry, I don't agree. I was happy to leave it as is until you raised this issue, but now I think the right thing to do is deprecate and remove warn(). I'm not too fussed about the WARN level, and I can't easily issue a deprecation warning for it as it's a module attribute, so I'll leave it in as an internal implementation detail, for which the usual caveats apply. -- ___ Python tracker <http://bugs.python.org/issue13235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13235] logging.warn() is not documented
Vinay Sajip added the comment: > BTW, you could have used a DeprecationWarning instead of a > PendingDeprecationWarning, especially if it was already deprecated. It wasn't officially deprecated, just "deprecation via obscurity";-) which is why I made it a PendingDeprecationWarning. -- ___ Python tracker <http://bugs.python.org/issue13235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13235] logging.warn() is not documented
Vinay Sajip added the comment: > PendingDeprecations are not so useful now that warnings are silenced by > default. > Since it wasn't documented, you could deprecate it in 3.3 and remove it in > 3.4 IMHO. Hmmm, you're probably right. I'll change it to a DeprecationWarning. -- ___ Python tracker <http://bugs.python.org/issue13235> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12406] msi.py needs updating for Python 3.3
Vinay Sajip added the comment: Adding Antoine for the short-name conflicts caused by the *.passwd.pem files. -- nosy: +pitrou ___ Python tracker <http://bugs.python.org/issue12406> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Vinay Sajip added the comment: FYI: In pythonv, the build_scripts functionality provides identical support for dotted callables to what Éric proposed, while preserving existing functionality for ordinary script files. Thus: scripts = demo1 demo2 = amodule.main demo3 = apackage.asubpackage.main gui copies demo1 (adjusting its shebang) and creates demo2 and demo3 from the dotted callables (using the appropriate shebang). While working on this, I came up against a problem with build_scripts in virtual environments: if I install a project into virtual env 1, then scripts are built with shebangs pointing to that env. If I then install the same project into virtual env 2, then the scripts are not re-created, so they would be installed into virtual env 2 with shebangs referencing virtual env 1. One solution is to set the force flag for virtual environments, but then if you later install into the system Python, then files with wrong shebangs could be installed there. I think the force flag should default to True for build_scripts; the extra script build time would be negligible except in pathological cases. Do you agree? -- ___ Python tracker <http://bugs.python.org/issue12394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Vinay Sajip added the comment: Re. the launcher changes, those improvements by Guy Rozendorn are welcome. I noticed some differences from the approach taken by Mark Hammond and Curt Hagenlocher in the PEP 397 implementation, which I ported to C: The Ctrl-C is ignored by the PEP 397 launcher. AFAICT it's passed to the child process anyway by Windows. The ignoring prevents the default behaviour (premature termination of the launcher). The PEP 397 launcher also duplicates the standard handles before creating the child process. The PEP 397 launcher also associates the launcher and the child together using the Job API. -- nosy: +guyrozendorn ___ Python tracker <http://bugs.python.org/issue12394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Vinay Sajip added the comment: > We’ll have to think about the shebang munging and decide if we keep it. I > think > recommending that people use “/usr/bin/env python” (or python3) and not doing > anything to the shebang may be the best thing. What about Windows support? Of course there is PEP 397 which brings shebang-line functionality to Windows, but that PEP has not yet been finalised. Without the existing shebang functionality, IMO there will be problems for Windows users with the “/usr/bin/env python” approach you suggest. -- ___ Python tracker <http://bugs.python.org/issue12394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Vinay Sajip added the comment: > >> What about Windows support? > Just like with distutils: the file extension is used, not the shebang. Please spell out for me how you see this working: I don't see it. Note that scripts have to use the correct Python even if they are invoked using an explicit path pointing into a virtual environment. -- ___ Python tracker <http://bugs.python.org/issue12394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Vinay Sajip added the comment: To expand on what I said about not seeing how things will work under Windows: are we going to place .exe launchers adjacent to the script, like setuptools does? If the script just has a shebang of "#!/usr/bin/env python", how is the launcher supposed to determine the exact Python to use from that, in a venv scenario where multiple Pythons will be installed? Scripts in virtual envs are supposed to run if invoked, even if the env is not on the PATH. -- ___ Python tracker <http://bugs.python.org/issue12394> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13303] Sporadic importlib failures: FileNotFoundError on os.rename()
Changes by Vinay Sajip : -- resolution: fixed -> ___ Python tracker <http://bugs.python.org/issue13303> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13303] Sporadic importlib failures: FileNotFoundError on os.rename()
Vinay Sajip added the comment: What's the downside of option 2) ? -- nosy: +vinay.sajip ___ Python tracker <http://bugs.python.org/issue13303> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13331] Packaging cannot install resource directory trees specified in setup.cfg
New submission from Vinay Sajip :
If setup.cfg contains a line such as
[files]
resources =
mydata/** = {purelib}
and the project contains a directory tree more than one level deep under
mydata, e.g.
mydata
|
+-mydata1
| |
| +-data1.dat
|
+-mydata2
|
+-data2.dat
then the parsing correctly identifies all the things to copy, but the
install_data step fails because it does not try to create intermediate
directories for mydata1, mydata2 but tries to copy them as files using
copy_file.
--
assignee: tarek
components: Distutils2, Library (Lib)
messages: 146917
nosy: alexis, eric.araujo, tarek, vinay.sajip
priority: high
severity: normal
status: open
title: Packaging cannot install resource directory trees specified in setup.cfg
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue13331>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13336] packaging.command.Command.copy_file doesn't implement preserve_mode and preserve_times
New submission from Vinay Sajip : The packaging.command.Command.copy_file method does not honour the preserve_mode and preserve_times keyword arguments. Likewise, packaging.command.Command.copy_tree does not honour the preserve_mode, preserve_times and preserve_symlinks keyword arguments. -- assignee: tarek components: Distutils2, Library (Lib) messages: 146957 nosy: alexis, eric.araujo, tarek, vinay.sajip priority: normal severity: normal status: open title: packaging.command.Command.copy_file doesn't implement preserve_mode and preserve_times versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13336> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13309] test_time fails: time data 'LMT' does not match format '%Z'
Vinay Sajip added the comment: It's not just Gentoo. I get this error repeatably on Ubuntu Oneiric 64- bit and Linux Mint Katya 64-bit, though not on the 32-bit variants. -- nosy: +vinay.sajip ___ Python tracker <http://bugs.python.org/issue13309> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13193] test_packaging and test_distutils failures
Vinay Sajip added the comment:
I get the opposite failure to Nadeem as far as
InstallDataTestCase.test_resources: it works on Ubuntu 64-bit, but fails on
32-bit. Digging into it a bit further, I find that _generate_cache in
Lib/packaging/database.py returns prematurely in the failing case, because
_cache_generated_egg is True in the failing case but not in the test run which
succeeds. My guess is that this could be due to a missing call to clear_cache()
in the same module, as _cache_generated_egg is set to True only in the last
part of _generate_cache, and my guess is that the value is a holdover from an
earlier test.
If I add the line "packaging.database.clear_cache()" just above "with
packaging.database.get_file('Spamlib', 'spamd') as fp:" then the test succeeds.
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue13193>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
