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 that they can
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 of the
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 think you meant
On Sat, Nov 29, 2014 at 8:31 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
In article 87a93tl07u@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Most importantly, assertion failures are not supposed to be recovered
from (within the program).
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
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 reports
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 product
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. :-)
On Sat, Nov 29, 2014 at 1:56 PM, MRAB pyt...@mrabarnett.plus.com 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
On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi peter.cacio...@gmail.com
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
On Thu, 27 Nov 2014 01:22:37 -0800, TP wrote:
On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi
peter.cacio...@gmail.com
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
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 net. [...]
Would
-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
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,
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
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
...
And here's a nice
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, but
On Fri, Nov 14, 2014 at 4:37 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
-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 of
Ethan Furman et...@stoneleaf.us:
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
-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 this
Ethan Furman et...@stoneleaf.us:
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
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?
Richard Riehle rrie...@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
--
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;
-
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa ma...@pacujo.net 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
Chris Angelico ros...@gmail.com:
On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa ma...@pacujo.net 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
On Sat, Nov 15, 2014 at 12:30 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
On Sat, Nov 15, 2014 at 11:12 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Most importantly, assertion failures are not supposed to be recovered
from (within the program). Assertion
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)
On Sat, Nov 15, 2014 at 1:14 PM, Tim Chase
python.l...@tim.thechases.com 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
On Friday, November 14, 2014 2:18:48 PM UTC-8, Marko Rauhamaa wrote:
Richard Riehle rrie...@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.
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 rrie...@itu.edu wrote:
On Friday, November 14, 2014 2:18:48 PM UTC-8, Marko Rauhamaa wrote:
Richard Riehle rrie...@itu.edu:
I find that not a lot of Python user really
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/676.html
-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 I
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.
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.
On 13/11/14 10:05, Ian Kelly wrote:
On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Ian Kelly ian.g.ke...@gmail.com:
Apart from idiomatic style, there is no difference between
# never reached
assert False
raise RuntimeError('Unreachable code reached')
On 11/11/2014 5:52 PM, Ben Finney wrote:
Terry Reedy tjre...@udel.edu 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
On 2014-11-12, Ben Finney ben+pyt...@benfinney.id.au wrote:
Chris Angelico ros...@gmail.com writes:
On Wed, Nov 12, 2014 at 7:03 AM, Ben Finney ben+pyt...@benfinney.id.au
wrote:
An ‘assert’ statement in the code will sometimes be active, and
sometimes be a no-op, for *exactly* the same
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
Anton anton.schattenf...@gmail.com:
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
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.
Ethan Furman et...@stoneleaf.us:
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
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
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
On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Ethan Furman et...@stoneleaf.us:
On 11/12/2014 01:41 PM, Marko Rauhamaa wrote:
Or I might indicate the exhaustion of possibilities:
if status == OK:
...
elif status == ERROR:
...
On Wed, Nov 12, 2014 at 3:04 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa ma...@pacujo.net 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
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:
...
elif
Anton anschat...@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
On Wed, Nov 12, 2014 at 3:13 PM, Anton anschat...@gmail.com 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
On Thu, Nov 13, 2014 at 7:53 AM, Anton anton.schattenf...@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
On 11/12/2014 02:41 PM, Ian Kelly wrote:
On Wed, Nov 12, 2014 at 3:13 PM, Anton anschat...@gmail.com 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
Ian Kelly ian.g.ke...@gmail.com:
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
On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote:
On Wed, Nov 12, 2014 at 3:13 PM, Anton an...@gmail.com 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
On 11/12/2014 02:47 PM, Marko Rauhamaa wrote:
Ian Kelly ian.g.ke...@gmail.com:
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
On Thu, Nov 13, 2014 at 9:47 AM, Marko Rauhamaa ma...@pacujo.net 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
On Wed, Nov 12, 2014 at 3:48 PM, Anton anschat...@gmail.com wrote:
On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote:
On Wed, Nov 12, 2014 at 3:13 PM, Anton an...@gmail.com wrote:
If the code is run optimized and asserts are ignore CONFUSED statement
would still not be handled and
Anton anschat...@gmail.com:
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
On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Ian Kelly ian.g.ke...@gmail.com:
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
On Thu, Nov 13, 2014 at 10:02 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Wed, Nov 12, 2014 at 3:48 PM, Anton anschat...@gmail.com wrote:
On Wednesday, November 12, 2014 2:42:19 PM UTC-8, Ian wrote:
On Wed, Nov 12, 2014 at 3:13 PM, Anton an...@gmail.com wrote:
If the code is run optimized
Ian Kelly ian.g.ke...@gmail.com:
On Wed, Nov 12, 2014 at 3:47 PM, Marko Rauhamaa ma...@pacujo.net 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
Chris Angelico ros...@gmail.com:
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
On Thu, Nov 13, 2014 at 10:23 AM, Marko Rauhamaa ma...@pacujo.net 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
Chris Angelico ros...@gmail.com:
On Thu, Nov 13, 2014 at 10:23 AM, Marko Rauhamaa ma...@pacujo.net 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
On Wednesday, November 12, 2014 3:03:18 PM UTC-8, Ian wrote:
On Wed, Nov 12, 2014 at 3:48 PM, Anton a...@gmail.com wrote:
Sure, which is why you and I have both suggested raising a RuntimeError
instead.
Yeah, I actually read it after sending my response :)
--
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
Peter Cacioppi peter.cacio...@gmail.com 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
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,
On Tue, 11 Nov 2014 11:40:38 -0800 (PST)
Peter Cacioppi peter.cacio...@gmail.com 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
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
On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi peter.cacio...@gmail.com
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
- Original Message -
From: Ethan Furman et...@stoneleaf.us
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 Pythonistas aren't as habituated
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
On 2014-11-11, Ben Finney ben+pyt...@benfinney.id.au 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
- Original Message -
From: Ethan Furman et...@stoneleaf.us
To: Albert-Jan Roskam fo...@yahoo.com
Cc: python-list@python.org 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
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
Terry Reedy tjre...@udel.edu 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
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 catches
On Tue, Nov 11, 2014 at 12:57 PM, TP wing...@gmail.com wrote:
On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi peter.cacio...@gmail.com
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
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
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 $
On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi
peter.cacio...@gmail.com 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
On Wed, Nov 12, 2014 at 7:03 AM, Ben Finney ben+pyt...@benfinney.id.au 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
Chris Angelico ros...@gmail.com writes:
On Wed, Nov 12, 2014 at 7:03 AM, Ben Finney ben+pyt...@benfinney.id.au
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
On Wed, Nov 12, 2014 at 1:35 PM, Ben Finney ben+pyt...@benfinney.id.au 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.
87 matches
Mail list logo
