| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
| |
Fixing backwards compatibility bug introduced in commit
254494c, which broke support for Python 3.4 when passing
the builtin method 'mro' of 'type' objects to
'inspect.signature', raising a 'ValueError'.
|
| |\
| |
| | |
ENH: better error messages from NumpyDocString
|
| | |
| |
| |
| |
| | |
make html wouldn't say where the error originates. This way, we get
at least a hint.
|
| |/ |
|
| | |
|
| |\
| |
| | |
ENH : NumpyDocString subclass collections.Mapping
|
| | |
| |
| |
| |
| |
| | |
Sub-classing `collections.Mapping` and providing a __iter__ and __len__
methods (completely delegated to _parsed_data) makes NumpyDocString
behave as a dictionary with fixed keys.
|
| |\ \
| |/
|/| |
ENH: support Yields section
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
| |
enables showing of inherited class members in the docs. The option has enabled by default.
|
| | |
|
| |
|
|
| |
AttributeError on Pandas.str
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Developers usually only need the type of a return value
followed by a brief description. However, in some cases
providing a name for a return value can make the documentation
clearer. This enhancement changes the format of the Returns
section such that the type is required, and the name is
optional:
Returns
-------
int
Description of anonymous integer return value.
x : str
Description of string return value named `x`.
With this change, if a colon is not present, then the entire
line is interpreted as the return type. In all other cases,
the Returns section is interpreted according to the current
rules.
Consistent with the current format, if a colon is present, then
the text to the left of the colon is interpreted as the name;
and the text to the right of the colon is interpreted as the
type. This makes the proposed change backwards compatible with
existing documentation.
|
| |
|
|
|
|
|
| |
Add `print_function` to all `from __future__ import ...` statements
and use the python3 print function syntax everywhere.
Closes #3078.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `imports` fixer deals with the standard packages that have been
renamed, removed, or methods that have moved.
cPickle -- removed, use pickle
commands -- removed, getoutput, getstatusoutput moved to subprocess
urlparse -- removed, urlparse moved to urllib.parse
cStringIO -- removed, use StringIO or io.StringIO
copy_reg -- renamed copyreg
_winreg -- renamed winreg
ConfigParser -- renamed configparser
__builtin__ -- renamed builtins
In the case of `cPickle`, it is imported as `pickle` when python < 3 and
performance may be a consideration, but otherwise plain old `pickle` is
used.
Dealing with `StringIO` is a bit tricky. There is an `io.StringIO`
function in the `io` module, available since Python 2.6, but it expects
unicode whereas `StringIO.StringIO` expects ascii. The Python 3
equivalent is then `io.BytesIO`. What I have done here is used BytesIO
for anything that is emulating a file for testing purposes. That is more
explicit than using a redefined StringIO as was done before we dropped
support for Python 2.4 and 2.5.
Closes #3180.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new import `absolute_import` is added the `from __future__ import`
statement and The 2to3 `import` fixer is run to make the imports
compatible. There are several things that need to be dealt with to make
this work.
1) Files meant to be run as scripts run in a different environment than
files imported as part of a package, and so changes to those files need
to be skipped. The affected script files are:
* all setup.py files
* numpy/core/code_generators/generate_umath.py
* numpy/core/code_generators/generate_numpy_api.py
* numpy/core/code_generators/generate_ufunc_api.py
2) Some imported modules are not available as they are created during
the build process and consequently 2to3 is unable to handle them
correctly. Files that import those modules need a bit of extra work.
The affected files are:
* core/__init__.py,
* core/numeric.py,
* core/_internal.py,
* core/arrayprint.py,
* core/fromnumeric.py,
* numpy/__init__.py,
* lib/npyio.py,
* lib/function_base.py,
* fft/fftpack.py,
* random/__init__.py
Closes #3172
|
| |
|
|
|
|
|
|
| |
This should be harmless, as we already are division clean. However,
placement of this import takes some care. In the future a script
can be used to append new features without worry, at least until
such time as it exceeds a single line. Having that ability will
make it easier to deal with absolute imports and printing updates.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were some conflicts with the 2to3 work in numpy. I think I got the
fixes right.
* enh-numpydoc:
DOC: fix doc/source/conf.py to work with Python 3
BUG: numpydoc: check that it works with sub-classes
TST: numpydoc: more class tests
BUG: numpydoc: fix bugs in attribute docstring extraction + improve presentation
TST: numpydoc: add stub test files, to check that files at least import
MAINT: always use plot directive from Matplotlib, and prefer Sphinx linkcode
ENH: numpydoc: Python 2 & 3 in single codebase, restructure as a package
ENH: numpydoc: deal with duplicated signatures
DOC: numpydoc/linkcode: mention that the extension will be in Sphinx upstream
BUG: numpydoc/linkcode: do not detect linkcode config changes
Conflicts:
doc/sphinxext/numpydoc/docscrape.py
doc/sphinxext/numpydoc/docscrape_sphinx.py
doc/sphinxext/numpydoc/linkcode.py
doc/sphinxext/numpydoc/phantom_import.py
doc/sphinxext/numpydoc/traitsdoc.py
|
| | |
|
| | |
|
| |
|
