[issue39125] Type signature of @property not shown in help()

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> Currently there is no way to tell if the *attribute* 
> is read-only, read-write or write-only.

Read-only is segregated in the help() output.

>>> class A:
@property
def computed_field(self):
'An example property'


>>> help(A)
Help on class A in module __main__:

class A(builtins.object)
 |  Readonly properties defined here:
 |  
 |  computed_field
 |  An example property
 |  
 |  --
 |  Data descriptors defined here:
 |  
 |  __dict__
 |  dictionary for instance variables (if defined)
 |  
 |  __weakref__

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39125] Type signature of @property not shown in help()

[brenthuisman]

brenthuisman  added the comment:

Is there any activity on this issue? The way Pybind11 generates accessors for 
attributes makes (as properties with getter and setter) makes it currently 
impossible to view the type info, which Pybind does provide.

Thanks for any update.

--
nosy: +brenthuisman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39125] Type signature of @property not shown in help()

[Nguyễn Gia Phong]

Change by Nguyễn Gia Phong :


--
versions: +Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39125] Type signature of @property not shown in help()

[Nguyễn Gia Phong]

Nguyễn Gia Phong  added the comment:

Relating to this, should there also be indication about the mode (get, set, 
del) the property?  Currently there is no way to tell if the *attribute* is 
read-only, read-write or write-only.

--
versions:  -Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39125] Type signature of @property not shown in help()

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Currently docstring written for even property.setter is ignored in help as 
inspect.getdoc only inspects property.fget [0] for docstrings. I feel docs for 
setter could also be included. The docs also indicate the same at 
https://docs.python.org/3.6/library/functions.html#property . In the absence of 
docs maybe the signature for getter and setter could be included as per this 
proposal.

class Foo:
@property
def bar(self) -> int:
'''Bar docs for property'''
return 42

@bar.setter
def bar(self, value: int) -> None:
'''Bar docs for setter'''
pass

help(Foo.bar)

Help on property:

Bar docs for property


[0] 
https://github.com/python/cpython/blob/4b3b1226e86df6cd45e921c8f2ad23c3639c43b2/Lib/inspect.py#L580

--
nosy: +rhettinger, xtreak
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39125] Type signature of @property not shown in help()

[Nguyễn Gia Phong]

New submission from Nguyễn Gia Phong :

Dear Maintainer,

I want to request a feature on the generative documentation of type-hinting.
As of December 2019, I believe there is no support for generating such
information in help().  For demonstration, I have this tiny piece of code

class Foo:
@property
def bar(self) -> int: return 42

@bar.setter
def bar(self, value: int) -> None: pass

def baz(self, arg: float) -> str: pass

whose documentation on CPython 3.7.5 (on Debian testing amd64 if that matters)
is generated as

class Foo(builtins.object)
 |  Methods defined here:
 |  
 |  baz(self, arg: float) -> str
 |  
 |  --
 |  Data descriptors defined here:
 |  
 |  __dict__
 |  dictionary for instance variables (if defined)
 |  
 |  __weakref__
 |  list of weak references to the object (if defined)
 |  
 |  bar

I expect the documentation for bar to be as informative as bar, i.e. something
similar to ``bar: int''.  As pointed out by ChrisWarrick on freenode#python,
the annotations are already present, yet help() is not making use of them:

>>> Foo.bar.fget.__annotations__
{'return': }
>>> Foo.bar.fset.__annotations__
{'value': , 'return': None}

Have a Merry Christmas or other holiday of your choice,
Nguyễn Gia Phong

--
assignee: docs@python
components: Documentation
messages: 358823
nosy: McSinyx, docs@python
priority: normal
severity: normal
status: open
title: Type signature of @property not shown in help()
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue39125>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Type signature

[paul kölle]

Marc 'BlackJack' Rintsch wrote:
 In [EMAIL PROTECTED], Yacao Wang
 wrote:
 
 However, type signatures are not only a kind of information provided for
 the compiler, but also for the programmer, or more important, for the
 programmer. Without it, we have to infer the return type or required
 agument types of a function, and this can't be done without seeing the
 implementation of it,
 
 That's what documentation is meant for.  If you are forced to look at the
 implementation, the documentation is bad.
I think the OP refers to reading the *code*, the documentation might not
exist (yet). Sometimes I feel python is easier to write than to read and
 missing argument type declarations (just for documentation purposes)
are  IMHO one reason. Another are missing (optional) argument type
checks at runtime. Something like WrongArgumentType exceptions instead
of rather unspecific AttributeError from deep inside the code would be
very convenient.

Yes docstrings are nice but sometimes a simple:

foo(int:param1, string:param2) is way better than:

foo(param1, param2):
  
  @type param1: integer
  @type parame2: string
  

cheers
 Paul

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Type signature

[Hugo Ferreira]

Which is expecially true when using IDEs with auto-completion.Using
VisualStudio/MonoDevelop and C# I rarely need to look at the
documentation because I can quickly see what a method accept and
returns. And when I need to pass flags or options, enums are much more
neat and encapsulated.
With Python I'm constantly looking at the documentation when
surfing a library. I personally like the terse code and abstraction
features of Python which is making me slowly writing more and more
tools in it. Still, I have to agree that there are edges (like these)
that must be sharpened out...On 7/24/06, paul kölle [EMAIL PROTECTED] wrote:
Marc 'BlackJack' Rintsch wrote: In [EMAIL PROTECTED], Yacao Wang wrote: However, type signatures are not only a kind of information provided for
 the compiler, but also for the programmer, or more important, for the programmer. Without it, we have to infer the return type or required agument types of a function, and this can't be done without seeing the
 implementation of it, That's what documentation is meant for.If you are forced to look at the implementation, the documentation is bad.I think the OP refers to reading the *code*, the documentation might not
exist (yet). Sometimes I feel python is easier to write than to read and missing argument type declarations (just for documentation purposes)areIMHO one reason. Another are missing (optional) argument type
checks at runtime. Something like WrongArgumentType exceptions insteadof rather unspecific AttributeError from deep inside the code would bevery convenient.Yes docstrings are nice but sometimes a simple:
foo(int:param1, string:param2) is way better than:foo(param1, param2):@type param1: integer@type parame2: stringcheers Paul--
http://mail.python.org/mailman/listinfo/python-list-- GPG Fingerprint: B0D7 1249 447D F5BB 22C55B9B 078C 2615 504B 7B85
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Type signature

[Marc 'BlackJack' Rintsch]

In [EMAIL PROTECTED], paul kölle
wrote:

 Marc 'BlackJack' Rintsch wrote:
 In [EMAIL PROTECTED], Yacao Wang
 wrote:
 
 However, type signatures are not only a kind of information provided for
 the compiler, but also for the programmer, or more important, for the
 programmer. Without it, we have to infer the return type or required
 agument types of a function, and this can't be done without seeing the
 implementation of it,
 
 That's what documentation is meant for.  If you are forced to look at the
 implementation, the documentation is bad.
 I think the OP refers to reading the *code*, the documentation might not
 exist (yet).

It should be right there under the `def` as docstring.

 Sometimes I feel python is easier to write than to read and
  missing argument type declarations (just for documentation purposes)
 are  IMHO one reason. Another are missing (optional) argument type
 checks at runtime. Something like WrongArgumentType exceptions instead
 of rather unspecific AttributeError from deep inside the code would be
 very convenient.

The you start getting `WrongArgumentType` exceptions sooner or later for
arguments that have all the necessary attributes in place but are of the
wrong type.  Very inconvenient.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Type signature

[[EMAIL PROTECTED]]

Yacao Wang wrote:
 Hi, I'm a newbie to Python. I've recently read some books about this
 language and none of them have answered my question.
 As a dynamically-typed language Python doesn't need any form of type
 signature which makes the syntax very clean and concise. However, type
 signatures are not only a kind of information provided for the compiler, but
 also for the programmer, or more important, for the programmer. Without it,
 we have to infer the return type or required agument types of a function,

Reset your brain.  Functions don't have required argument types,
anything implementing the interface they use will work.

e.g.:
class a(object):
def getVal(self):
return a_val

class b(object):
def getVal(self):
return b_val

def someFunc(valObj):
return valObj.getVal().upper()


someFunc can take objects of class a or class b or any other class that
has a getVal method returning something with an upper method (getVal
doesn't even have to return a string as long as what it returns has an
upper method).

a and b don't share an inheritance hierarchy, either.

There is no type signature, there's just which methods/attributes are
used by the function.

Limiting it to only working on specified types is unnecessarily
restrictive.

 Haskell can also determine type information
 dynamically

Haskell does static type inference at compile time, not dynamic typing.
 It's a completely different programming model (shared with ML, among
others)

 As I
 understand, Python relies too much on run-time type-checking, that is,
 whenever you give the wrong type, you just end up with an exception, which
 is logically correct, but not that useful as type signatures.

Dynamic typing is different from static typing, you're right, but it's
not worse.

You probably want to google for duck typing think about the
implications on polymorphism.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Type signature

[Paddy]

Yacao Wang wrote:
 Hi, I'm a newbie to Python. I've recently read some books about this
 language and none of them have answered my question.
 As a dynamically-typed language Python doesn't need any form of type
 signature which makes the syntax very clean and concise. However, type
 signatures are not only a kind of information provided for the compiler, but
 also for the programmer, or more important, for the programmer. Without it,
 we have to infer the return type or required agument types of a function,
 and this can't be done without seeing the implementation of it, and
 sometimes it is still difficult to extract the above information even if the
 implementation is available. Haskell can also determine type information
 dynamically, but it still supports and recommends the programming style with
 type signatures, which makes the code very readable and maitainable. As I
 understand, Python relies too much on run-time type-checking, that is,
 whenever you give the wrong type, you just end up with an exception, which
 is logically correct, but not that useful as type signatures.
 Any ideas on this issue?

 --
 Alex

Hi Yacao/Alex,
Try these:
  How to duck type? - the psychology of static typing in Ruby
   http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/100511
  3-31-04 I'm Over It

http://66.102.9.104/search?q=cache:6XW473VSflcJ:www.mindview.net/WebLog/log-0053+%2B%22duck+typing%22+%2B+%22static+typing%22+%2Bpythonhl=engl=ukct=clnkcd=3client=firefox-a

It seems that the latent or duck typing, used in dynamic languages is
counter-intuitve to  those from a static typing background.
Nevertheless, it does work, and work well.
- Paddy.

-- 
http://mail.python.org/mailman/listinfo/python-list

Type signature

[Yacao Wang]

Hi, I'm a newbie to Python. I've recently read some books about this language and none of them have answered my question. As a dynamically-typed language Python doesn't need any form of type signature which makes the syntax very clean and concise. However, type signatures are not only a kind of information provided for the compiler, but also for the programmer, or more important, for the programmer. Without it, we have to infer the return type or required agument types of a function, and this can't be done without seeing the implementation of it, and sometimes it is still difficult to extract the above information even if the implementation is available. Haskell can also determine type information dynamically, but it still supports and recommends the programming style with type signatures, which makes the code very readable and maitainable. As I understand, Python relies too much on run-time type-checking, that is, whenever you give the wrong type, you just end up with an exception, which is logically correct, but not that useful as type signatures.
Any ideas on this issue? -- Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Type signature

[Marc 'BlackJack' Rintsch]

In [EMAIL PROTECTED], Yacao Wang
wrote:

 However, type signatures are not only a kind of information provided for
 the compiler, but also for the programmer, or more important, for the
 programmer. Without it, we have to infer the return type or required
 agument types of a function, and this can't be done without seeing the
 implementation of it,

That's what documentation is meant for.  If you are forced to look at the
implementation, the documentation is bad.

 Haskell can also determine type information dynamically, but it still
 supports and recommends the programming style with type signatures,

Does Haskell really determine the type information dynamically!?  AFAIK
it's done at compile time.

 which makes the code very readable and maitainable. As I understand,
 Python relies too much on run-time type-checking, that is, whenever you
 give the wrong type, you just end up with an exception, which is
 logically correct, but not that useful as type signatures. Any ideas on
 this issue?

Which issue?  ;-)

Just stop thinking in terms of types.  Python is about *behavior*.  If
the docs say `this functions takes an iterable as input` then `iterable`
isn't a specific type but an object that implements the behavior of an
iterable.  You can't check that reliable without actually trying to
iterate over it.  Search for duck typing.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Type signature

[hanumizzle]

Yacao Wang wrote:
 Hi, I'm a newbie to Python. I've recently read some books about this
 language and none of them have answered my question.
 As a dynamically-typed language Python doesn't need any form of type
 signature which makes the syntax very clean and concise.

OK...

 However, type
 signatures are not only a kind of information provided for the compiler

Statically-typed code tends (generally) to be faster than
dynamically-typed code, obviously. Often, it doesn't really matter,
though. (This is an old argument.)

Lush is an interesting Lisp-like language that supports admixture of
dynamic and static typing, and uses type signatures to support it. It
can produce high performance machine code because of this.

 Python relies too much on run-time type-checking, that is,
 whenever you give the wrong type, you just end up with an exception, which
 is logically correct, but not that useful as type signatures.

As said before, polymorphism plays an important role. In addition to
looking up 'duck typing' (c.f. Programming Ruby), it might also be
useful to look for Damian Conway's observations on 'interface
polymorphism' (standard practice in Perl, Python, Ruby, etc.) vs.
'inheritance polymorphism' (what you get with C++ and IIRC Java).

-- 
http://mail.python.org/mailman/listinfo/python-list