Re: Any ReST aware editors?

[Yann Kaiser]

Does that work with with ReST?

On Thu, Sep 22, 2016, 12:59 Jon Ribbens  wrote:

> On 2016-09-22, Steve D'Aprano  wrote:
> > I have editors which will use syntax highlighting on .rst files, but I'm
> > hoping for something a bit smarter.
> >
> > What I'd like is an editor with a split window, one side showing the rst
> > that I can edit, the other side showing the formatted text updated as I
> > type. (Or at least, updated every thirty seconds or so.)
> >
> > Anybody know anything like that?
>
> There's dillinger.io if online is ok.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
Yann Kaiser
kaiser.y...@gmail.com
yann.kai...@efrei.net
+33 6 51 64 01 89
https://github.com/epsy
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sphinx (or other means to document python)

[Yann Kaiser]

pydoctor may be something you're looking for. I don't know if it supports
exporting to PDF like Sphinx does.

As you've no doubt figured out by now, Sphinx doesn't revolve around the
Python files themselves, but rather .rst files in which you can indeed
instruct Sphinx to just go and document a module.

On Sun, Sep 25, 2016, 02:26  wrote:

> On Sunday, September 11, 2016 at 3:56:36 PM UTC-5, chit...@uah.edu wrote:
> (about being frustrated with sphinx)
>
> I _remain_ frustrated - even as I finally figured out how to use it
> (thanks to a complete example from a friend)
>
> sphinx is very picky about spaces, lines - I had a line with some math
> formula spaces and tabs (after r''' - and sphinx kept ignoring that line
>
> when it works, the documentation (my preference is LaTeX) is great - the
> procedure for embedding the documentation as doctrings can be difficult, at
> times
>
> noweb is considerably simpler - but does not allow for the extraction
> of docstrings/comments - and does provide for a fairly painless way to
> combine comments, documentation along with code
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
Yann Kaiser
kaiser.y...@gmail.com
yann.kai...@efrei.net
+33 6 51 64 01 89
https://github.com/epsy
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to reduce the DRY violation in this code

[Yann Kaiser]

You could use `attrs` for this along with the convert option, if you're
open to receiving mixed arguments:

>>> @attr.s
... class C(object):
... x = attr.ib(convert=int)
>>> o = C("1")
>>> o.x
1

https://attrs.readthedocs.io/en/stable/examples.html#conversion

On Tue, Sep 27, 2016, 16:51 Steve D'Aprano 
wrote:

> I have a class that takes a bunch of optional arguments. They're all
> optional, with default values of various types. For simplicity, let's say
> some are ints and some are floats:
>
>
> class Spam:
> def __init__(self, bashful=10.0, doc=20.0, dopey=30.0,
>  grumpy=40, happy=50, sleepy=60, sneezy=70):
> # the usual assign arguments to attributes dance...
> self.bashful = bashful
> self.doc = doc
> # etc.
>
>
> I also have an alternative constructor that will be called with string
> arguments. It converts the strings to the appropriate type, then calls the
> real constructor, which calls __init__. Again, I want the arguments to be
> optional, which means providing default values:
>
>
> @classmethod
> def from_strings(cls, bashful='10.0', doc='20.0', dopey='30.0',
>  grumpy='40', happy='50', sleepy='60', sneezy='70'):
> bashful = float(bashful)
> doc = float(doc)
> dopey = float(dopey)
> grumpy = int(grumpy)
> happy = int(happy)
> sleepy = int(sleepy)
> sneezy = int(sneezy)
> return cls(bashful, doc, dopey, grumpy, happy, sleepy, sneezy)
>
>
> That's a pretty ugly DRY violation. Imagine that I change the default value
> for bashful from 10.0 to (let's say) 99. I have to touch the code in three
> places (to say nothing of unit tests):
>
> - modify the default value in __init__
> - modify the stringified default value in from_strings
> - change the conversion function from float to int in from_strings
>
>
> Not to mention that each parameter is named seven times.
>
>
> How can I improve this code to reduce the number of times I have to repeat
> myself?
>
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
Yann Kaiser
kaiser.y...@gmail.com
yann.kai...@efrei.net
+33 6 51 64 01 89
https://github.com/epsy
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to compile this code

[Yann Kaiser]

You want to replace the `Add` ast with a `Call` ast rather than just
calling your function.

Something like:

if isinstance(node.op, ast.Add):
return ast.Call(some_ast_expression_that_will_evaluate_to_op,
[node.left, node.right], [])

You'll have to replace some_ast_expression_... to something like
Name(id="op2", ctx=ast.Load()) and inject op2 in the globals when you call
`exec`.

On Tue, Nov 1, 2016, 06:36 meInvent bbird  wrote:

> would like to change Add operator to custom function op2 in solve function
> and then this solve([x*y - 1, x + 2], x, y)
> during solve, the parameters also change Add to custom function op2
>
> import ast
> from __future__ import division
> from sympy import *
> x, y, z, t = symbols('x y z t')
> k, m, n = symbols('k m n', integer=True)
> f, g, h = symbols('f g h', cls=Function)
> import inspect
>
> def op2(a,b):
> return a*b+a
>
> class ChangeAddToMultiply(ast.NodeTransformer):
> """Wraps all integers in a call to Integer()"""
> def visit_BinOp(self, node):
> print(dir(node))
> print(dir(node.left))
> if isinstance(node.op, ast.Add):
> node.op = op2(node.left, node.right)
> return node
>
> code = inspect.getsourcelines(solve)
> tree = ast.parse(code)
> tree = ChangeAddToMultiply().visit(tree)
> ast.fix_missing_locations(tree)
> co = compile(tree, '', "exec")
>
> exec(code)
> exec(co)
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
Yann Kaiser
kaiser.y...@gmail.com
yann.kai...@efrei.net
+33 6 51 64 01 89
https://github.com/epsy
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A problem with classes - derived type

[Yann Kaiser]

If you can't change A to use something like "type(self)(...)" to create its
return value, you could use the dark side and swap res's __class__:

res.__class__ = B

Or:

res.__class__ = type(self)

Do note that B.__init__ will not be run when you do this, so it is up to
you to execute any additional initialization B might require.

Alternatively if it makes sense for you you can call B's methods on an A
object like so:

B.b_method(a_object, ...)

On Mon, 9 May 2016 at 06:26 Paulo da Silva 
wrote:

> Hi!
>
> Suppose I have a class A whose implementation I don't know about.
> That class A has a method f that returns a A object.
>
> class A:
> ...
> def f(self, <...>):
> ...
>
> Now I want to write B derived from A with method f1. I want f1 to return
> a B object:
>
> class B(A):
> ...
> def f1(self, <...>):
> ...
> res=f(<...>)
>
> How do I return res as a B object?
>
> Thanks.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
Yann Kaiser
kaiser.y...@gmail.com
yann.kai...@efrei.net
+33 6 51 64 01 89
https://github.com/epsy
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Same function but different names with different set of default arguments

[Yann Kaiser]

partial treats keyword arguments as default values, though they become
keyword-only as a result :

f1 = functools.partial(g, p="p1")

On Thu, Jan 21, 2016, 08:35 Paulo da Silva 
wrote:

> Hi all.
>
> What is the fastest implementation of the following code?
>
> def g(p):
> ...
> return something
>
> def f1(p="p1"):
> return g(p)
>
> def f2(p="p2"):
> return g(p)
>
> Thanks
> Paulo
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to simulate C style integer division?

[Yann Kaiser]

You can use the // operator, which should do what you want.

On Thu, Jan 21, 2016, 09:40 Shiyao Ma  wrote:

> Hi,
>
> I wanna simulate C style integer division in Python3.
>
> So far what I've got is:
> # a, b = 3, 4
>
> import math
> result = float(a) / b
> if result > 0:
>   result = math.floor(result)
> else:
>   result = math.ceil(result)
>
>
> I found it's too laborious. Any quick way?
>
> --
>
> 吾輩は猫である。ホームーページはhttps://introo.me 。
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Same function but different names with different set of default arguments

[Yann Kaiser]

Apparently the thread poster cannot receive email, I just received a bounce
on my previous email :-/

On Thu, Jan 21, 2016, 08:49 Yann Kaiser  wrote:

> partial treats keyword arguments as default values, though they become
> keyword-only as a result :
>
> f1 = functools.partial(g, p="p1")
>
> On Thu, Jan 21, 2016, 08:35 Paulo da Silva <
> p_s_d_a_s_i_l_v_a...@netcabo.pt> wrote:
>
>> Hi all.
>>
>> What is the fastest implementation of the following code?
>>
>> def g(p):
>> ...
>> return something
>>
>> def f1(p="p1"):
>> return g(p)
>>
>> def f2(p="p2"):
>> return g(p)
>>
>> Thanks
>> Paulo
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Clize 3.0b1: An argument parser that draws a CLI from your function sigature

[Yann Kaiser]

Hello everyone!

After a few years in development, I am proud to say Clize is landing its
feet again and is now in beta for an upcoming release.

You can try it out usingpip install --user clize=3.0b1and you can
browse the docs athttps://clize.readthedocs.org/

For those who'd like an explanation before clicking links, here's Clize's
5-bullet point explanation:

* Command-line interfaces are created by passing functions to `clize.run`.
* Parameter types are deduced from the functions' parameters.
* A ``--help`` message is generated from your docstrings. (Why does this
still need to be a bullet point?)
* Decorators can be used to reuse functionality across functions.
* Clize can be extended with new parameter behavior.

I am primarily looking for feedback on the documentation contents, and I
need to source a FAQ page, but any feedback is welcome!

If you are into that sort of thing, I've also just set up a G+ community
for it at: https://plus.google.com/communities/10114600650079362
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Clize 3.0b1: An argument parser that draws a CLI from your function sigature

[Yann Kaiser]

On Mon, 27 Apr 2015 at 20:28 Chris Angelico  wrote:

> On Tue, Apr 28, 2015 at 12:45 PM, Yann Kaiser 
> wrote:
> > On Mon, 27 Apr 2015 at 17:04 Chris Angelico  wrote:
> >> Interesting. I've also been working on a simpler arg handling module;
> >> maybe we can work together. The goals for mine are:
> >>
> >> * Each function should be as independent as possible.
> >
> >
> > In Clize, commands are also just regular functions which have the desired
> > amount of keyword-only parameters and annotations. They can still be run
> > individually, be tested, and so forth.
>
> To implement something like the examples I gave, though, you'd need to
> enumerate the subcommand functions at the end. I'd like to be able to
> not do that.
>
> My inspiration came partly from Flask. I can build up a web site with
> several separate files, where one file might define routes for all the
> human-accessible content (the stuff that's designed for a web browser)
> and a separate file could define the API endpoints (emitting JSON or
> something). There's no need to have a single gathering point that
> lists every function that needs to be called - they get squirreled
> away by the decorator.
>

I'm aware of the pattern, and I don't really like it, especially because it
gets weird when multiple modules are involved. You'd have to import modules
because they have a side-effect of adding stuff to a list rather than
import things so that you can put them in a list. In addition, if Clize
manages that list, it will be a global mutable object to take care of in
tests and so forth. That'll be rather yucky.
I like the straightforwardness of "names are imported or defined" -> "names
are passed to run" (what is passed to run *is* what you get) rather than
names are collected as side effect of this and that import then run looks
at them (well, I could explore what all those imports are doing...).

>> * Minimize repetition (of names, descriptions, etc)
> >
> >
> > I try to minimize repetition, but the reality of things is that a
> parameter
> > name could be repeated up to 4 times in Clize:
> >
> > * In the function's parameter list
> > * In the function's docstring
> > * If named explicitly, in a @-kwoargs decorator (not needed with Py3)
> > * In an annotate decorator (again, not needed with Py2 compatibility
> isn't
> > desired)
> >
> > Two of these wouldn't be relevant in a Python 3-only world (if it's just
> a
> > shell script replacement, you can probably pretend to be in one for a
> > moment), the remainder being normal things in a function. So I'm not
> doing
> > too badly there. Descriptions are of course only written in the
> description
> > :-)
>
> A lot of my projects are Py3-only. I have no problem with that.
>
> >> * Keep everything in the function signature
> >
> > I started taking this at heart with 3.0, after seeing the rather
> disgusting
> > constructs that had to be used in Clize 2.x for specifying aliases and
> value
> > converters. Now everything is annotations. Nothing in the docstring
> > specifies behavior, and it isn't even read at all until --help is
> triggered.
> > I intend to keep docstrings behavior-free because, well, they're strictly
> > for documentation IMO.
> >
> > What I mean to say, is that I am definitely committed to keeping
> everything
> > in the function signature. Probably even more than you :-)
>
> :)
>
> There's a spectrum of convenience:
>
> 1) The actual function signature - information that already exists.
> Function and parameter names, basically.
> 2) Annotations, directly attached to the parameters.
> 3) Docstrings and decorators, adjacent to the 'def' statement.
> 4) Code elsewhere in the file.
> 5) Code or directives in a separate file.
>
> Some of Clize stretches as far as level 4, and that's what I'd like to
> pull up a bit. With docstringargs, the only things at level 4 are
> generic setup - importing the module (unavoidable) and "if name is
> main, do stuff" (also unavoidable unless you want to put in some major
> MAJOR magic).
>
> (I took this spectrum from the discussions surrounding PEP 484,
> incidentally. I'm sure you won't be even *considering* having crucial
> command-line parsing out in a separate file, but that's precisely what
> type-hint stub files are.)
>
> >> There's a demo file in the source repo, plus here are a couple of
> >> actual usage examples:
> >>
> >> https://github.com/Rosuav/Let

Re: Clize 3.0b1: An argument parser that draws a CLI from your function sigature

[Yann Kaiser]

On Mon, 27 Apr 2015 at 17:04 Chris Angelico  wrote:

> On Mon, Apr 27, 2015 at 7:02 PM, Yann Kaiser 
> wrote:
> > Hello everyone!
> >
> > After a few years in development, I am proud to say Clize is landing its
> > feet again and is now in beta for an upcoming release.
> >
> > You can try it out usingpip install --user clize=3.0b1and you can
> > browse the docs athttps://clize.readthedocs.org/
> >
> > For those who'd like an explanation before clicking links, here's Clize's
> > 5-bullet point explanation:
> >
> > * Command-line interfaces are created by passing functions to
> `clize.run`.
> > * Parameter types are deduced from the functions' parameters.
> > * A ``--help`` message is generated from your docstrings. (Why does this
> > still need to be a bullet point?)
> > * Decorators can be used to reuse functionality across functions.
> > * Clize can be extended with new parameter behavior.
>
> Interesting. I've also been working on a simpler arg handling module;
> maybe we can work together. The goals for mine are:
>
> * Each function should be as independent as possible.
>

In Clize, commands are also just regular functions which have the desired
amount of keyword-only parameters and annotations. They can still be run
individually, be tested, and so forth.


> * Minimize repetition (of names, descriptions, etc)
>

I try to minimize repetition, but the reality of things is that a parameter
name could be repeated up to 4 times in Clize:

* In the function's parameter list
* In the function's docstring
* If named explicitly, in a @-kwoargs decorator (not needed with Py3)
* In an annotate decorator (again, not needed with Py2 compatibility isn't
desired)

Two of these wouldn't be relevant in a Python 3-only world (if it's just a
shell script replacement, you can probably pretend to be in one for a
moment), the remainder being normal things in a function. So I'm not doing
too badly there. Descriptions are of course only written in the description
:-)

In addition, I took up the goal of helping minimize repetition in client
code behavior through better support for decorators (which is really cool,
by the way!)


> * Keep everything in the function signature
>

I started taking this at heart with 3.0, after seeing the rather disgusting
constructs that had to be used in Clize 2.x for specifying aliases and
value converters. Now everything is annotations. Nothing in the docstring
specifies behavior, and it isn't even read at all until --help is
triggered. I intend to keep docstrings behavior-free because, well, they're
strictly for documentation IMO.

One of the last remains of the old "give parameters to Clize about what
your function's parameters does" stuff, a flag to pass the executable name
to the function that's being run, was in fact changed in 3.0b1 to be an
annotation instead, giving it more flexibility (you can annotate whichever
parameter you want rather than being forced to use the first one).

What I mean to say, is that I am definitely committed to keeping everything
in the function signature. Probably even more than you :-)


> * Simplify the basic and obvious usages
>

That's where Clize started and I intend to keep simple usages simple.
One could say having to use @autokwoargs for turning parameters with
default values into keyword-only parameters, but I feel it was necessary
for consistency with the presence of actual keyword-only parameters.

Overall we're agreed on all these goals.

I will add that I'm taking up extensibility as a goal as of Clize 3.0.
clize.parameters.argument_decorator[1] wasn't originally by idea and was
first implemented by someone else using the public API.

[1]
http://clize.readthedocs.org/en/latest/compositing.html#using-a-composed-function-to-process-arguments-to-a-parameter

What it's clearly lacking when compared to your parser is better
docstrings, haha :-) The parser docs alleviate that a bit, but the parser
can be hard to navigate at first.

https://github.com/Rosuav/docstringargs
> https://pypi.python.org/pypi/docstringargs/
>
> There's a demo file in the source repo, plus here are a couple of
> actual usage examples:
>
> https://github.com/Rosuav/LetMeKnow/blob/master/letmeknow.py
> https://github.com/MikeiLL/appension/blob/master/fore/database.py
>
> The latter is an existing module in an existing project, and it grew a
> command-line interface with minimal changes, eg:
>
> https://github.com/MikeiLL/appension/commit/566f195
>
> Can we merge our plans and make a single module that's more likely to
> be maintained long-term? No point over-duplicating!
>

Agreed. I'm open to have more maintainers and to take input, but I have to
admit that at this stage of development, I'm quite attached to Clize's
existing codebase and features (although I'm always open to refactoring,
and the test suite helps with that).


> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Clize 3.0b1: An argument parser that draws a CLI from your function sigature

[Yann Kaiser]

On Mon, 27 Apr 2015 at 22:30 Ethan Furman  wrote:

> On 04/28, Chris Angelico wrote:
>
> > That's a lot of separate pieces. Here's the docstringargs equivalent:
> >
> > https://github.com/Rosuav/snippets/blob/dsa/snippets.py
>
> Just for grins, here's that using Scription:
>
> -- 8< 
> """Store and retrieve snippets of text"""
> from scription import *
> import logging
>
> # Set the log output file, and the log level
> logging.basicConfig(filename="snippets.log", level=logging.DEBUG)
>
> data = {}
>
> @Script()
> def main():
> print('Result: {!r}'.format(script_command()))
>
>

> @Command(
> name=('the name of the snippet', ),
> snippet=('the snippet text', ),
> )
> def put(name, snippet):
>

Blargh, this is exactly what I didn't like about Clize 2.x


> "Store a snippet with an associated name."
> logging.info("Storing({!r}, {!r})".format(name, snippet))
> data[name] = snippet
> return name, snippet
>
> @Command(
> name=('the name of the snippet', ),
> )
> def get(name):
> "Retrieve the snippet with a given name."
> logging.error("Retrieving({!r})".format(name))
> return data.get(name)
>
> Main()
> -- 8< 
>
> and a sample run with nothing selected:
>
> -- 8< 
> $ python snippet
> Store and retrieve snippets of text
>
> snippet get NAME
>
> Retrieve the snippet with a given name.
>
> NAME   the name of the snippet
>
> snippet put NAME SNIPPET
>
> Store a snippet with an associated name.
>
> NAME  the name of the snippet
> SNIPPET   the snippet text
> -- 8< 
>
>
> --
> ~Ethan~
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Clize 3.0b1: An argument parser that draws a CLI from your function sigature

[Yann Kaiser]

On Tue, 28 Apr 2015 at 19:16 Chris Angelico  wrote:

> On Wed, Apr 29, 2015 at 11:55 AM, Yann Kaiser 
> wrote:
> > I'm aware of the pattern, and I don't really like it, especially because
> it
> > gets weird when multiple modules are involved. You'd have to import
> modules
> > because they have a side-effect of adding stuff to a list rather than
> import
> > things so that you can put them in a list. In addition, if Clize manages
> > that list, it will be a global mutable object to take care of in tests
> and
> > so forth. That'll be rather yucky.
> > I like the straightforwardness of "names are imported or defined" ->
> "names
> > are passed to run" (what is passed to run *is* what you get) rather than
> > names are collected as side effect of this and that import then run
> looks at
> > them (well, I could explore what all those imports are doing...).
>
> Okay. That's a philosophical difference that I can understand. There
> is some magic when the decorator hangs onto a reference, and
> personally, I think it's worth it, but if you don't, that's fine. All
> I'd need to do is have my own decorator that collects the functions up
> into a list.
>

Yeah, writing that feature is fairly easy. Telling users why their commands
aren't registered or why their circular import loop is blowing up isn'it.


> >> Can you put together a Clize equivalent? I'm pretty sure it's going to
> >> be remarkably close to what I want.
> >
> >
> > https://gist.github.com/epsy/fba26300fccb7e672729
> >
> > It is pretty much the same save for the result formatting (clize prints
> > non-None results on its own then exits, although for your example I
> > understand the extra format step is necessary)
>
> I already hacked the output a bit compared to the original. Exact
> details aren't a big deal. In the case of fore/database.py, the
> precise formatting hardly matters; this is basically the bootstrapping
> back end (when you have a completely empty database, the server won't
> start, so you need to create yourself an account first), so it's okay
> if it just prints out a tuple's repr.
>
> > Annotated line numbers for "put": (PEP8 double-spacing increased the
> > numbers, sorry)
> >
> > 1-6: Boilerplate: imports
> > 16: Function signature
> > 17-22: Documentation (parameter descriptions need to be in their own
> > paragraph in Clize's default helper)
> > 37-39: Defining a wrapper just for reformatting the result
> > 42-43: defining the execution point and adding the result format
> decorator
> >
> > The result formatting could be better. Maybe run could be made not to
> exit
> > upon success (but still upon failure) and return the evaluated value
> rather
> > than print it, or apply decorators en masse. I definitely see the appeal
> in
> > either.
>
> Returning rather than printing would perhaps be nice in terms of
> reducing the magic, but there's already some magic around (eg exiting
> on failure; mine, since it chains through to argparse, exits on --help
> or failure), so it's not a big deal.
>


>
> So we're actually really REALLY close to each other here. This looks good!
>

Indeed :-)


> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Clize 3.0b1: An argument parser that draws a CLI from your function sigature

[Yann Kaiser]

And... 3.0 is released! :-)

Feel free to contact me or reply should you encounter any issues!

http://clize.readthedocs.org/en/3.0/releases.html#v3-0

On Mon, 27 Apr 2015 at 02:02 Yann Kaiser  wrote:

> Hello everyone!
>
> After a few years in development, I am proud to say Clize is landing its
> feet again and is now in beta for an upcoming release.
>
> You can try it out usingpip install --user clize=3.0b1and you can
> browse the docs athttps://clize.readthedocs.org/
>
> For those who'd like an explanation before clicking links, here's Clize's
> 5-bullet point explanation:
>
> * Command-line interfaces are created by passing functions to `clize.run`.
> * Parameter types are deduced from the functions' parameters.
> * A ``--help`` message is generated from your docstrings. (Why does this
> still need to be a bullet point?)
> * Decorators can be used to reuse functionality across functions.
> * Clize can be extended with new parameter behavior.
>
> I am primarily looking for feedback on the documentation contents, and I
> need to source a FAQ page, but any feedback is welcome!
>
> If you are into that sort of thing, I've also just set up a G+ community
> for it at: https://plus.google.com/communities/10114600650079362
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Cheat sheet for the new string formatting?

[Yann Kaiser]

It just means significant digits in the general format, which alternates
between 10-exponent notation and plain decimal notation.

https://docs.python.org/3.4/library/string.html#format-specification-mini-language

>>> '{:.3}'.format(0.356785)
'3.57e-05'
>>> '{:.3}'.format(0.00356785)
'0.00357'

On Mon, 8 Jun 2015 at 22:33 Skip Montanaro  wrote:

> This is counterintuitive:
>
> >>> "{:.3}".format(-0.00666762259822)
> '-0.00667'
> >>> "{:.3f}".format(-0.00666762259822)
> '-0.007'
> >>> "%.3f" % -0.00666762259822
> '-0.007'
> >>> "{:.3s}".format(-0.00666762259822)
> ValueError Unknown format code 's' for object of type 'float'
>
> Why does the first form display five digits after the decimal point? Why
> don't floats support "{:.Ns}"? (I know I can use "{!s}".)
>
> This is using a freshly hg pulled and updated 2.7  branch.
>
> Thx,
>
> S
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list