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

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

I love assert

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

Contents

  I love assert Peter Cacioppi <peter.cacioppi@gmail.com> - 2014-11-11 11:40 -0800
    Re: I love assert Ben Finney <ben+python@benfinney.id.au> - 2014-11-12 07:03 +1100
      Re: I love assert Grant Edwards <invalid@invalid.invalid> - 2014-11-11 21:43 +0000
    Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-11 12:08 -0800
    Re: I love assert Rob Gaddi <rgaddi@technologyhighland.invalid> - 2014-11-11 12:20 -0800
    Re: I love assert Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-11-11 20:34 +0000
    Re: I love assert TP <wingusr@gmail.com> - 2014-11-11 12:57 -0800
    Re: I love assert Terry Reedy <tjreedy@udel.edu> - 2014-11-11 17:34 -0500
    Re: I love assert Ben Finney <ben+python@benfinney.id.au> - 2014-11-12 09:52 +1100
    Re: I love assert Tim Chase <python.list@tim.thechases.com> - 2014-11-11 17:03 -0600
    Re: I love assert Peter Cacioppi <peter.cacioppi@gmail.com> - 2014-11-11 15:02 -0800
    Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-11 15:38 -0800
    Re: I love assert Dan Stromberg <drsalists@gmail.com> - 2014-11-11 17:56 -0800
    Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-12 13:21 +1100
    Re: I love assert Ben Finney <ben+python@benfinney.id.au> - 2014-11-12 13:35 +1100
      Re: I love assert Grant Edwards <invalid@invalid.invalid> - 2014-11-12 14:10 +0000
    Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-12 13:44 +1100
      Re: I love assert wxjmfauth@gmail.com - 2014-11-11 23:14 -0800
    Re: I love assert Terry Reedy <tjreedy@udel.edu> - 2014-11-12 03:29 -0500
    Re: I love assert Anton <anton.schattenfeld@gmail.com> - 2014-11-12 12:53 -0800
      Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-12 23:41 +0200
        Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-12 13:52 -0800
          Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-12 23:56 +0200
            Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 15:04 -0700
              Re: I love assert Anton <anschatten@gmail.com> - 2014-11-12 14:13 -0800
                Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 15:41 -0700
                  Re: I love assert Anton <anschatten@gmail.com> - 2014-11-12 14:48 -0800
                    Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 01:01 +0200
                      Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-15 10:40 +1100
                        Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 02:12 +0200
                          Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-15 12:04 +1100
                            Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 03:30 +0200
                              Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-15 12:48 +1100
                              Re: I love assert Tim Chase <python.list@tim.thechases.com> - 2014-11-14 20:14 -0600
                              Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-15 13:16 +1100
                              Re: I love assert albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-11-29 17:35 +0000
                    Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 16:02 -0700
                      Re: I love assert Anton <anschatten@gmail.com> - 2014-11-12 15:43 -0800
                    Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-13 10:10 +1100
                      Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 01:23 +0200
                        Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-13 10:27 +1100
                          Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 01:31 +0200
                Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-12 14:47 -0800
                  Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-14 22:37 +1100
                    Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-14 09:40 -0700
            Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 15:07 -0700
              Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 00:47 +0200
                Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-12 14:56 -0800
                Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-13 09:58 +1100
                Re: I love assert Ian Kelly <ian.g.kelly@gmail.com> - 2014-11-12 16:05 -0700
                  Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 01:12 +0200
                Re: I love assert Lie Ryan <lie.1296@gmail.com> - 2014-11-14 01:09 +1100
          Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-14 22:33 +1100
            Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-14 10:18 -0800
              Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-14 21:12 +0200
                Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-14 12:41 -0800
                  Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-14 22:50 +0200
              Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-15 13:58 +1100
                Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-14 20:09 -0800
                  Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-17 13:09 +1100
                    Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-16 19:25 -0800
        Re: I love assert Anton <anschatten@gmail.com> - 2014-11-12 14:00 -0800
          Re: I love assert Anton <anschatten@gmail.com> - 2014-11-12 14:04 -0800
            Re: I love assert Marko Rauhamaa <marko@pacujo.net> - 2014-11-13 00:34 +0200
      Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-13 09:43 +1100
    Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-14 22:15 +1100
    Re: I love assert Richard Riehle <rriehle@itu.edu> - 2014-11-14 14:09 -0800
      Decorators (was: Re: I love assert) Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 00:18 +0200
        Re: Decorators Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-11-14 22:37 +0000
          Re: Decorators Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 00:47 +0200
        Re: Decorators (was: Re: I love assert) Richard Riehle <rriehle@itu.edu> - 2014-11-14 18:19 -0800
          Re: Decorators (was: Re: I love assert) Mayank Tripathi <oquanox@gmail.com> - 2014-11-15 02:36 +0000
          Re: Decorators (was: Re: I love assert) Tim Chase <python.list@tim.thechases.com> - 2014-11-14 20:30 -0600
            Re: Decorators Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 09:00 +0200
              Re: Decorators Grant Edwards <invalid@invalid.invalid> - 2014-11-15 15:32 +0000
          Re: Decorators (was: Re: I love assert) Richard Riehle <rriehle@itu.edu> - 2014-11-14 23:42 -0800
          Re: Decorators Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-11-15 13:12 +0000
            Re: Decorators Marko Rauhamaa <marko@pacujo.net> - 2014-11-15 15:24 +0200
              Re: Decorators Terry Reedy <tjreedy@udel.edu> - 2014-11-15 15:28 -0500
          Re: Decorators (was: Re: I love assert) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-16 02:39 +1100
    Re: I love assert TP <wingusr@gmail.com> - 2014-11-27 01:22 -0800
      Re: I love assert alister <alister.nospam.ware@ntlworld.com> - 2014-11-27 09:59 +0000
        Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-29 12:30 +1100
          Re: I love assert MRAB <python@mrabarnett.plus.com> - 2014-11-29 02:56 +0000
            Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-29 20:31 +1100
              Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-29 21:40 +1100
              Re: I love assert MRAB <python@mrabarnett.plus.com> - 2014-11-29 19:49 +0000
          Re: I love assert Chris Angelico <rosuav@gmail.com> - 2014-11-29 14:02 +1100
          Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-29 14:33 -0800
            Re: I love assert Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-11-30 19:18 +1100
              Re: I love assert Ethan Furman <ethan@stoneleaf.us> - 2014-11-30 11:34 -0800

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#80959

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/16/2014 06:09 PM, Steven D'Aprano wrote:
> Ethan Furman wrote:
>> On 11/14/2014 06:58 PM, Steven D'Aprano wrote:
>>> Ethan Furman wrote:
>>>> 
>>>> My point being:  a safety net that is so easily disabled does not count (IMHO) as a backup.
>>> 
>>> Assertions are not a backup or a safety net. [...]
>> 
>> Would you be happier if I phrased that as: Defensive programming techniques that can be unknowingly disabled by
>> the end-user aren't very helpful?
> 
> No.
> 
> You appear to be labouring under the misapprehension that assertion-based techniques (such as design by contract)
> are a technique for guarding against expected errors in (say) data.

I believe we are in violent agreement here.  My hissy-fit is not on the correct use of asserts, but their incorrect use.

- --
~Ethan~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJUaWqRAAoJENZ7D1rrH75N5pAQAKTiuIMWSpVYX80XdyPh036f
7FTvIerwaCtxwhBG2ma5GKQSXLIPIp6n6LQopnIN6Y82Odx6CqtUmlOpbrxZ4L5w
HG+GaCgBKPCP43ghP8NV+IDNK+mpz3g8uqa3F7ofgygDiBUqXg07/aBR2Eifkyl2
yoB9OjwRek2/m+KkUxe+hnEAmNjeyHF1+0rpFkjf04c4O38/fXJ2Gv6aoluoc/on
IdmST56ukgcVU9JjTTLD+PhLA8v/uvTHyFFQvGng9cUTIMxJEvItIikp+20VS1CP
PY8xJabI28TA4IEtC3atMwk/bDme2H6ovv0O0yvYswF38Y0u6U+NpNgKYUZfXKwS
nFHIJMFSfFpWddmxUGCNmjvGlDRVH5py11QGEl430PhUr3Y5re4MUglye9lFWoy9
NwSVA4c6zoM4lrgdZ2qzzDX8LUaLr1c//sNvS+kVaI6syIf0C60++QJGBboauIMR
lprJ65FfmiHhfI9e+7sS5KX09iILkuPjnwGi79CJG/TehfFcvueqDjNzRan8JzVX
/Czo3zwBK8B4cV13DBeRP2oaJcreMvA5bysXXKJ7iqZkLST+K8hiFpoKCGZiGdcZ
OBafvCwMqP5GzuCCzBxwAOIPo4KHR+KDVMarLZ+NI2kebZPTgKmWmtPrIIztTxE0
DFNrXUK0o8z0WGKP2Ke6
=tM/a
-----END PGP SIGNATURE-----

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

#80638

On Wednesday, November 12, 2014 1:41:20 PM UTC-8, Marko Rauhamaa wrote:
> Asserts help the reader of the code understand why some possibilities
> are not considered by the code. They are not considered because the
> writer of the code asserts they are not really possible.
I can see how assert statement can point out what should not happen, can you give an example. 

> I use asserts sparingly, just like comments (which asserts are). I use
> them to communicate nonobvious truths to the future maintainer of the
> code.
> 
> Or I might indicate the exhaustion of possibilities:
> 
>      if status == OK:
>          ...
>      elif status == ERROR:
>          ...
>      else:
>          assert status == WARNING
>          ...
Could you elaborate your example here? Basically, this type of error checking does not look familiar to me in Python code. In C when one works with descriptors and has to check status codes after every call it looks natural. Maybe I just haven't used it this way, so I'd really appreciate a more specific use case.

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

#80639

On Wednesday, November 12, 2014 2:00:35 PM UTC-8, Anton wrote:
> On Wednesday, November 12, 2014 1:41:20 PM UTC-8, Marko Rauhamaa wrote:
> > Asserts help the reader of the code understand why some possibilities
> > are not considered by the code. They are not considered because the
> > writer of the code asserts they are not really possible.
> I can see how assert statement can point out what should not happen, can you give an example. 

I messed up, meant to say:
I can see how assert statement can point out what should not happen, can you give an example when a single assert statement would explain why it should never happen?

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

#80645

Anton <anschatten@gmail.com>:

> I can see how assert statement can point out what should not happen,
> can you give an example when a single assert statement would explain
> why it should never happen?

Asserts don't communicate justifications. They simply assert something
to be the case, period. Any other elaborations must go in comments.


Marko

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

#80647

On Thu, Nov 13, 2014 at 7:53 AM, Anton <anton.schattenfeld@gmail.com> wrote:
> I am not sure how and when you use assert, but something that stops me from using assert is that in many cases I would use them to
> 1) Check type of an incoming argument/returned value
> 2) Check value of an incoming argument/returned value
> But the issues I can see here is that assert throws AssertError, while there is a specialized error for each of the case: 1) TypeError 2) ValueError.
> Moreover for the 1) case it makes it impossible to dynamically substitute an object with another object that implements the same interface.

The fact that there's a better exception type that's obviously more
correct is a strong hint that you shouldn't use assert for these two
cases. And your "Moreover" concern is a strong hint that you shouldn't
be checking at all :)

If you need to check this sort of thing, an explicit "if condition:
raise SomeError('message')" construct is a lot more useful. Otherwise,
there's no reason to have the line of code at all.

ChrisA

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

#80754

Peter Cacioppi wrote:

> I get the impression that most Pythonistas aren't as habituated with
> assert statements as I am. Is that just a misimpression on my part? If
> not, is there a good reason to assert less with Python than other
> languages?

I love assert, and use it frequently. But there are good reasons and bad
reasons to use it. I've written an essay about the good reasons to use
assert, e.g. defensive programming, program invariants, checked comments,
design by contract, and when not to use them, e.g. testing arguments to
public interfaces.

http://import-that.dreamwidth.org/676.html


> As far as I can tell, Python supports assert perfectly well. When run with
> the optimization flagging, the asserts are truly removed.
> 
> I think one needs to take care with some basic assert coding - it's not a
> substitute for unit tests, it doesn't absolve you of normal exception
> responsibilities, and, most of all, it should be used for passive
> inspection and not action. But given these guidelines, I still find it
> very useful as "active comments".

Agreed completely!



-- 
Steven

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

#80784

On Tuesday, November 11, 2014 11:41:06 AM UTC-8, Peter Cacioppi wrote:
> I get the impression that most Pythonistas aren't as habituated with assert statements as I am. Is that just a misimpression on my part? If not, is there a good reason to assert less with Python than other languages?
> 
> As far as I can tell, Python supports assert perfectly well. When run with the optimization flagging, the asserts are truly removed.
> 
> I think one needs to take care with some basic assert coding - it's not a substitute for unit tests, it doesn't absolve you of normal exception responsibilities, and, most of all, it should be used for passive inspection and not action. But given these guidelines, I still find it very useful as "active comments".
--------------------------------------------------------------------------
Reply & Comment:

I am new to this group, but really like Python.   One of the things I find helpful is to combine the assert with the decorator capability to produce code that is close to, although not identical to, the Design by Contract features built-in to Eiffel and Ada (2012).  I find that not a lot of Python user really appreciate the power of decorators.   

Richard Riehle, PhD, International Technological University, San Jose, CA.

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

#80786 — Decorators (was: Re: I love assert)

Richard Riehle <rriehle@itu.edu>:

> I find that not a lot of Python user really appreciate the power of
> decorators.

Well, I don't.

All it means is that I've never seen a use of decorators that has
enhanced the code. Once I "see the light," I'll have no problem changing
my view.


Marko

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

#80788 — Re: Decorators

On 14/11/2014 22:18, Marko Rauhamaa wrote:
> Richard Riehle <rriehle@itu.edu>:
>
>> I find that not a lot of Python user really appreciate the power of
>> decorators.
>
> Well, I don't.
>
> All it means is that I've never seen a use of decorators that has
> enhanced the code. Once I "see the light," I'll have no problem changing
> my view.
>

Perhaps this helps 
http://blog.dscpl.com.au/2014/01/how-you-implemented-your-python.html ?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#80790 — Re: Decorators

Mark Lawrence <breamoreboy@yahoo.co.uk>:

> Perhaps this helps
> http://blog.dscpl.com.au/2014/01/how-you-implemented-your-python.html ?

Thanks, but sorry, it didn't. I couldn't even relate to the supposed
WSGI craze.

I'm yet to face the situation where a colleague would point out, "See
how elegantly you could have done that using a decorator."


Marko

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

#80802 — Re: Decorators (was: Re: I love assert)

On Friday, November 14, 2014 2:18:48 PM UTC-8, Marko Rauhamaa wrote:
> Richard Riehle <rriehle@itu.edu>:
> 
> > I find that not a lot of Python user really appreciate the power of
> > decorators.
> 
> Well, I don't.
> 
> All it means is that I've never seen a use of decorators that has
> enhanced the code. Once I "see the light," I'll have no problem changing
> my view.
> 
> 
> Marko

Decorators are new in Python, so there are not a lot of people using them.  From my experience with other languages, especially Ada and Eiffel, I enjoy the benefit of assertions (as pre-conditions and post-conditions and invariants) at the specification level (not embedded in the code), so decorators are closer to my other experience.   They bring me closer to the Design by Contract model of Ada and Eiffel.   That is why I was so pleased to see them added to Python.  

It is true, however, that they are not immediately intutive in Python, but once understood, they are handy IMHO for improving code reliability.   Perhaps I was spoiled by having this capability in some other languages.

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

#80803 — Re: Decorators (was: Re: I love assert)

[Multipart message — attachments visible in raw view] — view raw

Decorators were there in Python 2.4, released in 2005. Not exactly new.

On Sat Nov 15 2014 at 7:51:11 AM Richard Riehle <rriehle@itu.edu> wrote:

> On Friday, November 14, 2014 2:18:48 PM UTC-8, Marko Rauhamaa wrote:
> > Richard Riehle <rriehle@itu.edu>:
> >
> > > I find that not a lot of Python user really appreciate the power of
> > > decorators.
> >
> > Well, I don't.
> >
> > All it means is that I've never seen a use of decorators that has
> > enhanced the code. Once I "see the light," I'll have no problem changing
> > my view.
> >
> >
> > Marko
>
> Decorators are new in Python, so there are not a lot of people using
> them.  From my experience with other languages, especially Ada and Eiffel,
> I enjoy the benefit of assertions (as pre-conditions and post-conditions
> and invariants) at the specification level (not embedded in the code), so
> decorators are closer to my other experience.   They bring me closer to the
> Design by Contract model of Ada and Eiffel.   That is why I was so pleased
> to see them added to Python.
>
> It is true, however, that they are not immediately intutive in Python, but
> once understood, they are handy IMHO for improving code reliability.
>  Perhaps I was spoiled by having this capability in some other languages.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

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

#80809 — Re: Decorators (was: Re: I love assert)

On 2014-11-14 18:19, Richard Riehle wrote:
> Decorators are new in Python, so there are not a lot of people
> using them. 

Um...they were introduced in 2.4 which was released in late 2004.  So
they've only been around for about (almost exactly) a decade.  Not
sure that qualifies as "new in Python".

And decorators are used pretty regularly in just about every
code-base that I've touched (I've been programming in Python since
early 2004, so I've maintained pre-2.4 code without decorators and
then brought it forward to 2.4 where decorators were usable).

-tkc

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

#80813 — Re: Decorators

Tim Chase <python.list@tim.thechases.com>:

> And decorators are used pretty regularly in just about every code-base
> that I've touched (I've been programming in Python since early 2004,
> so I've maintained pre-2.4 code without decorators and then brought it
> forward to 2.4 where decorators were usable).

Funny. My experience with Python is about as old, and I have yet to
encounter them in code. I have seen (maybe even used) @staticmethod once
or twice over a decade and then as a magic keyword rather than a
"decorator pattern."


Marko

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

#80826 — Re: Decorators

On 2014-11-15, Marko Rauhamaa <marko@pacujo.net> wrote:
> Tim Chase <python.list@tim.thechases.com>:
>
>> And decorators are used pretty regularly in just about every code-base
>> that I've touched (I've been programming in Python since early 2004,
>> so I've maintained pre-2.4 code without decorators and then brought it
>> forward to 2.4 where decorators were usable).
>
> Funny. My experience with Python is about as old, and I have yet to
> encounter them in code. I have seen (maybe even used) @staticmethod once
> or twice over a decade and then as a magic keyword rather than a
> "decorator pattern."

I've been using Python since 1999 and version 1.5.2 and have yet to
use decorators.  I do occasionally find myself in a spot where I'm
pretty sure that there's a more elegent way to do something using a
decorator, and promise myself that I'll read up on decorators one of
these days when I have some spare time...

-- 
Grant

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

#80814 — Re: Decorators (was: Re: I love assert)

[Multipart message — attachments visible in raw view] — view raw

Mayank,

Thanks.  I have only been using Python for about four years, so there are
features I have only recently discovered.   Decorators are one of them.  So
far, I encounter other Python users who are also unfamiliar with them.
When I discovered them, I instantly saw how they could be valuable.

Richard Riehle, PhD
Core Faculty, ITU

On Fri, Nov 14, 2014 at 6:36 PM, Mayank Tripathi <oquanox@gmail.com> wrote:

> Decorators were there in Python 2.4, released in 2005. Not exactly new.
>
> On Sat Nov 15 2014 at 7:51:11 AM Richard Riehle <rriehle@itu.edu> wrote:
>
>> On Friday, November 14, 2014 2:18:48 PM UTC-8, Marko Rauhamaa wrote:
>> > Richard Riehle <rriehle@itu.edu>:
>> >
>> > > I find that not a lot of Python user really appreciate the power of
>> > > decorators.
>> >
>> > Well, I don't.
>> >
>> > All it means is that I've never seen a use of decorators that has
>> > enhanced the code. Once I "see the light," I'll have no problem changing
>> > my view.
>> >
>> >
>> > Marko
>>
>> Decorators are new in Python, so there are not a lot of people using
>> them.  From my experience with other languages, especially Ada and Eiffel,
>> I enjoy the benefit of assertions (as pre-conditions and post-conditions
>> and invariants) at the specification level (not embedded in the code), so
>> decorators are closer to my other experience.   They bring me closer to the
>> Design by Contract model of Ada and Eiffel.   That is why I was so pleased
>> to see them added to Python.
>>
>> It is true, however, that they are not immediately intutive in Python,
>> but once understood, they are handy IMHO for improving code reliability.
>>  Perhaps I was spoiled by having this capability in some other languages.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>

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

#80822 — Re: Decorators

On 15/11/2014 07:42, Richard Riehle wrote:
> Mayank,
>
> Thanks.  I have only been using Python for about four years, so there
> are features I have only recently discovered.   Decorators are one of
> them.  So far, I encounter other Python users who are also unfamiliar
> with them.  When I discovered them, I instantly saw how they could be
> valuable.
>
> Richard Riehle, PhD
> Core Faculty, ITU
>

Would you please be kind enough to get a PhD in interspersing your 
replies or bottom posting rather than top posting, thank you.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#80823 — Re: Decorators

Mark Lawrence <breamoreboy@yahoo.co.uk>:

> On 15/11/2014 07:42, Richard Riehle wrote:
>> When I discovered them, I instantly saw how they could be valuable.
>
> Would you please be kind enough to get a PhD in interspersing your
> replies or bottom posting rather than top posting, thank you.

I'd take top-posting if I were enlightened about how decorators could be
valuable. Sadly, I didn't see it instantly, or even afterwards.


Marko

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

#80839 — Re: Decorators

On 11/15/2014 8:24 AM, Marko Rauhamaa wrote:

> I'd take top-posting if I were enlightened about how decorators could be
> valuable.

Here is part of the original rationale.

@deco(arg)
def f: suite

is (for this discussion) equivalent to

def f: suite
f = deco(arg)(f)

The latter requires writing 'f' 3 times instead of 1.  Now suppose to 
meet external requirements, such as interfacing to Objective C, you had 
to wrap dozens of functions, each with long names, up to 30 chars, with 
multiple components.  You would then become enlightened.

Once the idea of making function wrapping easier emerged, many other 
applications emerged.  Various stdlib modules define decorators.

If you do not need to wrap functions, easy wrapping might seem useless 
to you.  That's fine. You know they are there should you ever have need.

-- 
Terry Jan Reedy

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

#80827 — Re: Decorators (was: Re: I love assert)

Richard Riehle wrote:

> Decorators are new in Python, so there are not a lot of people using them.


The principle of decorators themselves is as old as Python itself. You could
implement them as far back as Python 1.5, if not older:


[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09:18)  [GCC 4.1.2 20080704 (Red Hat
4.1.2-52)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> def decorator(func):
...     def inner(arg, func=func):
...             return func(arg*2)
...     return inner
...
>>> def f(x):
...     return x + 1
...
>>> f = decorator(f)
>>> f(1)
3
>>> f(5)
11


The first built-in decorators (classmethod, staticmethod and property) were
added in Python 2.2. Decorator syntax using @ was added in 2.4.

https://docs.python.org/2/whatsnew/2.4.html#pep-318-decorators-for-functions-and-methods

So decorators have been available for a very long time.


> From my experience with other languages, especially Ada and Eiffel, I
> enjoy the benefit of assertions (as pre-conditions and post-conditions and
> invariants) at the specification level (not embedded in the code), so
> decorators are closer to my other experience.   They bring me closer to
> the Design by Contract model of Ada and Eiffel.   That is why I was so
> pleased to see them added to Python.


Way back in Python 1.5, Guido van Rossum wrote an essay describing a way to
get Eiffel-like checks for pre-conditions and post-conditions:

https://www.python.org/doc/essays/metaclasses/

(Alas, the link to Eiffel.py is currently broken. But you can read the rest
of the essay.)


> It is true, however, that they are not immediately intutive in Python, but
> once understood, they are handy IMHO for improving code reliability.  
> Perhaps I was spoiled by having this capability in some other languages.

-- 
Steven

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web