NiklasRosenstein / pydoc-markdown

Create Python API documentation in Markdown format.
http://niklasrosenstein.github.io/pydoc-markdown/
Other
458 stars 103 forks source link

Inline Python code ends up at different position #308

Closed s-martin closed 9 months ago

s-martin commented 9 months ago

Environment

Describe the bug

When I use code examples following markdown syntax within the docstring the generated markdown file puts the code at the end of the chapter.

I use this docstring:

The code sample at the first example is formatted using regular markdown syntax (```python

"""
A plugin package with some special functionality

Plugins packages are python packages that are dynamically loaded. From these packages only a subset of objects is exposed
through the plugs.call interface. The python packages can use decorators or dynamic function call to register (callable)
objects.

The python package name may be different from the name the package is registered under in plugs. This allows to load different
python packages for a specific feature based on a configuration file. Note: Python package are still loaded as regular
python packages and can be accessed by normal means

If you want to provide additional functionality to the same feature (probably even for run-time switching)
you can implement a Factory Pattern using this package. Take a look at volume.py as an example.

**Example:** Decorate a function for auto-registering under it's own name:

```python
    import jukebox.plugs as plugs
    @plugs.register
    def func1(param):
        pass

Example: Decorate a function for auto-registering under a new name::

@plugs.register(name='better_name')
def func2(param):
    pass

Example: Register a function during run-time under it's own name::

def func3(param):
    pass
plugs.register(func3)

Example: Register a function during run-time under a new name::

def func4(param):
    pass
plugs.register(func4, name='other_name', package='other_package')

Example: Decorate a class for auto registering during initialization, including all methods (see _register_class for more info)::

@plugs.register(auto_tag=True)
class MyClass1:
    pass

Example: Register a class instance, from which only report is a callable method through the plugs interface::

class MyClass2:
    @plugs.tag
    def report(self):
        pass
myinst2 = MyClass2()
plugin.register(myinst2, name='myinst2')

Naming convention:

package

  1. Either a python package
  2. or a plugin package (which is the python package but probably loaded under a different name inside plugs)

plugin

  1. An object from the package that can be accessed through the plugs call function (i.e. a function or a class instance)
  2. The string name to above object

name The string name of the plugin object for registration

method

  1. In case the object is a class instance a bound method to call from the class instance
  2. The string name to above object

"""


This results in the following markdown code:

The code sample from above is missing at **Example**, but shown at the very end.

jukebox.plugs

A plugin package with some special functionality

Plugins packages are python packages that are dynamically loaded. From these packages only a subset of objects is exposed through the plugs.call interface. The python packages can use decorators or dynamic function call to register (callable) objects.

The python package name may be different from the name the package is registered under in plugs. This allows to load different python packages for a specific feature based on a configuration file. Note: Python package are still loaded as regular python packages and can be accessed by normal means

If you want to provide additional functionality to the same feature (probably even for run-time switching) you can implement a Factory Pattern using this package. Take a look at volume.py as an example.

Example: Decorate a function for auto-registering under it's own name:

Example: Decorate a function for auto-registering under a new name::

@plugs.register(name='better_name') def func2(param): pass

Example: Register a function during run-time under it's own name::

def func3(param): pass plugs.register(func3)

Example: Register a function during run-time under a new name::

def func4(param): pass plugs.register(func4, name='other_name', package='other_package')

Example: Decorate a class for auto registering during initialization, including all methods (see _register_class for more info)::

@plugs.register(auto_tag=True) class MyClass1: pass

Example: Register a class instance, from which only report is a callable method through the plugs interface::

class MyClass2: @plugs.tag def report(self): pass myinst2 = MyClass2() plugin.register(myinst2, name='myinst2')

Naming convention:

package

  1. Either a python package
  2. or a plugin package (which is the python package but probably loaded under a different name inside plugs)

plugin

  1. An object from the package that can be accessed through the plugs call function (i.e. a function or a class instance)
  2. The string name to above object

name The string name of the plugin object for registration

method

  1. In case the object is a class instance a bound method to call from the class instance
  2. The string name to above object
    import jukebox.plugs as plugs
    @plugs.register
    def func1(param):
        pass


**Expected behavior**

I would expect that the code sample remains at the correct position withion the docstring documentation.

A clear and concise description of what you expected to happen.
s-martin commented 9 months ago

Ok, found the problem.

Needed to explicitly specify - type: sphinx as processor. Afterwards I had to use rst syntax for code samples (identation)