Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #111197 > unrolled thread

Clean Singleton Docstrings

Back to article view | Back to comp.lang.python

Contents

  Clean Singleton Docstrings Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-07 23:46 +0000
    Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-08 12:53 +1000
    Re: Clean Singleton Docstrings Michael Selik <michael.selik@gmail.com> - 2016-07-07 23:43 -0400
      Re: Clean Singleton Docstrings Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-08 16:57 +0000
        Re: Clean Singleton Docstrings Ethan Furman <ethan@stoneleaf.us> - 2016-07-08 13:00 -0700
    Re: Clean Singleton Docstrings Peter Otten <__peter__@web.de> - 2016-07-08 09:38 +0200
      Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-08 19:20 +1000
        Re: Clean Singleton Docstrings Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-08 16:47 +0000
      Re: Clean Singleton Docstrings Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-13 15:42 -0700
        Re: Clean Singleton Docstrings Peter Otten <__peter__@web.de> - 2016-07-14 01:54 +0200
          Re: Clean Singleton Docstrings Rustom Mody <rustompmody@gmail.com> - 2016-07-15 21:04 -0700
            Re: Clean Singleton Docstrings Ethan Furman <ethan@stoneleaf.us> - 2016-07-15 21:20 -0700
              Re: Clean Singleton Docstrings Rustom Mody <rustompmody@gmail.com> - 2016-07-15 22:51 -0700
              Re: Clean Singleton Docstrings Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-15 23:19 -0700
                Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-16 16:29 +1000
                Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-16 02:53 -0400
                  Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-16 18:54 +1000
                  Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-16 19:46 +1000
                    What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-17 21:16 -0700
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 14:35 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-17 22:37 -0700
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 15:48 +1000
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 09:21 +0300
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-18 09:32 -0400
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Ben Finney <ben+python@benfinney.id.au> - 2016-07-18 14:46 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-17 22:22 -0700
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-18 19:29 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 13:00 +0300
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 20:15 +1000
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 03:24 -0700
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-18 20:37 +1000
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 14:38 +0300
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Peter Otten <__peter__@web.de> - 2016-07-18 14:58 +0200
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:42 +1000
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 21:58 -0700
                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-19 15:30 +1000
                                Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-20 15:42 +1000
                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-20 16:11 +1000
                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-20 09:09 +0200
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 10:25 +0300
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve@pearwood.info> - 2016-07-20 22:47 +1000
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 16:54 +0300
                                        Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-21 00:26 +1000
                                          Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 17:59 +0300
                                            Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-20 22:38 -0700
                                              Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-21 10:52 +0300
                                                Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-21 18:46 +1000
                                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Marko Rauhamaa <marko@pacujo.net> - 2016-07-21 12:09 +0300
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-22 00:54 +0100
                                        Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Kaynor <ckaynor@zindagigames.com> - 2016-07-21 17:43 -0700
                                          Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-22 17:14 +0100
                                  Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-20 22:28 -0700
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Chris Angelico <rosuav@gmail.com> - 2016-07-21 15:35 +1000
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-20 22:52 -0700
                                    Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-21 16:34 +1000
                                      Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Rustom Mody <rustompmody@gmail.com> - 2016-07-21 06:14 -0700
                                        Re: Floating point equality [was Re: What exactly is "exact" (was Clean Singleton Docstrings)] Steven D'Aprano <steve@pearwood.info> - 2016-07-22 02:10 +1000
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Chris Angelico <rosuav@gmail.com> - 2016-07-19 15:27 +1000
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 03:14 -0700
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-18 09:25 -0600
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 18:40 +0300
                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 18:55 +0300
                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-18 11:13 -0600
                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-18 21:58 +0300
                                  Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 17:36 -0700
                                    Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:16 +1000
                                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Rustom Mody <rustompmody@gmail.com> - 2016-07-18 20:26 -0700
                                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Gene Heskett <gheskett@shentel.net> - 2016-07-19 01:22 -0400
                                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-19 10:46 -0700
                                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Gene Heskett <gheskett@shentel.net> - 2016-07-19 16:35 -0400
                                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 01:17 +0300
                                              Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-19 23:15 -0400
                                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 10:16 +0300
                                                  Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-20 10:00 -0400
                                                    Re: What exactly is "exact" (was Clean Singleton Docstrings) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-21 10:46 +1200
                                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-19 16:27 -0600
                                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 02:09 +0300
                                              Re: What exactly is "exact" (was Clean Singleton Docstrings) alister <alister.ware@ntlworld.com> - 2016-07-20 13:24 +0000
                                                Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-21 14:04 +1000
                                            Re: What exactly is "exact" (was Clean Singleton Docstrings) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-19 17:01 -0700
                                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-20 11:07 +1200
                                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Marko Rauhamaa <marko@pacujo.net> - 2016-07-20 02:20 +0300
                          Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:03 +1000
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Random832 <random832@fastmail.com> - 2016-07-18 09:25 -0400
                        Re: What exactly is "exact" (was Clean Singleton Docstrings) Steven D'Aprano <steve@pearwood.info> - 2016-07-19 13:21 +1000
                      Re: What exactly is "exact" (was Clean Singleton Docstrings) Ben Finney <ben+python@benfinney.id.au> - 2016-07-19 10:21 +1000
                Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-16 17:27 +1000
                  Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-16 10:58 +0300
                Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-16 14:04 -0400
                  Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-16 21:43 +0300
                Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 07:02 +1000
                  Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-17 00:27 +0300
                    Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 08:18 +1000
                      Re: Clean Singleton Docstrings Marko Rauhamaa <marko@pacujo.net> - 2016-07-17 10:41 +0300
                        Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 17:51 +1000
                        Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-17 04:03 -0400
                          Re: Clean Singleton Docstrings Steven D'Aprano <steve@pearwood.info> - 2016-07-17 20:35 +1000
                        Re: Clean Singleton Docstrings Random832 <random832@fastmail.com> - 2016-07-17 04:08 -0400
                        Re: Clean Singleton Docstrings Chris Angelico <rosuav@gmail.com> - 2016-07-17 18:44 +1000
        Re: Clean Singleton Docstrings Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-13 18:25 -0600
    Re: Clean Singleton Docstrings Peter Otten <__peter__@web.de> - 2016-07-08 09:44 +0200
      Re: Clean Singleton Docstrings Rustom Mody <rustompmody@gmail.com> - 2016-07-08 01:53 -0700
    Re: What exactly is "exact" (was Clean Singleton Docstrings) Gene Heskett <gheskett@shentel.net> - 2016-07-19 23:16 -0400

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#111197 — Clean Singleton Docstrings

I've got a package that contains a global ensmartened dict that allows
all the various parts of my program to share state.  Things like device
handles, information about the application environment, etc. that are
inherantly global (i.e. we're not having that debate).

Implementation is:

  class _Registry(UserDict):
    """Docstring!"""
    ...
  Registry = _Registry()

So Registry is now a globally accessible mutable object; no reason to
complicate things with singletons or borgs or whathave you. From
within the interactive console, help(foobar.Registry) gives me the
_Registry documentation as expected.

From the (Linux) command line though:
  $ pydoc3 foobar._Registry
    [lots of good documentation stuff]
  $ pydoc3 foobar.Registry
  no Python documentation found for 'foobar.Registry'

Is this a thing that can be fixed with a commensurate amount of effort?

Thanks,
Rob

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

[toc] | [next] | [standalone]

#111198

On Fri, 8 Jul 2016 09:46 am, Rob Gaddi wrote:
[...]

> So Registry is now a globally accessible mutable object; no reason to
> complicate things with singletons or borgs or whathave you. From
> within the interactive console, help(foobar.Registry) gives me the
> _Registry documentation as expected.
> 
> From the (Linux) command line though:
>   $ pydoc3 foobar._Registry
>     [lots of good documentation stuff]
>   $ pydoc3 foobar.Registry
>   no Python documentation found for 'foobar.Registry'
> 
> Is this a thing that can be fixed with a commensurate amount of effort?

[steve@ando ~]$ python3 -m pydoc --help
pydoc - the Python documentation tool

pydoc <name> ...
    Show text documentation on something.  <name> may be the name of a
    Python keyword, topic, function, module, or package, or a dotted
    reference to A CLASS OR FUNCTION within a module [...]

(Emphasis added.)


So, no, reading the docstrings from individual objects is not supported by
pydoc's command line interface. You could possibly add that functionality,
but I don't know how much effort it would be.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#111199

> On Jul 7, 2016, at 7:46 PM, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
> 
> I've got a package that contains a global ensmartened dict that allows
> all the various parts of my program to share state.

The simplest solution would be to use a module as your singleton. For example, "registry.py" would work. Pydoc will show its docstring, and it will have all the features you had been using, with the added benefit of not needing to enforce its singletonness.
     

[toc] | [prev] | [next] | [standalone]

#111207

Michael Selik wrote:

>
>
>> On Jul 7, 2016, at 7:46 PM, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:
>> 
>> I've got a package that contains a global ensmartened dict that allows
>> all the various parts of my program to share state.
>
> The simplest solution would be to use a module as your singleton. For example, "registry.py" would work. Pydoc will show its docstring, and it will have all the features you had been using, with the added benefit of not needing to enforce its singletonness.
>      

REALLY needs to be an object, preferably dict-like.  For instance, one
of the things it does is provide a .getKeyChanged(self, key) method that
returns a keyChanged QSignal so that various elements of the program can
all register for notifications triggered by __setitem__.  That way, when
Registry['dut'] gets updated, all of the various GUI elements reliant on
information about the dut all dump their old data and find out about the
newly connected device.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#111208

On 07/08/2016 09:57 AM, Rob Gaddi wrote:
> Michael Selik wrote:
>> On Jul 7, 2016, at 7:46 PM, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote:

>>> I've got a package that contains a global ensmartened dict that allows
>>> all the various parts of my program to share state.
>>
>> The simplest solution would be to use a module as your singleton. For example, "registry.py" would work. Pydoc will show its docstring, and it will have all the features you had been using, with the added benefit of not needing to enforce its singletonness.
>>
>
> REALLY needs to be an object, preferably dict-like.  For instance, one
> of the things it does is provide a .getKeyChanged(self, key) method that
> returns a keyChanged QSignal so that various elements of the program can
> all register for notifications triggered by __setitem__.  That way, when
> Registry['dut'] gets updated, all of the various GUI elements reliant on
> information about the dut all dump their old data and find out about the
> newly connected device.

Get the best of both worlds -- insert your Registry object into 
sys.modules.  It is then importable from anywhere, yet still has all its 
native object power.

Something like this should do the trick:

# untested
import sys
sys.modules['%s.registry' % __name__] = _Register()

and then elsewhere:

from blah import registery
registry.whatever()

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#111202

Rob Gaddi wrote:

> I've got a package that contains a global ensmartened dict that allows
> all the various parts of my program to share state.  Things like device
> handles, information about the application environment, etc. that are
> inherantly global (i.e. we're not having that debate).
> 
> Implementation is:
> 
>   class _Registry(UserDict):
>     """Docstring!"""
>     ...
>   Registry = _Registry()
> 
> So Registry is now a globally accessible mutable object; no reason to
> complicate things with singletons or borgs or whathave you. From
> within the interactive console, help(foobar.Registry) gives me the
> _Registry documentation as expected.
> 
> From the (Linux) command line though:
>   $ pydoc3 foobar._Registry
>     [lots of good documentation stuff]
>   $ pydoc3 foobar.Registry
>   no Python documentation found for 'foobar.Registry'
> 
> Is this a thing that can be fixed with a commensurate amount of effort?

There is a test

if not object:
    raise ImportError('no Python documentation found for %r' % thing)

in the pydoc module. So all you need is to ensure that your Registry 
evaluates to True in a boolean context, e. g. by putting something into it: 

$ cat foobar.py
from collections import UserDict

class _Registry(UserDict):
    """Docstring!"""

Registry = _Registry()
Registry["dummy"] = 42
$ pydoc3 foobar.Registry | head -n 10
Help on _Registry in foobar object:

foobar.Registry = class _Registry(collections.UserDict)
 |  Docstring!
 |  
 |  Method resolution order:
 |      _Registry
 |      collections.UserDict
 |      collections.abc.MutableMapping
 |      collections.abc.Mapping

You might also file a bug report asking to replace

if not object: ...

with 

if object is None: ...

[toc] | [prev] | [next] | [standalone]

#111205

On Fri, 8 Jul 2016 05:38 pm, Peter Otten wrote:

[...]
>> Is this a thing that can be fixed with a commensurate amount of effort?
> 
> There is a test
> 
> if not object:
>     raise ImportError('no Python documentation found for %r' % thing)
> 
> in the pydoc module. So all you need is to ensure that your Registry
> evaluates to True in a boolean context, e. g. by putting something into
> it:


Nicely spotted! I had seen the test but hadn't realised the implications.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#111206

Steven D'Aprano wrote:

> On Fri, 8 Jul 2016 05:38 pm, Peter Otten wrote:
>
> [...]
>>> Is this a thing that can be fixed with a commensurate amount of effort?
>> 
>> There is a test
>> 
>> if not object:
>>     raise ImportError('no Python documentation found for %r' % thing)
>> 
>> in the pydoc module. So all you need is to ensure that your Registry
>> evaluates to True in a boolean context, e. g. by putting something into
>> it:
>
>
> Nicely spotted! I had seen the test but hadn't realised the implications.
>

As speedy problem resolutions go, before I mentioned it is pretty good.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#111418

On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:

> There is a test
> 
> if not object:
>     raise ImportError('no Python documentation found for %r' % thing)
> 
> in the pydoc module. So all you need is to ensure that your Registry 
> evaluates to True in a boolean context, e. g. by putting something into it: 

And there are still those who think that Python’s lax acceptance of non-boolean values as booleans is a good idea...

[toc] | [prev] | [next] | [standalone]

#111419

Lawrence D’Oliveiro wrote:

> On Friday, July 8, 2016 at 7:38:56 PM UTC+12, Peter Otten wrote:
> 
>> There is a test
>> 
>> if not object:
>>     raise ImportError('no Python documentation found for %r' % thing)
>> 
>> in the pydoc module. So all you need is to ensure that your Registry
>> evaluates to True in a boolean context, e. g. by putting something into
>> it:
> 
> And there are still those who think that Python’s lax acceptance of
> non-boolean values as booleans is a good idea...

I don't think this particular problem serves as an argument for stricter 
handling of boolean expressions because the fix

if object is not None: ...

is not completely correct, either:

$ cat demo.py
no = False
yes = True
maybe = None
$ pydoc3.4 demo.yes | head -n3
Help on bool in demo object:

demo.yes = class bool(int)
$ pydoc3.4 demo.no | head -n3
no Python documentation found for 'demo.no'

$ pydoc3.5 demo.no | head -n3
Help on bool in demo object:

demo.no = class bool(int)
$ pydoc3.5 demo.maybe | head -n3
No Python documentation found for 'demo.maybe'.
Use help() to get the interactive help utility.
Use help(str) for help on the str class.

Better would be to let the locate() function raise an exception along these 
lines:

       for part in parts[n:]:
        try:
            object = getattr(object, part)
        except AttributeError:
            # return None
            raise ImportError("Name ... not found in module ...")

PS: Do the new hints
"""
Use help() to get the interactive help utility.
Use help(str) for help on the str class.
"""
make any sense? Not to me, at this time of the day...

[toc] | [prev] | [next] | [standalone]

#111490

On Thursday, July 14, 2016 at 5:24:50 AM UTC+5:30, Peter Otten wrote:
> Lawrence D’Oliveiro wrote:
> > And there are still those who think that Python’s lax acceptance of
> > non-boolean values as booleans is a good idea...
> 
> I don't think this particular problem serves as an argument for stricter 
> handling of boolean expressions because the fix
<details Ive yet  to grok snipped>

I was going to apologise for the snark
Then I see thats not my words; I said something along similar lines
Doesn't mean python needs to change
Just that suggesting that python's bool notion is straightforward is an
unnecessary lie – especially to newbies.

[toc] | [prev] | [next] | [standalone]

#111491

On 07/15/2016 09:04 PM, Rustom Mody wrote:

> Just that suggesting that python's bool notion is straightforward is an
> unnecessary lie – especially to newbies.

Python's boolean concept is as simple as it gets -- what is not straightforward about it?

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#111493

On Saturday, July 16, 2016 at 9:50:13 AM UTC+5:30, Ethan Furman wrote:
> On 07/15/2016 09:04 PM, Rustom Mody wrote:
> 
> > Just that suggesting that python's bool notion is straightforward is an
> > unnecessary lie – especially to newbies.
> 
> Python's boolean concept is as simple as it gets -- what is not straightforward about it?

I thought the other thread "Operator precedence/boolean logic" demonstrated that.
Ive added a further continuation there – where this topic is more relevant

[toc] | [prev] | [next] | [standalone]

#111495

On Saturday, July 16, 2016 at 4:20:13 PM UTC+12, Ethan Furman wrote:
>
> On 07/15/2016 09:04 PM, Rustom Mody wrote:
> 
>> Just that suggesting that python's bool notion is straightforward is an
>> unnecessary lie – especially to newbies.
> 
> Python's boolean concept is as simple as it gets -- what is not
> straightforward about it?

The fact that it led to the aforementioned bug.

[toc] | [prev] | [next] | [standalone]

#111496

On Sat, Jul 16, 2016 at 4:19 PM, Lawrence D’Oliveiro
<lawrencedo99@gmail.com> wrote:
> On Saturday, July 16, 2016 at 4:20:13 PM UTC+12, Ethan Furman wrote:
>>
>> On 07/15/2016 09:04 PM, Rustom Mody wrote:
>>
>>> Just that suggesting that python's bool notion is straightforward is an
>>> unnecessary lie – especially to newbies.
>>
>> Python's boolean concept is as simple as it gets -- what is not
>> straightforward about it?
>
> The fact that it led to the aforementioned bug.

The difference between ints and floats can lead to bugs, too. Which
one should we eliminate?

Tuple augmented assignment can lead to extremely confusing bugs. Let's
abolish augmented assignment. Or tuples?

Operator precedence leads to bugs when people don't respect it.
Eliminate it; all operators function at the same precedence, with
middle-to-outside associativity (as popularized by the "if/else"
ternary operator).

There. Now we have a bug-free language.

Tongue removed from cheek... The Python policy is a *lot* easier to
work with than REXX's policy is. In REXX, if you put a value in an IF
statement that isn't its canonical True or False (in its case, "1" and
"0"), you get a run-time error. Python lets you use None, False, 0,
etc, as falsey, and if you really want a comparison, you put it in
there. How is this a problem?

As demonstrated elsewhere, the problem isn't the boolification. The
problem is that an 'if' was used where exception handling would have
been far better.

ChrisA

[toc] | [prev] | [next] | [standalone]

#111497

On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote:
> The difference between ints and floats can lead to bugs, too. Which
> one should we eliminate?

Eliminate both of them. Move to a single abstract numeric type* a la
Scheme, with an "inexact" attribute (inexact numbers may or may not be
represented by a float, or by the same bigint/decimal/rational types as
exact ones with a flag set to mark them as inexact.)

*which may have multiple concrete representations, just as our single
abstract unicode string type has different concrete representations for
ASCII, Latin-1, UCS-2, and UCS-4.

[toc] | [prev] | [next] | [standalone]

#111500

On Sat, 16 Jul 2016 04:53 pm, Random832 wrote:

> On Sat, Jul 16, 2016, at 02:29, Chris Angelico wrote:
>> The difference between ints and floats can lead to bugs, too. Which
>> one should we eliminate?
> 
> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "inexact" attribute (inexact numbers may or may not be
> represented by a float, or by the same bigint/decimal/rational types as
> exact ones with a flag set to mark them as inexact.)
> 
> *which may have multiple concrete representations, just as our single
> abstract unicode string type has different concrete representations for
> ASCII, Latin-1, UCS-2, and UCS-4.

No, that's not going to work. It works for Unicode because the
implementation *really is just a detail*. Whether 'A' is represented as a
seven-bit ASCII code, 8-bit Latin-1 code, 16-bit UCS-2 code or 32-bit UCS-4
code makes no difference to the behaviour of the string. (There may or may
not be performance differences, but that's a separate issue.)

But that doesn't hold for numbers. For a combination of accidental,
intentional and historical reasons, we need to support multiple numeric
types with different behaviour sometimes even different APIs. For example,
different int types behave differently on overflow; floats have signed
zeroes and infinities but fractions don't, etc. But most importantly, one
needs to be able to distinguish between (say) real numbers and complex
numbers, where sqrt(x) and sqrt(x+0j) do not necessarily return the same
value. Or you want to implement (say) "integers modulo 12" such that 11+1
gives 0. You can't do that if you are limited to a single abstract Number
type.


Still, there's probably a lot we could do to improve the ability to
duck-type numbers in Python. For instance, it is a nuisance that we write:

  math.isfinite(x)

for floats, but

  x.is_finite()

for Decimals.




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#111503

Oh, and a further thought... 


On Sat, 16 Jul 2016 04:53 pm, Random832 wrote:

> Eliminate both of them. Move to a single abstract numeric type* a la
> Scheme, with an "inexact" attribute (inexact numbers may or may not be
> represented by a float, or by the same bigint/decimal/rational types as
> exact ones with a flag set to mark them as inexact.)

But that's *wrong*. Numbers are never inexact. (You can have interval
arithmetic using "fuzzy numbers", but they're ALWAYS inexact.) It is
calculations which are exact or inexact, not numbers. There's no a priori
reason to expect that 0.499999 is "inexact" while 0.5 is "exact", you need
to know the calculation that generated it:

py> from decimal import *
py> getcontext().prec = 6
py> Decimal("9.000002")/6  # inexact
Decimal('1.50000')
py> Decimal(1)/2 - Decimal('1e-6')  # exact
Decimal('0.499999')


It seems to me that unless you're prepared to actually do some sort of error
tracking, just having an "inexact/exact" flag is pretty useless. If I
perform a series of calculations, and get 1.0 as the result, and the
inexact flag is set, that doesn't mean that 1.0 is the wrong answer -- it
may be that the errors have cancelled and 1.0 is the exact answer. Or it
may be that the error bound is 1.0 ± 10000, and the calculation has
diverged so far from the correct result that it is useless.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#111588 — What exactly is "exact" (was Clean Singleton Docstrings)

On Saturday, July 16, 2016 at 3:16:48 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 16 Jul 2016 04:53 pm, Random832 wrote:
> 
> > Eliminate both of them. Move to a single abstract numeric type* a la
> > Scheme, with an "inexact" attribute (inexact numbers may or may not be
> > represented by a float, or by the same bigint/decimal/rational types as
> > exact ones with a flag set to mark them as inexact.)
> 
> But that's *wrong*. Numbers are never inexact. (You can have interval
> arithmetic using "fuzzy numbers", but they're ALWAYS inexact.) It is
> calculations which are exact or inexact, not numbers. There's no a priori
> reason to expect that 0.499999 is "inexact" while 0.5 is "exact", you need
> to know the calculation that generated it:

Heh! Did you check what scheme has to say about this before holding forth?
I suggest a tool called google. It can make one seem profound
Here are the first couple of hits it gives (me) for “scheme exact number”


| Scheme integers can be exact and inexact. For example, a number
| written as 3.0 with an explicit decimal-point is inexact, but it
| is also an integer. The functions integer? and scm_is_integer
| report true for such a number, but the functions exact-integer?…
| only allow exact integers and thus report
| false. Likewise, the conversion functions like
| scm_to_signed_integer only accept exact integers.
|  
| The motivation for this behavior is that the inexactness of a number
| should not be lost silently. If you want to allow inexact integers,
| you can explicitly insert a call to inexact->exact or to its C
| equivalent scm_inexact_to_exact. (Only inexact integers will be
| converted by this call into exact integers; inexact non-integers 
| will become exact fractions.)

https://www.gnu.org/software/guile/manual/html_node/Integers.html

| All numbers are complex numbers. Some of them are real numbers, and
| all of the real numbers that can be represented are also rational
| numbers, except for +inf.0 (positive infinity), +inf.f
| (single-precision variant), -inf.0 (negative infinity), -inf.f
| (single-precision variant), +nan.0 (not-a-number), and +nan.f
| (single-precision variant). Among the rational numbers, some are
| integers, because round applied to the number produces the same
| number.
|  
| Orthogonal to those categories, each number is also either an exact
| number or an inexact number. Unless otherwise specified, computations
| that involve an inexact number produce inexact results. Certain
| operations on inexact numbers, however, produce an exact number, such
| as multiplying an inexact number with an exact 0. Operations that
| mathematically produce irrational numbers for some rational arguments
| (e.g., sqrt) may produce inexact results even for exact arguments.

https://docs.racket-lang.org/reference/numbers.html

AIUI…
There are two almost completely unrelated notions of exact

1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are approximations.
   We could call these inexact forms of ⅓

2. Measurement and observation produces numbers.  These are inexact inherently.

Scheme's notion of exact is towards capturing the second notion.
According to which
“There were 20,000 people in the stadium” would be an inexact integer
[Yeah note Inexact INTEGER]
whereas
√2, e, π are all exact.  Just that they dont have finite decimal/continued
fraction and of course float representations.

In short one could think of inexact and exact — in scheme's intended
semantics — as better called scientific (or science-ic) and mathematic
numbers.

Or if you prefer more philosophic jargon: analytic numbers and synthetic numbers:

The fact that analytic/mathematic and synthetic/science-ic domains at all 
correspond is at the least surprising.  
Famous article calling it “unreasonable” starts with this:

| THERE IS A story about two friends, who were classmates in high
| school, talking about their jobs. One of them became a statistician
| and was working on population trends. He showed a reprint to his
| former classmate. The reprint started, as usual, with the Gaussian
| distribution and the statistician explained to his former classmate
| the meaning of the symbols for the actual population, for the average
| population, and so on. His classmate was a bit incredulous and was not
| quite sure whether the statistician was pulling his leg. "How can you
| know that?" was his query. "And what is this symbol here?" "Oh," said
| the statistician, "this is pi." "What is that?" "The ratio of the
| circumference of the circle to its diameter." "Well, now you are
| pushing your joke too far," said the classmate, "surely the population
| has nothing to do with the circumference of the circle."
| https://www.dartmouth.eduh/~matc/MathDrama/reading/Wigner.html

But the match while strong is not quite perfect:

Physical length (unlike math numbers) may have a ‘least count’
https://en.wikipedia.org/wiki/Planck_length

Likewise time

https://en.wikipedia.org/wiki/Planck_time

And of course all this is highly speculative; ie it may be 
https://en.wikipedia.org/wiki/Chronon

At the more mundane level when I read off 2 volts on a voltmeter
- May be reading wrong by seeing from a wrong angle
- Meter may be miscalibrated
- Or broken
- Or the range setting was not 0-10 as I imagined but 0-500
- And so on

IOW numbers picked off from the real world are just naturally wrong

And that's nothing to do with math operations like floating point
introducing errors

[toc] | [prev] | [next] | [standalone]

#111589 — Re: What exactly is "exact" (was Clean Singleton Docstrings)

On Mon, Jul 18, 2016 at 2:16 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Saturday, July 16, 2016 at 3:16:48 PM UTC+5:30, Steven D'Aprano wrote:
> Here are the first couple of hits it gives (me) for “scheme exact number”
>
> | Scheme integers can be exact and inexact. For example, a number
> | written as 3.0 with an explicit decimal-point is inexact, but it
> | is also an integer.
>
> AIUI…
> There are two almost completely unrelated notions of exact
>
> 1. ⅓ in decimal cannot be exactly represented though 0.3 0.33 etc are approximations.
>    We could call these inexact forms of ⅓
>
> 2. Measurement and observation produces numbers.  These are inexact inherently.
>
> Scheme's notion of exact is towards capturing the second notion.

Why does that mean that 3.0 is inexact? In what way is 3.0 "inexact"?
It's an exact value representing the integer three.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.python

csiph-web