Re: [Python-Dev] [Python-checkins] cpython: Fix syntax in packaging docs and update suspicious ignore file.
> changeset: 71283:3a4b983dd70b > user:Georg Brandl > summary: > Fix syntax in packaging docs and update suspicious ignore file. > > files: > Doc/library/packaging.compiler.rst | 2 +- > Doc/packaging/builtdist.rst | 2 +- > Doc/packaging/commandref.rst | 2 +- Thanks for the fixes, Georg. I fix problems when I get warnings, but these fell through. Maybe you used a special command line to find those? > Doc/tools/sphinxext/susp-ignored.csv | 27 ++- I’ve always wondered about that file’s role, and I’ve finally found answers in Doc/tools/sphinxext/suspicious.py. Should we update this file when we get suspicious output? Does using “.. block-code:: none” prevent program output from appearing as suspicious? Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Fix syntax in packaging docs and update suspicious ignore file.
Am 12.07.2011 15:30, schrieb Éric Araujo:
>> changeset: 71283:3a4b983dd70b
>> user:Georg Brandl
>> summary:
>> Fix syntax in packaging docs and update suspicious ignore file.
>>
>> files:
>> Doc/library/packaging.compiler.rst | 2 +-
>> Doc/packaging/builtdist.rst | 2 +-
>> Doc/packaging/commandref.rst | 2 +-
>
> Thanks for the fixes, Georg. I fix problems when I get warnings, but
> these fell through. Maybe you used a special command line to find those?
Yes: "make suspicious" in the Doc directory invokes the special builder that
looks for things that look like reST markup in the output, where it shouldn't
occur. This is a routine step in PEP 101, so it will be done before every
release.
>> Doc/tools/sphinxext/susp-ignored.csv | 27 ++-
>
> I’ve always wondered about that file’s role, and I’ve finally found
> answers in Doc/tools/sphinxext/suspicious.py. Should we update this
> file when we get suspicious output? Does using “.. block-code:: none”
> prevent program output from appearing as suspicious?
No (and neither do normal code blocks). That is one thing that should be
improved in the builder: the content of code blocks ("literal" nodes in
docutils) shouldn't be checked.
Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of absolute_import w/ python 2.7
On Fri, Jul 8, 2011 at 06:51, Sylvain Thénault wrote: > Hi there, > > the documentation state that absolute_import feature is the default > behaviour with python 2.7, though it seems that it behave differently > with the __future__ import : > > $ cat package/__init__.py > > import subpackage > > $ python2.7 > Python 2.7.1+ (default, Apr 20 2011, 22:33:39) > [GCC 4.5.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import package > >>> > > $ cat package/__init__.py > > from __future__ import absolute_import > import subpackage > > $ python2.7 > Python 2.7.1+ (default, Apr 20 2011, 22:33:39) > [GCC 4.5.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import package > Traceback (most recent call last): > File "", line 1, in > File "package/__init__.py", line 23, in >import subpackage > ImportError: No module named subpackage > So are you claiming that the import of 'package' w/o the __future__ statement actually succeeds even though there is no package.subpackage module? Obviously that would be a flat-out bug, but I just double-checked my sanity and that does nto work with a CPython 2.7 checkout. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] status of absolute_import w/ python 2.7
On Wed, Jul 13, 2011 at 1:41 PM, Brett Cannon wrote: > So are you claiming that the import of 'package' w/o the __future__ > statement actually succeeds even though there is no package.subpackage > module? Obviously that would be a flat-out bug, but I just double-checked my > sanity and that does nto work with a CPython 2.7 checkout. No, the problem is that __future__.absolute_import claims to be the default behaviour in 2.7, but this does not appear to actually be the case - it still tries the implicit relative import. E.g, given the following setup: cwd /package /__init__.py /submodule.py /submodule2.py an "import submodule" in __init__.py or submodule2.py will succeed. Now, the what's new for 2.7 doesn't actually *say* we made that change and I can't find any evidence for it in NEWS either, so I think the bug is actually in the __future__ module (and docs: http://docs.python.org/library/__future__). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
