Baby Babbeh posted:

I use .format() probably way more than I should, so I'm pretty hyped for f-strings. Can't wait to write the lovely, un-maintainable code ya'll are talking about.

Boris Galerkin posted:

I'm trying to learn/use Sphinx but I swear every single tutorial I've found is completely worthless and leaves more questions than answers. For example I just want to do something simple like this:
*snip*

Master_Odin posted:

Are f-strings going to be back ported in some way to older versions of Python or is it 3.6 only?

Boris Galerkin posted:

I'm trying to learn/use Sphinx but I swear every single tutorial I've found is completely worthless and leaves more questions than answers. For example I just want to do something simple like this:

code:

def foo():
    """Some information about this function."""

    ...

    # Something very important about the next line:
    two = 1 + 1

    ....

    return two

I can get Sphinx to generate documentation for foo() containing that bit in the """ """, but I want it to include also the comments in #. How can I do that?

Another seemingly simple but difficult thing I want to do is something like: I have a dict with some parameters. I want sphinx to document each key, and I want it to take whatever I already wrote in inline comments.

code:

some_dict_of_parameters = {
    'a_flag':          #< `a_flag` controls something and does something else
        True,        
    'some_other_flag': #< `some_other_flag` controls the blah blah blah.
        False,
}

In doxygen I think I could do this with the #< (or eg !< for fortran) like I show. I want a similar feature in sphinx because the other alternatives I can think of is copying and pasting all the keys into a docstring placed above/after that dictionary and that's just stupid.

HardDiskD posted:

Do you know any OSS project that does what you want in their documentation? I never came across this before.

accipter posted:

Have you taken a look at autodata (need to scroll down to autodata). You can do the following:

Python code:

class Foo:
    """Docstring for class Foo."""

    #: Doc comment for class attribute Foo.bar.
    #: It can have multiple lines.
    bar = 1

    flox = 1.5   #: Doc comment for Foo.flox. One line only.

    baz = 2
    """Docstring for class attribute Foo.baz."""

    def __init__(self):
        #: Doc comment for instance attribute qux.
        self.qux = 3

        self.spam = 4
        """Docstring for instance attribute spam."""

Feral Integral posted:

Is the f-string thing just a shorthand for .format()?

Boris Galerkin posted:

Yes, doxygen lets me do this. For example in fortran syntax, I can do normal comments that won't show up in the auto generated documentation with the normal '!' prefix, but I can also choose to use '!<' and doxygen will include that particular comment line. For my second example, standard fortran doesn't really have dicts so you could use something like a derived type or whatever.

code:

type :: parameters
     int :: a_flag !> info about this flag
     int :: a_different_flag !> info about this one

     ! this is a regular comment like that doxygen will ignore

end type parameters

And in the documentation it automagically documents each member "key" without me having to copy and paste it and put it all into a docstring.

Boris Galerkin posted:

Hmm ok, will try this again tomorrow. I did some searching and i did see some examples using the "#: etc" syntax and I tried it, but it did nothing. Does "autodata" not get enabled by default? Is being able to explicitly tell sphinx to put this comment line in the documents not a common thing for python developers?

accipter posted:

Usage guidance is really meant to go into the docstring. Comments are there to help the understand the code, and shouldn't really be separated from the code.

If you want to have the autodata fields show up, you have to request them in the .rst files, or modify the autosummary templates to include the information by default.

Boris Galerkin posted:

It's starting to sound like sphinx isn't the right tool for this case then. Not knocking on it, but in this case I don't want to separate usage vs what the code does because the developers are going to be the only users. I want high level information (this function solves df(x)/dx = exp(a(x)*q(x) - 1), where a(x) = ...) but I also want selected comments to appear both in the documentation with latex or latex like rendered math that show what I actually implemented/am solving since the actual equation implemented might not resemble the one in the docstring, and for it to appear in the code next to the relevant lines.

accipter posted:

You can definitely make Sphinx work for what you want to do, but it isn't standard practice.

accipter posted:

You can definitely make Sphinx work for what you want to do, but it isn't standard practice. The biggest issue that I see with what you are trying to do is that including a # comment in the documentation seems worthless to me without the code associated with that comment. If you agree, then it would be easy to include links to highlighted source code using sphinx.ext.viewcode. This would allow a user to browse the API and readily access the source code to see implementation. If you are set on including some # comments within the generated documentation that is possible with Sphinx and how you accomplish that depends on how you are generating the documentation. If you are using autodoc and/or autosummary, you need to modify the templates to include the autodata field. This would take about 10 minutes to modify the templates.

BigRedDot posted:

Anyway, it sort of sounds like you are looking for a "literate programming" tool for Python. If that's the case you might find Pycco more suited.

Eela6 posted:

https://www.youtube.com/watch?v=EEUXKG97YRw

Thermopyle posted:

Hey BigRedDot: I just noticed the link to the weather source code here goes to a 404 on Github.

QuarkJets posted:

What's the word on fastest plotting in Python? I read that matplotlib with the TkAgg backend is probably the fastest way to dump plots, does anyone know for sure?

Baby Babbeh posted:

What's the point of that? Is Go concurrency really that much better than asyncio that you'd give up access to some of python's most powerful libraries to use it?

Cingulate posted:

Shouldn't this work?

code:

$python --version
Python 3.5.2 :: Anaconda custom (x86_64)

$conda install python=3.6
Fetching package metadata ...........
Solving package specifications: ....


UnsatisfiableError: The following specifications were found to be in conflict:
  - conda -> python 2.7*|3.3*|3.4*|3.5*
  - python 3.6*
Use "conda info <package>" to see the dependencies for each package.

Thermopyle posted:

Eela6 posted:

Thermopyle posted:

I'd really like to see some more in-depth discussion of this.

I mean, they'd have to move to Python 3+ to get asyncio, but it seems like that'd be less work than what they did, so maybe Go concurrency really is that much better? Also, there's other lightweight thread alternatives like eventlet/gevent...

Of course, Google also has a real hard-on for Go, so maybe it's just the new and shiny factor?

Dex posted:

from some stuff i looked at last year, go's concurrency for cpu intensive threads was around 50x cpython's. however, go has some seriously nasty leaks that are completely beyond your ability to control, so you will almost certainly end up with memory issues that are near impossible to isolate, so if you have even the slightest reason to care about memory consumption, it seems like a terrible choice

i'd aim for pypy before running python in go if i was willing to make tradeoffs on certain libs since it's apparently significantly more performant than cpython, but i don't actually need to so i've only done some light reading on it

Cingulate posted:

Ah okay, thanks. I will just wait then.

I didn't want to make a new env because I have tons of packages and I don't think there is a simple way of migrating my py3.5 packages to a py3.6 env right?

Munkeymon posted:

I bet it's more work to take a big codebase like YouTube to 3+ than to write a compiler that'll drop-in replace 2.