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

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

Newbie: static typing?

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

Contents

  Newbie: static typing? Rui Maciel <rui.maciel@gmail.com> - 2013-08-05 21:46 +0100
    Re: Newbie: static typing? Gary Herron <gary.herron@islandtraining.com> - 2013-08-05 14:07 -0700
      Re: Newbie: static typing? Rui Maciel <rui.maciel@gmail.com> - 2013-08-06 10:05 +0100
        Re: Newbie: static typing? Steven D'Aprano <steve@pearwood.info> - 2013-08-06 09:26 +0000
        Re: Newbie: static typing? Joshua Landau <joshua@landau.ws> - 2013-08-06 10:29 +0100
          Re: Newbie: static typing? Rui Maciel <rui.maciel@gmail.com> - 2013-08-06 11:12 +0100
            Re: Newbie: static typing? Burak Arslan <burak.arslan@arskom.com.tr> - 2013-08-06 16:27 +0300
            Re: Newbie: static typing? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-06 15:57 +0200
            Re: Newbie: static typing? Chris Angelico <rosuav@gmail.com> - 2013-08-06 15:06 +0100
            Re: Newbie: static typing? "Eric S. Johansson" <esj@harvee.org> - 2013-08-06 09:58 -0400
            Re: Newbie: static typing? Chris Angelico <rosuav@gmail.com> - 2013-08-06 15:38 +0100
        Easier to Ask Forgiveness than Permission (was: Newbie: static typing?) Ben Finney <ben+python@benfinney.id.au> - 2013-08-07 08:23 +1000
    Re: Newbie: static typing? Ian Kelly <ian.g.kelly@gmail.com> - 2013-08-05 17:38 -0600
    Re: Newbie: static typing? Ben Finney <ben+python@benfinney.id.au> - 2013-08-06 10:35 +1000
      Re: Newbie: static typing? Rui Maciel <rui.maciel@gmail.com> - 2013-08-06 10:01 +0100
        Re: Newbie: static typing? Joshua Landau <joshua@landau.ws> - 2013-08-06 10:19 +0100
          Re: Newbie: static typing? Rui Maciel <rui.maciel@gmail.com> - 2013-08-06 11:07 +0100
            Re: Newbie: static typing? Rotwang <sg552@hotmail.co.uk> - 2013-08-06 15:25 +0100
            Re: Newbie: static typing? Ben Finney <ben+python@benfinney.id.au> - 2013-08-07 08:34 +1000
        Re: Newbie: static typing? Chris Angelico <rosuav@gmail.com> - 2013-08-06 10:29 +0100
          Re: Newbie: static typing? Rui Maciel <rui.maciel@gmail.com> - 2013-08-06 11:28 +0100
            Re: Newbie: static typing? Chris Angelico <rosuav@gmail.com> - 2013-08-06 11:50 +0100
            Re: Newbie: static typing? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-08-06 18:54 -0400
            Re: Newbie: static typing? Terry Reedy <tjreedy@udel.edu> - 2013-08-06 19:02 -0400
            Re: Newbie: static typing? Chris Angelico <rosuav@gmail.com> - 2013-08-07 01:16 +0100
            RE: Newbie: static typing? "Prasad, Ramit" <ramit.prasad@jpmorgan.com.dmarc.invalid> - 2013-08-08 16:46 +0000
    Re: Newbie: static typing? Steven D'Aprano <steve@pearwood.info> - 2013-08-06 05:21 +0000
      Re: Newbie: static typing? Rui Maciel <rui.maciel@gmail.com> - 2013-08-06 10:04 +0100
    Re: Newbie: static typing? Grant Edwards <invalid@invalid.invalid> - 2013-08-06 15:05 +0000

Page 2 of 2 — ← Prev page 1 [2]

#52020

Chris Angelico wrote:

> On Tue, Aug 6, 2013 at 10:01 AM, Rui Maciel <rui.maciel@gmail.com> wrote:
>> It would be nice if some functions threw an error if they were passed a
>> type
>> they don't support or weren't designed to handle.  That would avoid
>> having to deal with some bugs which otherwise would never happen.
>>
>> To avoid this sort of error, I've been testing arguments passed to some
>> functions based on their type, and raising TypeError when necessariy, but
>> surely there must be a better, more pythonic way to handle this issue.
> 
> def add_three_values(x,y,z):
>     return x+y+z
> 
> Do you want to test these values for compatibility? Remember, you
> could take a mixture of types, as most of the numeric types can safely
> be added. You can also add strings, or lists, but you can't mix them.
> And look! It already raises TypeError if it's given something
> unsuitable:

If the type problems aren't caught right away when the invalid types are 
passed to a function then the problem may only manifest itself in some far 
away point in the code, making this bug needlessly harder to spot and fix, 
and making the whole ordeal needlessly too time consuming.


Rui Maciel

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

#52028

On Tue, Aug 6, 2013 at 11:28 AM, Rui Maciel <rui.maciel@gmail.com> wrote:
> Chris Angelico wrote:
>> def add_three_values(x,y,z):
>>     return x+y+z
>>
>> Do you want to test these values for compatibility? Remember, you
>> could take a mixture of types, as most of the numeric types can safely
>> be added. You can also add strings, or lists, but you can't mix them.
>> And look! It already raises TypeError if it's given something
>> unsuitable:
>
> If the type problems aren't caught right away when the invalid types are
> passed to a function then the problem may only manifest itself in some far
> away point in the code, making this bug needlessly harder to spot and fix,
> and making the whole ordeal needlessly too time consuming.

There are two problems that can result from not checking:

1) The traceback will be deeper and may be less clear.

2) Some code will be executed and then an exception thrown.

If #2 is a problem, then you write checks in. (But be aware that
exceptions can be thrown from all sorts of places. It's usually better
to write your code to cope with exceptions than to write it to check
its args.) But that's a highly unusual case. With >99% of Python
scripts, it won't matter; programming errors are corrected by editing
the source and rerunning the program from the top. (There ARE
exceptions to this, but in Python they're relatively rare. In some of
my serverside programming (usually in Pike), I have to code in *much*
better protection than this. But if you're doing that sort of thing,
you'll know.)

So the real problem here is that, when there's a bug, the traceback is
longer and perhaps unclear. This is at times a problem, but it's not
as big a problem as the maintenance burden of all those extra type
checks. You might have a bug that takes you an extra few minutes to
diagnose because it's actually caused half way up the call stack (or,
worse, it doesn't come up in testing at all and it slips through into
production), but you save hours and hours of fiddling with the type
checks, and perhaps outright fighting them when you want to do
something more unusual. Or you write six versions of a function, with
different type checking. Any of these scenarios is, in my opinion, far
worse than the occasional bit of extra debugging work.

Like everything, it's a tradeoff. And if your function signatures are
sufficiently simple, you won't often get the args wrong anyway.

ChrisA

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

#52077

On Tue, 06 Aug 2013 11:28:07 +0100, Rui Maciel <rui.maciel@gmail.com>
declaimed the following:


>
>If the type problems aren't caught right away when the invalid types are 
>passed to a function then the problem may only manifest itself in some far 
>away point in the code, making this bug needlessly harder to spot and fix, 
>and making the whole ordeal needlessly too time consuming.
>
	Then wrap your code with a try/except block, allowing you to report a
misfunction at your level. That way anything that is viable can still work
without you restricting users of your module, yet you can handle the
failure, remove the extraneous (to you) low-level error trace, and raise a
failure apropos to your module.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#52079

On 8/6/2013 6:50 AM, Chris Angelico wrote:
> On Tue, Aug 6, 2013 at 11:28 AM, Rui Maciel <rui.maciel@gmail.com> wrote:
>> Chris Angelico wrote:
>>> def add_three_values(x,y,z):
>>>      return x+y+z
>>>
>>> Do you want to test these values for compatibility? Remember, you
>>> could take a mixture of types, as most of the numeric types can safely
>>> be added. You can also add strings, or lists, but you can't mix them.
>>> And look! It already raises TypeError if it's given something
>>> unsuitable:
>>
>> If the type problems aren't caught right away when the invalid types are
>> passed to a function then the problem may only manifest itself in some far
>> away point in the code, making this bug needlessly harder to spot and fix,
>> and making the whole ordeal needlessly too time consuming.
>
> There are two problems that can result from not checking:
>
> 1) The traceback will be deeper and may be less clear.
>
> 2) Some code will be executed and then an exception thrown.

3) The code falls into an infinite loop or recursion.

The solution is to think before looping or recursing.  This often 
involves value checking (non-negative int or non-fractional float, for 
instance) rather than type checking in the usual static type-checking sense.

One also needs to be careful about passing unbounded iterators to other 
functions and remember that unboundedness is contagious. (filter(pred, 
unbounded_iterator) is an unbounded iterator). Again, this is a 'value' 
or implicit sub-type issue rather than a explicit, visible 'type' issue.

Infinite recursion will be caught eventually when memory runs out (and 
that is an advantage of recursion over iteration ;-), but I prefer to 
avoid it anyway.

-- 
Terry Jan Reedy

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

#52093

On Wed, Aug 7, 2013 at 12:02 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> 3) The code falls into an infinite loop or recursion.
>
> The solution is to think before looping or recursing.  This often involves
> value checking (non-negative int or non-fractional float, for instance)
> rather than type checking in the usual static type-checking sense.

Yeah, there aren't many languages that let you declare that the
argument must be a positive integer. That's just something you have to
test for manually.

> One also needs to be careful about passing unbounded iterators to other
> functions and remember that unboundedness is contagious. (filter(pred,
> unbounded_iterator) is an unbounded iterator). Again, this is a 'value' or
> implicit sub-type issue rather than a explicit, visible 'type' issue.

Not quite always; I'd say that unboundedness is as contagious as IEEE
Infinity. Lots of operations on infinity will yield infinity, but a
few won't. itertools.islice can guarantee a finite iterator, and
takewhile may terminate. But yes, with filter() it certainly is.

ChrisA

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

#52213

Rui Maciel wrote:
> Chris Angelico wrote:
> 
> > On Tue, Aug 6, 2013 at 10:01 AM, Rui Maciel <rui.maciel@gmail.com> wrote:
> >> It would be nice if some functions threw an error if they were passed a
> >> type
> >> they don't support or weren't designed to handle.  That would avoid
> >> having to deal with some bugs which otherwise would never happen.
> >>
> >> To avoid this sort of error, I've been testing arguments passed to some
> >> functions based on their type, and raising TypeError when necessariy, but
> >> surely there must be a better, more pythonic way to handle this issue.
> >
> > def add_three_values(x,y,z):
> >     return x+y+z
> >
> > Do you want to test these values for compatibility? Remember, you
> > could take a mixture of types, as most of the numeric types can safely
> > be added. You can also add strings, or lists, but you can't mix them.
> > And look! It already raises TypeError if it's given something
> > unsuitable:
> 
> If the type problems aren't caught right away when the invalid types are
> passed to a function then the problem may only manifest itself in some far
> away point in the code, making this bug needlessly harder to spot and fix,
> and making the whole ordeal needlessly too time consuming.
> 
> 
> Rui Maciel

This can be true, but in personal experience does not happen 
often. I will say that dynamic typing ends up usually
being more future proof as I can later create a similar object
(but not in the same inheritance hierarchy) that will work
with older functions because the functions don't look for
certain types but rather just rely on duck typing.

I find this especially useful when testing or mocking. I can
create a test object and attach methods/attributes to the
test object to duck type as I desire to test the my desired code. 

I think the following reads are very interesting
for people new to Python from other languages (not just Java).
http://dirtsimple.org/2004/12/python-is-not-java.html
(and the flip side) http://dirtsimple.org/2004/12/java-is-not-python-either.html


~Ramit



This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.  

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

#52001

On Mon, 05 Aug 2013 21:46:57 +0100, Rui Maciel wrote:

> Is there any pythonic way to perform static typing?  After searching the
> web I've stumbled on a significant number of comments that appear to
> cover static typing as a proof of concept , but in the process I've
> found no tutorial on how to implement it.

Try Cobra instead. It's Python-like syntax, but allows static typing.

http://cobra-language.com/



-- 
Steven

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

#52005

Steven D'Aprano wrote:

> On Mon, 05 Aug 2013 21:46:57 +0100, Rui Maciel wrote:
> 
>> Is there any pythonic way to perform static typing?  After searching the
>> web I've stumbled on a significant number of comments that appear to
>> cover static typing as a proof of concept , but in the process I've
>> found no tutorial on how to implement it.
> 
> Try Cobra instead. It's Python-like syntax, but allows static typing.
> 
> http://cobra-language.com/

Thanks for the suggestion, but switching Python for another programming 
language would defeat the purpose of learning Python.


Rui Maciel

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

#52049

On 2013-08-05, Rui Maciel <rui.maciel@gmail.com> wrote:

> Is there any pythonic way to perform static typing?

No.

One of the fundamental characteristics of Python is dynamic typing.

Without dynamic typing, it wouldn't _be_ Python.

-- 
Grant Edwards               grant.b.edwards        Yow! I wonder if I ought
                                  at               to tell them about my
                              gmail.com            PREVIOUS LIFE as a COMPLETE
                                                   STRANGER?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web