On 13/05/2022 18:37, bryangan41 wrote:
Is the following LBYL:foo = 123if foo < 200: do()If so, how to change to
EAFP?Thanks!Sent from Samsung tablet.
The distinction between look-before-you-leap and
easier-to-ask-forgiveness-than-permission is weaker than yo might expect.
When you wr
On 14/05/2022 04.37, bryangan41 wrote:
> Is the following LBYL:foo = 123if foo < 200: do()
Yes (once formatted for Python).
If so, how to change to EAFP?
Not sure if can. Let's alter the code to:
foo = 0
#and
def do():
return 5 / foo
Then, you will expect a ZeroDi
Is the following LBYL:foo = 123if foo < 200: do()If so, how to change to
EAFP?Thanks!Sent from Samsung tablet.
--
https://mail.python.org/mailman/listinfo/python-list
On 2019-11-18 19:00:41 -0500, Mark Turner wrote:
[trivial test]
> I think this simple test like has value. It’s just not where you
> expect it to be. In order to get this test to pass you have to have
> your development environment set up, your testing environment set up
> and perhaps some basic d
On Mon, Nov 18, 2019 at 3:23 PM Peter J. Holzer wrote:
>
> I don't know what "proper" TDD is (and even less "proper consideration"
> of TDD), but TDD is in my opinion very much rooted in the agile mindset.
> And that means frequent iteration and improvement. So I think the
> micro-iteration techni
> On Nov 18, 2019, at 4:07 PM, Peter J. Holzer wrote:
>
> On 2019-11-13 15:16:55 +1300, DL Neil via Python-list wrote:
>> On 4/11/19 9:44 AM, Peter J. Holzer wrote:
>>> TDD does in my opinion encourage EAFP thinking.
>>>
>>> The TDD is usually:
>&
On 2019-11-13 15:16:55 +1300, DL Neil via Python-list wrote:
> On 4/11/19 9:44 AM, Peter J. Holzer wrote:
> > TDD does in my opinion encourage EAFP thinking.
> >
> > The TDD is usually:
> >
> > 1 Write a test
> > 2 Write the minimal amount of code
On 6/11/19 8:01 AM, Barry Scott wrote:
On 1 Nov 2019, at 05:40, DL Neil via Python-list wrote:
Is the practice of TDD fundamentally, if not philosophically, somewhat contrary
to Python's EAFP approach?
The practice of TDD* is that one writes test routines to prove a unit of code,
eg m
actice of TDD fundamentally, if not philosophically,
somewhat contrary to Python's EAFP approach?
Agreed: (in theory) TDD is independent of language or style. However, I'm
wondering if (in practice) it creates a mode of thinking that pushes one
into an EAFP way of thinking?
Thi
> On 1 Nov 2019, at 05:40, DL Neil via Python-list
> wrote:
>
> Is the practice of TDD fundamentally, if not philosophically, somewhat
> contrary to Python's EAFP approach?
>
>
> TDD = Test-Driven Development
> EAFP = it's easier to ask forgiveness th
(in practice) it creates a mode of thinking that pushes one
> > > into an EAFP way of thinking?
> >
> > This is exactly the opposite of what you proposed in your first mail,
> > and I think it is closer to the truth:
> >
> > TDD does in my opinion encourage E
On 10/31/2019 10:40 PM, DL Neil via Python-list wrote:
Is the practice of TDD fundamentally, if not philosophically, somewhat contrary
to Python's EAFP approach?
Not at all. To use the maths example that's been going around:
def sqrt(number):
...
return some_value
pushes one
into an EAFP way of thinking?
This is exactly the opposite of what you proposed in your first mail,
and I think it is closer to the truth:
TDD does in my opinion encourage EAFP thinking.
As in "use the code and if it fails, add a test and fix it" versus "if
the code
On 2019-11-04 08:14:37 +1300, DL Neil via Python-list wrote:
> Perhaps 'Python pros' don't use TDD. Which in-and-of-itself, somewhat
> answers the question!
A certain Youtube channel has T-shirts for sale with this text:
DON'T TRY THIS AT HOME
WE ARE PROFESSIONALS
because we get paid
On 2019-11-01 18:40:06 +1300, DL Neil via Python-list wrote:
> In other words, before you do anything with some data, check that it is what
> you think it is. Whereas in Python we "try" by assuming everything is
> compos-mentis* and handle the "except" when things are not how we'd like.
>
> That a
tally, if not philosophically,
> > > somewhat contrary to Python's EAFP approach?
>
> > I’m not an expert on either TDD or Python, but as no one else has
> > responded, I’ll put in my 2 cents worth...
> > You are mixing paradigms. TDD is about testing code, rega
On 2/11/19 4:32 PM, boB Stepp wrote:
On Fri, Nov 1, 2019 at 12:42 AM DL Neil via Python-list
wrote:
Is the practice of TDD fundamentally, if not philosophically, somewhat
contrary to Python's EAFP approach?
[...]
In encouraging my mind to think about testing the code, I find m
On 3/11/19 6:30 AM, Bev In TX wrote:
On Nov 1, 2019, at 12:40 AM, DL Neil via Python-list
mailto:python-list@python.org>> wrote:
Is the practice of TDD fundamentally, if not philosophically, somewhat
contrary to Python's EAFP approach?
I’m not an expert on either TDD or Python
On Fri, Nov 1, 2019 at 12:42 AM DL Neil via Python-list
wrote:
>
> Is the practice of TDD fundamentally, if not philosophically, somewhat
> contrary to Python's EAFP approach?
>
[...]
>
> In encouraging my mind to think about testing the code, I find myself
> sea
Is the practice of TDD fundamentally, if not philosophically, somewhat
contrary to Python's EAFP approach?
TDD = Test-Driven Development
EAFP = it's easier to ask forgiveness than permission
* WebRefs as footnote
The practice of TDD* is that one writes test routines to prove a uni
L) versus “easier to ask forgiveness than
permission” (EAFP), and tends to prefer the latter.
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#eafp-vs-lbyl>
“It is easier to ask forgiveness than permission” is attributed to
computer programming legend Rear Admiral Grace Hop
On Tue, Feb 5, 2013 at 11:04 PM, Steven D'Aprano
wrote:
> py> isinstance(NAN, Number)
> True
Does that line of code count as nerd humour?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Pete Forman wrote:
> Steven D'Aprano writes:
>>> I want to check that a value is a number. [...]
>> I'm leaning towards an isinstance check
[...]
> BTW what if the value is Not-a-Number? ;-)
Nothing different, and hopefully exactly what the caller expects. As far as
Python is concerned, NANs are
Steven D'Aprano writes:
>> I want to check that a value is a number. [...]
> I'm leaning towards an isinstance check
Well that is the answer to your question, whether the value *is* a
number. EAFP can answer the question whether the value *behaves* like a
number, where the c
On 2/4/2013 6:16 PM, Steven D'Aprano wrote:
The eternal conflict between "Look Before You Leap" and "Easier to Ask for
Forgiveness than Permission" (LBYL vs EAFP) continues...
A somewhat different answer is that it depends on what you want the
function to do, as doc
On Tue, 05 Feb 2013 16:20:19 +1100, Chris Angelico wrote:
> On Tue, Feb 5, 2013 at 3:52 PM, Steven D'Aprano
> wrote:
>> There's also the principle that it is best to raise an exception as
>> early as possible. It's easier to track down errors at the point they
>> are introduced than long afterwar
I was
explaining EAFP as I see it, not advocating it for all circumstances.
Although since you bring it up, I find that the LBYL crowd tends to be
more prone to exception avoidance, e.g. returning None on a failure
rather than raising an exception, whereas the EAFP crowd seems more
likely to just
On Tue, Feb 5, 2013 at 3:52 PM, Steven D'Aprano
wrote:
> There's also the principle that it is best to raise an exception as early
> as possible. It's easier to track down errors at the point they are
> introduced than long afterwards.
Yes, definitely, especially (as was mentioned) if you're work
spects, it's not a number. You
can't multiply an iterator by 2, for instance.
> My library will not try to prevent the caller taking the average of (say)
> a dozen eggs and 10 miles. I'm not sure that it should try to prevent the
> caller from trying to take the average betwe
On Mon, 04 Feb 2013 16:46:11 -0700, Ian Kelly wrote:
> Presumably if the operation requires
> a number, then it will at some point perform some kind of numerical
> manipulation that will raise a TypeError if one is not passed. If the
> operation succeeds, then the object supported all the operatio
On Tue, 05 Feb 2013 10:38:41 +1100, Chris Angelico wrote:
> On Tue, Feb 5, 2013 at 10:16 AM, Steven D'Aprano
> wrote:
>> A third option is not to check x at all, and hope that it will blow up
>> at some arbitrary place in the middle of my code rather than silently
>> do the wrong thing. I don't l
On 4 February 2013 23:16, Steven D'Aprano
wrote:
>
> I want to check that a value is a number. Let's say I don't care what sort
> of number -- float, int, complex, Fraction, Decimal, something else -- just
> that it is a number. Should I:
>
> Look Before I Leap:
>
> from numbers import Number
On 02/04/2013 03:16 PM, Steven D'Aprano wrote:
The eternal conflict between "Look Before You Leap" and "Easier to Ask for
Forgiveness than Permission" (LBYL vs EAFP) continues...
I want to check that a value is a number. Let's say I don't care what so
On Tue, Feb 5, 2013 at 10:16 AM, Steven D'Aprano
wrote:
> from numbers import Number
> if isinstance(x, Number):
> ...
> else:
> raise TypeError
>
>
> or Ask Forgiveness:
>
> x + 0
> ...
>
>
> where in both cases the ellipsis ... is the code I actually care abou
On 02/04/2013 06:38 PM, Chris Angelico wrote:
On Tue, Feb 5, 2013 at 10:16 AM, Steven D'Aprano
wrote:
A third option is not to check x at all, and hope that it will blow up at
some arbitrary place in the middle of my code rather than silently do the
wrong thing. I don't like this idea because,
On Feb 4, 2013 4:24 PM, "Steven D'Aprano" <
steve+comp.lang.pyt...@pearwood.info> wrote:
>
> The eternal conflict between "Look Before You Leap" and "Easier to Ask for
> Forgiveness than Permission" (LBYL vs EAFP) continues...
>
> I want t
On Tue, Feb 5, 2013 at 10:16 AM, Steven D'Aprano
wrote:
> A third option is not to check x at all, and hope that it will blow up at
> some arbitrary place in the middle of my code rather than silently do the
> wrong thing. I don't like this idea because, even if it fails, it is better
> to fail ea
The eternal conflict between "Look Before You Leap" and "Easier to Ask for
Forgiveness than Permission" (LBYL vs EAFP) continues...
I want to check that a value is a number. Let's say I don't care what sort
of number -- float, int, complex, Fraction, Decimal, somet
Malte Helmert writes:
> Arnaud Delobelle wrote:
>
>> This means that EAFP made me hide a typo which would have been obviously
>> detected had I LBYLed, i.e. instead of
>>
>> try:
>> return val.latex()
>> except AttributeError:
>>
"%s=%s" % (latex(k), latex(v))
for k, v in sorted(val.iteritems())
)
else:
return str(val)
It's EAFP and I have used this for a while with no problem. Recently I
added a new class for 'n choose r' objects, as fo
Ben Finney wrote:
> def latex(val):
> def make_result_in_the_absence_of_a_latex_method():
> result = transmogrify(val)
> return result
>
> try:
> typeset_func = val.latex
> except AttributeError:
> typeset_func = make_result_in_the_absence_of_a_latex_met
Arnaud Delobelle wrote:
> This means that EAFP made me hide a typo which would have been obviously
> detected had I LBYLed, i.e. instead of
>
> try:
> return val.latex()
> except AttributeError:
> ...
>
> do
>
> if hasattr(val, &#x
Arnaud Delobelle writes:
> As I want to be able to typeset some builtin types as well, I have a
> generic function, latex(), as follows:
>
> def latex(val):
> try:
> return val.latex()
> except AttributeError:
[…]
> It's EAFP and I have used thi
ex(k), latex(v))
for k, v in sorted(val.iteritems())
)
else:
return str(val)
It's EAFP and I have used this for a while with no problem. Recently I
added a new class for 'n choose r' objects, as follows:
class Choose(Expression
44 matches
Mail list logo
