Re: I love assert

On 11/30/2014 12:18 AM, Steven D'Aprano wrote: > > Ah, wait, I see the reference. You're talking about the quote from James O > Coplien: > > "An even more professional approach is to leave the assertions > in the code when you ship, and to automatically file a bug report > on behalf

Re: I love assert

Ethan Furman wrote: > On 11/28/2014 05:30 PM, Steven D'Aprano wrote: >> alister wrote: >> >>> And as may wiser people than me have already highlighted Assertions can >>> be switched off in python which means they cannot be relied upon in >>> production code invalidating the authors suggestion tha

Re: I love assert

On 11/28/2014 05:30 PM, Steven D'Aprano wrote: > alister wrote: > >> And as may wiser people than me have already highlighted Assertions can >> be switched off in python which means they cannot be relied upon in >> production code invalidating the authors suggestion that they can >> automate bug r

Re: I love assert

On 2014-11-29 09:31, Steven D'Aprano wrote: MRAB wrote: On 2014-11-29 01:30, Steven D'Aprano wrote: [snip] I stress that assertions aren't a replacement for unit testing, but they compliment unit testing: assertions can help cover code missed by your unit tests, and check that your unit tests

Re: I love assert

In article <87a93tl07u@elektro.pacujo.net>, Marko Rauhamaa wrote: >Chris Angelico : > >> On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa wrote: >>> Most importantly, assertion failures are not supposed to be recovered >>> from (within the program). Assertion failures can result in the loss

Re: I love assert

On Sat, Nov 29, 2014 at 8:31 PM, Steven D'Aprano wrote: > Somibody swappid thi i and e kiys on my kiboard. You know the old rule. "I" before "E", except after "QW"... ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: I love assert

MRAB wrote: > On 2014-11-29 01:30, Steven D'Aprano wrote: > [snip] >> I stress that assertions aren't a replacement for unit testing, but they >> compliment unit testing: assertions can help cover code missed by your >> unit tests, and check that your unit tests are correct. >> > [snip] > > I thi

Re: I love assert

On Sat, Nov 29, 2014 at 1:56 PM, MRAB wrote: > On 2014-11-29 01:30, Steven D'Aprano wrote: > [snip] >> >> I stress that assertions aren't a replacement for unit testing, but they >> compliment unit testing: assertions can help cover code missed by your >> unit >> tests, and check that your unit te

Re: I love assert

On 2014-11-29 01:30, Steven D'Aprano wrote: [snip] I stress that assertions aren't a replacement for unit testing, but they compliment unit testing: assertions can help cover code missed by your unit tests, and check that your unit tests are correct. [snip] I think you meant "complement". :-)

Re: I love assert

alister wrote: > And as may wiser people than me have already highlighted Assertions can > be switched off in python which means they cannot be relied upon in > production code invalidating the authors suggestion that they can > automate bug reports & "Extend testing into the lifetime of the produ

Re: I love assert

On Thu, 27 Nov 2014 01:22:37 -0800, TP wrote: > On Tue, Nov 11, 2014 at 11:40 AM, 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 ass

Re: I love assert

On Tue, Nov 11, 2014 at 11:40 AM, 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 ca

Re: I love assert

-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.

Re: I love assert

Ethan Furman wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > 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 n

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

Re: Decorators (was: Re: I love assert)

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.

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"

Re: I love assert

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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

Re: I love assert

Ethan Furman wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/14/2014 03:33 AM, Steven D'Aprano wrote: >> >> I agree with Marko in this case. Marko's example of defensive programming >> is very similar to the one I gave in my essay here: >> >> http://import-that.dreamwidth.org

Re: Decorators (was: Re: I love assert)

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 wrote: > On Friday, November 14, 2014 2:18:48 PM UTC-8, Marko Rauhamaa wrote: > > Richard Riehle : > > > > > I find that not a lot of Python user really appreciate the power of

Re: Decorators (was: Re: I love assert)

On Friday, November 14, 2014 2:18:48 PM UTC-8, Marko Rauhamaa wrote: > Richard Riehle : > > > 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 "

Re: I love assert

On Sat, Nov 15, 2014 at 1:14 PM, Tim Chase wrote: > On 2014-11-15 12:48, Chris Angelico wrote: >> conn = establish_database_connection() >> try: >> do_stuff() >> finally: >> conn.rollback() > > this sounds suspiciously like you'd never actually commit. Do you > mean something like > > c

Re: I love assert

On 2014-11-15 12:48, Chris Angelico wrote: > conn = establish_database_connection() > try: > do_stuff() > finally: > conn.rollback() this sounds suspiciously like you'd never actually commit. Do you mean something like conn = establisth_database_connection() try: do_stuff(conn)

Re: I love assert

On Sat, Nov 15, 2014 at 12:30 PM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa wrote: >>> Most importantly, assertion failures are not supposed to be recovered >>> from (within the program). Assertion failures can result in the loss >>> of life an

Re: I love assert

Chris Angelico : > On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa wrote: >> Most importantly, assertion failures are not supposed to be recovered >> from (within the program). Assertion failures can result in the loss >> of life and limb. They can result in database corruption. They can >> resu

Re: I love assert

On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa wrote: > Most importantly, assertion failures are not supposed to be recovered > from (within the program). Assertion failures can result in the loss of > life and limb. They can result in database corruption. They can result > in monetary losses. T

Re: I love assert

Steven D'Aprano : > Marko Rauhamaa wrote: > >> Asserts are not about notification, checking or optimization. They are >> about communicating what's going on in the programmer's mind. They are >> comments. > > Assertions can be used for *all of these things*. > > Assertions can be used for: > > - c

Re: I love assert

Marko Rauhamaa wrote: > Asserts are not about notification, checking or optimization. They are > about communicating what's going on in the programmer's mind. They are > comments. Assertions can be used for *all of these things*. Assertions can be used for: - checking internal program logic; -

Decorators (was: Re: I love assert)

Richard Riehle : > 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 -- https://mail.python.

Re: I love assert

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? >

Re: I love assert

Ethan Furman : > Python the language is just the opposite: debug mode is on /by > default/, and to turn it off you have to specify -O: C's the same way. When I did Java, we enabled assertions in production code. Marko -- https://mail.python.org/mailman/listinfo/python-list

Re: I love assert

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/2014 11:12 AM, Marko Rauhamaa wrote: > Ethan Furman wrote: > >> My point being: a safety net that is so easily disabled does not count >> (IMHO) as a backup. > > Correct. You never lean on assertions. They are primarily formal comments. On

Re: I love assert

Ethan Furman : > My point being: a safety net that is so easily disabled does not count > (IMHO) as a backup. Correct. You never lean on assertions. They are primarily formal comments. However, assertion failures do help in troubleshooting occasionally. Most importantly, they immediately, unques

Re: I love assert

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/2014 03:33 AM, Steven D'Aprano wrote: > > I agree with Marko in this case. Marko's example of defensive programming is > very similar to the one I gave in my > essay here: > > http://import-that.dreamwidth.org/676.html > > You're correct o

Re: I love assert

On Fri, Nov 14, 2014 at 4:37 AM, Steven D'Aprano wrote: > Ethan Furman wrote: > >>> There's no way to make the CONFUSED status be handled without actually >>> changing the code. The difference is that this version will not >>> incorrectly treat CONFUSED as WARNING; it just won't do anything at >>>

Re: I love assert

Ethan Furman wrote: >> There's no way to make the CONFUSED status be handled without actually >> changing the code. The difference is that this version will not >> incorrectly treat CONFUSED as WARNING; it just won't do anything at >> all if the code is optimized. > > So, a different wrong thing,

Re: I love assert

Ethan Furman wrote: > On 11/12/2014 01:41 PM, Marko Rauhamaa wrote: >> >> Or I might indicate the exhaustion of possibilities: >> >> if status == OK: >> ... >> elif status == ERROR: >> ... >> else: >> assert status == WARNING >> ... > > An

Re: I love assert

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 ar

Re: I love assert

On 13/11/14 10:05, Ian Kelly wrote: On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa wrote: Ian Kelly : Apart from idiomatic style, there is no difference between # never reached assert False raise RuntimeError('Unreachable code reached') If the purpose is communication, the

Re: I love assert

On Wednesday, November 12, 2014 3:03:18 PM UTC-8, Ian wrote: > On Wed, Nov 12, 2014 at 3:48 PM, Anton wrote: > Sure, which is why you and I have both suggested raising a RuntimeError > instead. Yeah, I actually read it after sending my response :) -- https://mail.python.org/mailman/listinfo/pyth

Re: I love assert

Chris Angelico : > On Thu, Nov 13, 2014 at 10:23 AM, Marko Rauhamaa wrote: >> However, the programmer could have played this frustration out already >> in his head and written: >> >> assert len(choices) > 0 >> count = next_size / len(choices) > > assert choices > count = next_size / len

Re: I love assert

On Thu, Nov 13, 2014 at 10:23 AM, Marko Rauhamaa wrote: > However, the programmer could have played this frustration out already > in his head and written: > > assert len(choices) > 0 > count = next_size / len(choices) assert choices count = next_size / len(choices) Or even just: coun

Re: I love assert

Chris Angelico : > Or, in as many cases as possible, raise an implicit KeyError and save > yourself a lot of typing. Any time these kinds of elif trees can be > turned into dict lookups, you get non-assert error checking for free. I agree that you shouldn't sprinkle asserts around the code. But c

Re: I love assert

Ian Kelly : > On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa wrote: >> Asserts have nothing to do with them being optimized out. Asserts are >> communication. >> >> Apart from idiomatic style, there is no difference between >> >> # never reached >> >> assert False >> >> raise Runtime

Re: I love assert

On Thu, Nov 13, 2014 at 10:02 AM, Ian Kelly wrote: > On Wed, Nov 12, 2014 at 3:48 PM, Anton wrote: >> On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote: >>> On Wed, Nov 12, 2014 at 3:13 PM, Anton wrote: >>> > If the code is run optimized and asserts are ignore CONFUSED statement >>> >

Re: I love assert

On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa wrote: > Ian Kelly : > >> Although to be honest I'd rather use something like "raise >> RuntimeError('Unreachable code reached')" than "assert False" here. If >> the expectation is that the code will never be executed, then there's >> no reason to ev

Re: I love assert

Anton : > Right, but the goal is not to make the CONFUSED status be handled > without coding, but to be notified about an unknown status code and > act accordingly. Asserts are not about notification, checking or optimization. They are about communicating what's going on in the programmer's mind.

Re: I love assert

On Wed, Nov 12, 2014 at 3:48 PM, Anton wrote: > On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote: >> On Wed, Nov 12, 2014 at 3:13 PM, Anton wrote: >> > If the code is run optimized and asserts are ignore CONFUSED statement >> > would still not be handled and you will not know about it

Re: I love assert

On Thu, Nov 13, 2014 at 9:47 AM, Marko Rauhamaa wrote: > Apart from idiomatic style, there is no difference between > > # never reached > > assert False > > raise RuntimeError('Unreachable code reached') > > 1 / 0 > > print("Hello world") > > since, after all, that line is neve

Re: I love assert

On 11/12/2014 02:47 PM, Marko Rauhamaa wrote: Ian Kelly : Although to be honest I'd rather use something like "raise RuntimeError('Unreachable code reached')" than "assert False" here. If the expectation is that the code will never be executed, then there's no reason to ever optimize it out.

Re: I love assert

On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote: > On Wed, Nov 12, 2014 at 3:13 PM, Anton wrote: > > If the code is run optimized and asserts are ignore CONFUSED statement > > would still not be handled and you will not know about it. > > I would do something like: > > There's no way

Re: I love assert

Ian Kelly : > Although to be honest I'd rather use something like "raise > RuntimeError('Unreachable code reached')" than "assert False" here. If > the expectation is that the code will never be executed, then there's > no reason to ever optimize it out. Asserts have nothing to do with them being

Re: I love assert

On 11/12/2014 02:41 PM, Ian Kelly wrote: On Wed, Nov 12, 2014 at 3:13 PM, Anton wrote: On Wednesday, November 12, 2014 2:05:17 PM UTC-8, Ian wrote: You don't need to remove it. Just reorganize it to make sure it indicates actual exhaustion of possibilities. E.g. using the "assert False" patter

Re: I love assert

On Thu, Nov 13, 2014 at 7:53 AM, Anton 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

Re: I love assert

On Wed, Nov 12, 2014 at 3:13 PM, Anton wrote: > On Wednesday, November 12, 2014 2:05:17 PM UTC-8, Ian wrote: >> You don't need to remove it. Just reorganize it to make sure it >> indicates actual exhaustion of possibilities. E.g. using the "assert >> False" pattern from your post: >> >> if status

Re: I love assert

Anton : > 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

Re: I love assert

On Wednesday, November 12, 2014 2:05:17 PM UTC-8, Ian wrote: > On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa wrote: > > Ethan Furman: > > > >> On 11/12/2014 01:41 PM, Marko Rauhamaa wrote: > >>> > >>> Or I might indicate the exhaustion of possibilities: > >>> > >>> if status == OK: > >>>

Re: I love assert

On Wed, Nov 12, 2014 at 3:04 PM, Ian Kelly wrote: > On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa wrote: >> How would it be better if you removed the assert then? > > You don't need to remove it. Just reorganize it to make sure it > indicates actual exhaustion of possibilities. E.g. using the "

Re: I love assert

On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa wrote: > Ethan Furman : > >> On 11/12/2014 01:41 PM, Marko Rauhamaa wrote: >>> >>> Or I might indicate the exhaustion of possibilities: >>> >>> if status == OK: >>> ... >>> elif status == ERROR: >>> ... >>> else:

Re: I love assert

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 state

Re: I love assert

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 th

Re: I love assert

Ethan Furman : > On 11/12/2014 01:41 PM, Marko Rauhamaa wrote: >> >> Or I might indicate the exhaustion of possibilities: >> >> if status == OK: >> ... >> elif status == ERROR: >> ... >> else: >> assert status == WARNING >> ... > > And here

Re: I love assert

On 11/12/2014 01:41 PM, Marko Rauhamaa wrote: Or I might indicate the exhaustion of possibilities: if status == OK: ... elif status == ERROR: ... else: assert status == WARNING ... And here's a nice example of what one should NOT do.

Re: I love assert

Anton : > 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 You use asserts to boldly state that the as

Re: I love assert

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? >

Re: I love assert

On 2014-11-12, Ben Finney wrote: > Chris Angelico writes: > >> On Wed, Nov 12, 2014 at 7:03 AM, Ben Finney >> wrote: >> > An ‘assert’ statement in the code will sometimes be active, and >> > sometimes be a no-op, for *exactly* the same code under different >> > circumstances. That's a trap for

Re: I love assert

On 11/11/2014 5:52 PM, Ben Finney wrote: Terry Reedy writes: We love 'assert' so much that we have 20-30 'assertXYZ' variations in unittest. A function will not be disabled by a run-time option to the Python interpreter. The statement 'assert expression' is almost equivalent to if not exp

Re: I love assert

On Wed, Nov 12, 2014 at 1:35 PM, Ben Finney wrote: > The more things people need to keep in mind when reading my code that > isn't stated explicitly in the code, the worse I consider the code to > be. Then the ternary if/else operator should also be abolished. track["APIC:"].data if "APIC:" in t

Re: I love assert

Chris Angelico writes: > On Wed, Nov 12, 2014 at 7:03 AM, Ben Finney > wrote: > > An ‘assert’ statement in the code will sometimes be active, and > > sometimes be a no-op, for *exactly* the same code under different > > circumstances. That's a trap for the reader, and I'd rather not set > > it.

Re: I love assert

On Wed, Nov 12, 2014 at 7:03 AM, Ben Finney wrote: > An ‘assert’ statement in the code will sometimes be active, and > sometimes be a no-op, for *exactly* the same code under different > circumstances. That's a trap for the reader, and I'd rather not set it. This is no worse than other forms of p

Re: I love assert

On Tue, Nov 11, 2014 at 11:40 AM, 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 c

Re: I love assert

On 11/11/2014 01:46 PM, Albert-Jan Roskam wrote: Ethan Furman wrote: I don't know, haven't used it nor read the code. It would certainly not be good if it failed in optimized mode. antonia@antonia-HP-2133 /tmp $ python -O test.py Ran 2 tests in 0.015s OK antonia@antonia-HP-2133 /tmp $ pytho

Re: I love assert

On 11/11/2014 03:02 PM, Peter Cacioppi wrote: On Tue, Nov 11, 2014 at 12:57 PM, TP wrote: PyCharm uses docstrings to accomplish the same task [2] but can also use asserts/isinstance [3]. [2] https://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pycharm.html

Re: I love assert

On Tue, Nov 11, 2014 at 12:57 PM, TP wrote: > On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi > wrote: > >> 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, i

Re: I love assert

On 2014-11-11 11:40, 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? I tend to use it to catch my bone-headedness rather than actual tests. I'm particularly fond of one that catche

Re: I love assert

Terry Reedy writes: > We love 'assert' so much that we have 20-30 'assertXYZ' variations in > unittest. A function will not be disabled by a run-time option to the Python interpreter. > The statement 'assert expression' is almost equivalent to > > if not expression: raise AssertionError('expres

Re: I love assert

On 11/11/2014 2:40 PM, 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? We love 'assert' so much that we

Re: I love assert

- Original Message - > From: Ethan Furman > To: Albert-Jan Roskam > Cc: "python-list@python.org" > Sent: Tuesday, November 11, 2014 10:15 PM > Subject: Re: I love assert > > On 11/11/2014 01:09 PM, Albert-Jan Roskam wrote: >> Ethan Furman wrote

Re: I love assert

On 2014-11-11, Ben Finney wrote: > An ‘assert’ statement in the code will sometimes be active, and > sometimes be a no-op, for *exactly* the same code under different > circumstances. Yep, it's the same in C, C++, Java, PHP, and other languages. I think most people know that asserts can be disa

Re: I love assert

On 11/11/2014 01:09 PM, Albert-Jan Roskam wrote: Ethan Furman wrote: asserts are a specialized tool, easily abused. Sounds like you are using them exactly as intended. Would you say that assert is baaadly abused in nose?*) I never tried it, but probably all tests pass when Python is run wit

Re: I love assert

- Original Message - > From: Ethan Furman > To: python-list@python.org > Cc: > Sent: Tuesday, November 11, 2014 9:08 PM > Subject: Re: I love assert > > On 11/11/2014 11:40 AM, Peter Cacioppi wrote: >> >> I get the impression that most Pyth

Re: I love assert

On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi wrote: > 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 acti

Re: I love assert

On 11/11/2014 19:40, 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 suppo

Re: I love assert

On Tue, 11 Nov 2014 11:40:38 -0800 (PST) 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 f

Re: I love assert

On 11/11/2014 11:40 AM, 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

Re: I love assert

Peter Cacioppi writes: > 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 don't know about comparisons like “use less wi