Re: PyWart: The problem with "print"

[Joshua Landau]

On 4 June 2013 14:35, Mark Lawrence  wrote:
> On 04/06/2013 14:29, rusi wrote:
>> The Clash of the Titans
>>
>> Lé jmf chârgeth with mightƴ might
>> And le Mond underneath trembleth
>> Now RR mounts his sturdy steed
>> And the windmill yonder turneth
>>
>
> +1 funniest poem of the week :)

Week? Do we do this every Tuesday?

I vote all-time best post for python-list@python.org.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Janssen]

On 6/6/13, alex23  wrote:
> On Jun 7, 11:44 am, Mark Janssen  wrote:
>> > Bulshytt. If you have no idea what polymorphism is, you shouldn't even
>> > be participating in this conversation.
>>
>> I am aware of what it means, but Python doesn't really have it
>
> You really need to stop commenting when you clearly have no
> understanding of what you're talking about.

"Clearly", okay.  You've added a wee bit of constructive argument *if*
you're considered reputable to the rest of the list; however,
"polymorophism", should really only be considered "true" when
specifically in a "functional enclosure".  C++ has this, through it's
type system, more strictly when there is no references to variables
outside the function scope.  Python does not.

But this all relates to theoretical ObjectArchitecture and
ModelsOfComputation that aren't well-understood outside a few
specialized folks.  Good luck trying to work through the chaff, if you
don't want to know the difference.

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[rusi]

On Jun 7, 8:24 am, rusi  wrote:
> On Jun 7, 8:14 am, Mark Janssen  wrote:
>
>
>
>
>
>
>
>
>
> > >> I am aware of what it means, but Python doesn't really have it (although
> > >> it may evolve to it with annotations).
>
> > > No polymorphism huh?
>
> > > py> len([1, 2, 3])  # len works on lists
> > > 3
> > > py> len((1, 2))  # and on tuples
> > > 2
> > > py> len({})  # and on dicts
> > > 0
> > > py> len('I pity the fool')  # and on strings
> > > 15
> > > py> len(b'\x23')  # and on bytes
> > > 1
> > > py> len(set(range(2)))  # and on sets
> > > 2
> > > py> len(frozenset(range(4)))  # and on frozensets
> > > 4
> > > py> len(range(1000))  # and on range objects
> > > 1000
>
> > Okay, wow, it looks like we need to define some new computer science
> > terms here.
>
> Fairly definitive terms have existed since 
> 1985:http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
>
>
>
> > You are making an "outside view of a function" (until a better term is
> > found).  So that give you one possible view of polymorphism.  However,
> > *within* a class that I would write, you would not see polymorphism
> > like you have in C++,  where it is within the *function closure*
> > itself.   Instead you would see many if/then combinations to define
> > the behavior given several input types.  I would call this simulated
> > polymorphism.
>
> Cardelli and Wegner cited above call this ad-hoc polymorphism.
> What you are calling polymorphism, they call universal polymorphism.
>
> See sect 1.3 for a summary diagram

I should have added that python has the universal polymorphism that
you want:

$ python
Python 2.7.5 (default, May 20 2013, 13:49:25)
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> len([1,2])
2
>>> len([[1,2]])
1
>>> len([[[1,2]],[[3]],[[4,5]]])
3
>>>

The main thing to note about universal -> parametric polymorphism is
that one definition works for an infinite set of types, without any
extra code(ing)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Janssen]

> Fairly definitive terms have existed since 1985:
> http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
>>
>> You are making an "outside view of a function" (until a better term is
>> found).  So that give you one possible view of polymorphism.  However,
>> *within* a class that I would write, you would not see polymorphism
>> like you have in C++,  where it is within the *function closure*
>> itself.   Instead you would see many if/then combinations to define
>> the behavior given several input types.  I would call this simulated
>> polymorphism.
>
> Cardelli and Wegner cited above call this ad-hoc polymorphism.
> What you are calling polymorphism, they call universal polymorphism.

Okay, THANK YOU for the reference.  The main thing to note is that
there is a difference.  Those terms sound good enough.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[rusi]

On Jun 7, 8:14 am, Mark Janssen  wrote:
> >> I am aware of what it means, but Python doesn't really have it (although
> >> it may evolve to it with annotations).
>
> > No polymorphism huh?
>
> > py> len([1, 2, 3])  # len works on lists
> > 3
> > py> len((1, 2))  # and on tuples
> > 2
> > py> len({})  # and on dicts
> > 0
> > py> len('I pity the fool')  # and on strings
> > 15
> > py> len(b'\x23')  # and on bytes
> > 1
> > py> len(set(range(2)))  # and on sets
> > 2
> > py> len(frozenset(range(4)))  # and on frozensets
> > 4
> > py> len(range(1000))  # and on range objects
> > 1000
>
> Okay, wow, it looks like we need to define some new computer science
> terms here.

Fairly definitive terms have existed since 1985:
http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf

>
> You are making an "outside view of a function" (until a better term is
> found).  So that give you one possible view of polymorphism.  However,
> *within* a class that I would write, you would not see polymorphism
> like you have in C++,  where it is within the *function closure*
> itself.   Instead you would see many if/then combinations to define
> the behavior given several input types.  I would call this simulated
> polymorphism.

Cardelli and Wegner cited above call this ad-hoc polymorphism.
What you are calling polymorphism, they call universal polymorphism.

See sect 1.3 for a summary diagram

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Janssen]

>> I am aware of what it means, but Python doesn't really have it (although
>> it may evolve to it with annotations).
>
> No polymorphism huh?
>
>
> py> len([1, 2, 3])  # len works on lists
> 3
> py> len((1, 2))  # and on tuples
> 2
> py> len({})  # and on dicts
> 0
> py> len('I pity the fool')  # and on strings
> 15
> py> len(b'\x23')  # and on bytes
> 1
> py> len(set(range(2)))  # and on sets
> 2
> py> len(frozenset(range(4)))  # and on frozensets
> 4
> py> len(range(1000))  # and on range objects
> 1000

Okay, wow, it looks like we need to define some new computer science
terms here.

You are making an "outside view of a function" (until a better term is
found).  So that give you one possible view of polymorphism.  However,
*within* a class that I would write, you would not see polymorphism
like you have in C++,  where it is within the *function closure*
itself.   Instead you would see many if/then combinations to define
the behavior given several input types.  I would call this simulated
polymorphism.

But don't quote me on this because I have to review my 20 years of CS
and see if it matches what the field says -- if the field has settled
on a definition.  If not, I go with the C++ definition, and there it
is very different than python.

But then, you weren't going to quote me anyway, right?

-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[rusi]

On Jun 6, 11:44 pm, Devin Jeanpierre  wrote:
>
> > Unfortunately* the halting problem stands.  When generalized to Rice
> > theorem it says that only trivial properties of programs are
> > algorithmically decidable:
> >http://mathworld.wolfram.com/RicesTheorem.html
>
> > And so the semantic correctness of a program -- a non-trivial property
> > -- is not decidable.
>
> Just because a problem is NP-complete or undecidable, doesn't mean
> there aren't techniques that give the benefits you want (decidability,
> poly-time) for a related problem. Programmers often only or mostly
> care about that related problem, so it isn't the end of the line just
> when we hit this stumbling block.
>
> As far as undecidability goes, one possibility is to accept a subset
> of desired programs. For example, restrict the language to not be
> turing complete, and there is no problem.
>
> Another resolution to the problem of undecidability is to accept a
> _superset_ of the collection you want. This permits some programs
> without the property we want, but it's often acceptable anyway.
>
> A third approach is to attach proofs, and only accept a program with
> an attached and correct proof of said property. This is a huge
> concept, vital to understanding complexity theory. It may be
> undecidable to find a proof, but once it is found, it is decidable to
> check the proof against the program.
>
> Haskell takes something akin to the second approach, and allows errors
> to exist which would require "too much work" to eliminate at compile
> time. (Although the type system is a literal case of the first
> resolution). Python, by contrast, often values flexibility over
> correctness, regardless of how easy it might be to check an error at
> compile time. The two languages have different philosophies, and that
> is something to respect. The reduction to Rice's theorem does not
> respect the trade-off that Haskell is making, it ignores it. It may be
> a "pipe dream" to get everything ever, but that's not to say that the
> entire approach is invalid and that we should ignore how Haskell
> informs the PL discourse.
>

Nice 3-point summary. Could serve as a good antidote to some of the
cargo-culting that goes on under Haskell.
To make it very clear: In any science, when there are few people they
probably understand the science. When the numbers explode, cargo-cult
science happens.  This does not change the fact that a few do still
understand.  Haskell is not exception.  See below

>
> On Thu, Jun 6, 2013 at 1:27 PM, rusi  wrote:
> > Yes, all programming communities have blind-spots.  The Haskell
> > community's is that Haskell is safe and safe means that errors are
> > caught at compile-time.
>
> I don't think Haskell people believe this with the thoroughness you
> describe. There are certainly haskell programmers that are aware of
> basic theory of computation.

Of course!  Here's cmccann from Haskell weekly news of May 31: [On
reimplementing cryptography in pure Haskell] writing in Haskell lets
you use type safety to ensure that all the security holes you create
are subtle instead of obvious.

Which is showing as parody exactly what I am talking of: All errors
cannot be removed algorithmically/mechanically.

And here's Bob Harper -- father of SML -- pointing out well-known and
less well-known safety problems with Haskell:
http://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-unsafe/


--
> Super OT divergence because I am a loser nerd:

Uh? Not sure I understand…
OT: OK: How can you do programming if you dont understand it?
I guess in a world where majority do it without understanding, someone
who understands (more) will be called 'nerd'?

> For some reason both the Python and Haskell communities feel the other
> is foolish and ignorant, dismissing their opinions as unimportant
> babbling. I wish that would stop.

Dunno whether you are addressing me specifically or python folks
generally.
If me, please remember my post ended with
> If a programmer comes to python from Haskell, he will end up being a better 
> programmer than one
> coming from C or Java or…

If addressed generally, I heartily agree. My proposed course:
https://moocfellowship.org/submissions/the-dance-of-functional-programming-languaging-with-haskell-and-python
is in this direction. That is it attempts to create a new generation
of programmers who will be able to use Haskell's theory-power to pack
an extra punch into batteries-included python.

More details:  
http://blog.languager.org/2013/05/dance-of-functional-programming.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Steven D'Aprano]

On Thu, 06 Jun 2013 18:44:49 -0700, Mark Janssen wrote:

>>> Python has seduced us all into lazy typing.  That's what it is.
>>
>> Bulshytt. If you have no idea what polymorphism is, you shouldn't even
>> be participating in this conversation.
> 
> I am aware of what it means, but Python doesn't really have it (although
> it may evolve to it with annotations).

No polymorphism huh?


py> len([1, 2, 3])  # len works on lists
3
py> len((1, 2))  # and on tuples
2
py> len({})  # and on dicts
0
py> len('I pity the fool')  # and on strings
15
py> len(b'\x23')  # and on bytes
1
py> len(set(range(2)))  # and on sets
2
py> len(frozenset(range(4)))  # and on frozensets
4
py> len(range(1000))  # and on range objects
1000


Looks pretty polymorphic to me.




-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[alex23]

On Jun 7, 11:44 am, Mark Janssen  wrote:
> > Bulshytt. If you have no idea what polymorphism is, you shouldn't even
> > be participating in this conversation.
>
> I am aware of what it means, but Python doesn't really have it

You really need to stop commenting when you clearly have no
understanding of what you're talking about.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Janssen]

>> Python has seduced us all into lazy typing.  That's what it is.
>
> Bulshytt. If you have no idea what polymorphism is, you shouldn't even
> be participating in this conversation.

I am aware of what it means, but Python doesn't really have it
(although it may evolve to it with annotations).  But then these
debates were over a decade ago.

MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Dan Stromberg]

On Thu, Jun 6, 2013 at 9:49 AM, Rick Johnson
wrote:

> Congrats: Again you join the ranks of most children who make excuses for
> their foolish actions along the lines of:
>
>  "Hey, they did it first!"
>
> Well, the lemmings get what they deserve i suppose.
>

Lemmings don't really jump off cliffs.  The Disney film documenting it was
staged by a film crew who'd -heard- Lemmings did, and forced the little
guys over a cliff in the name of saving time.

http://en.wikipedia.org/wiki/Lemming
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[alex23]

On Jun 7, 2:39 am, Devin Jeanpierre  wrote:
> Languages do not exist in a vacuum.

They do if all you use them for is academic point scoring over
practical purposes.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[alex23]

On Jun 7, 3:59 am, Mark Janssen  wrote:
> Okay, I'm going straighten out you foo(l)s once and for all.

Gosh, really?! THANKS.

> Python has seduced us all into lazy typing.  That's what it is.

Bulshytt. If you have no idea what polymorphism is, you shouldn't even
be participating in this conversation.

> The fact is, that none of us is close enough to God

More bulshytt.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Devin Jeanpierre]

Super OT divergence because I am a loser nerd:

On Thu, Jun 6, 2013 at 1:27 PM, rusi  wrote:
> Yes, all programming communities have blind-spots.  The Haskell
> community's is that Haskell is safe and safe means that errors are
> caught at compile-time.

I don't think Haskell people believe this with the thoroughness you
describe. There are certainly haskell programmers that are aware of
basic theory of computation.

> Unfortunately* the halting problem stands.  When generalized to Rice
> theorem it says that only trivial properties of programs are
> algorithmically decidable:
> http://mathworld.wolfram.com/RicesTheorem.html
>
> And so the semantic correctness of a program -- a non-trivial property
> -- is not decidable.

Just because a problem is NP-complete or undecidable, doesn't mean
there aren't techniques that give the benefits you want (decidability,
poly-time) for a related problem. Programmers often only or mostly
care about that related problem, so it isn't the end of the line just
when we hit this stumbling block.

As far as undecidability goes, one possibility is to accept a subset
of desired programs. For example, restrict the language to not be
turing complete, and there is no problem.

Another resolution to the problem of undecidability is to accept a
_superset_ of the collection you want. This permits some programs
without the property we want, but it's often acceptable anyway.

A third approach is to attach proofs, and only accept a program with
an attached and correct proof of said property. This is a huge
concept, vital to understanding complexity theory. It may be
undecidable to find a proof, but once it is found, it is decidable to
check the proof against the program.

Haskell takes something akin to the second approach, and allows errors
to exist which would require "too much work" to eliminate at compile
time. (Although the type system is a literal case of the first
resolution). Python, by contrast, often values flexibility over
correctness, regardless of how easy it might be to check an error at
compile time. The two languages have different philosophies, and that
is something to respect. The reduction to Rice's theorem does not
respect the trade-off that Haskell is making, it ignores it. It may be
a "pipe dream" to get everything ever, but that's not to say that the
entire approach is invalid and that we should ignore how Haskell
informs the PL discourse.

For some reason both the Python and Haskell communities feel the other
is foolish and ignorant, dismissing their opinions as unimportant
babbling. I wish that would stop.

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Rick Johnson]

On Thursday, June 6, 2013 1:03:24 PM UTC-5, Rick Johnson wrote:
 
> The second covers type checking objects that enter into new
> namespaces. That would cover all functions/methods arguments
> (at a minimum). 

Yeah, before anyone starts complaining about this, i meant to say "scope". Now 
you can focus on the *real* argument instead of spending all your time pointing 
out minutiae.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Russ P.]

On Thursday, June 6, 2013 2:29:02 AM UTC-7, Steven D'Aprano wrote:
> On Thu, 06 Jun 2013 12:29:44 +1000, Chris Angelico wrote:
> 
> 
> 
> > On Thu, Jun 6, 2013 at 11:56 AM, Steven D'Aprano
> 
> >  wrote:
> 
> >> On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote:
> 
> >>> As for Python, my experience with it is that, as your application
> 
> >>> grows, you start getting confused about what the argument types are or
> 
> >>> are supposed to be.
> 
> >>
> 
> >> Whereas people never get confused about the arguments in static typed
> 
> >> languages?
> 
> >>
> 
> >> The only difference is whether the compiler tells you that you've
> 
> >> passed the wrong type, or your unit test tells you that you've passed
> 
> >> the wrong type. What, you don't have unit tests? Then how do you know
> 
> >> that the code does the right thing when passed data of the right type?
> 
> >> Adding an extra couple of unit tests is not that big a burden.
> 
> > 
> 
> > The valid type(s) for an argument can be divided into two categories:
> 
> > Those the compiler can check for, and those the compiler can't check
> 
> > for. Some languages have more in the first category than others, but
> 
> > what compiler can prove that a string is an
> 
> > HTML-special-characters-escaped string? In a very few languages, the
> 
> > compiler can insist that an integer be between 7 and 30, but there'll
> 
> > always be some things you can't demonstrate with a function signature.
> 
> > 
> 
> > That said, though, I do like being able to make at least *some*
> 
> > declaration there. It helps catch certain types of error.
> 
> 
> 
> *shrug*
> 
> 
> 
> I don't terribly miss type declarations. Function argument declarations 
> 
> are a bit simpler in Pascal, compared to Python:
> 
> 
> 
> 
> 
> Function Add(A, B : Integer) : Integer; 
> 
> Begin
> 
>  Add := A + B;
> 
> End;
> 
> 
> 
> 
> 
> versus
> 
> 
> 
> 
> 
> def add(a, b):
> 
> if not (isinstance(a, int) and isinstance(b, int)):
> 
> raise TypeError
> 
> return a + b
> 

Scala also has isInstanceOf[Type] which allows you to do this sort of thing, 
but of course it would be considered terrible style in Scala.

> 
> 
> 
> but not that much simpler. And while Python can trivially support 
> 
> multiple types, Pascal cannot. (Some other static typed languages may.)
> 
> 
> 
> Whatever benefit there is in declaring the type of a function is lost due 
> 
> to the inability to duck-type or program to an interface. There's no type 
> 
> that says "any object with a 'next' method", for example. And having to 
> 
> declare local variables is a PITA with little benefit.
> 
> 
> 
> Give me a language with type inference, and a nice, easy way to keep duck-
> 
> typing, and I'll reconsider. But until then, I don't believe the benefit 
> 
> of static types comes even close to paying for the extra effort.


Scala has type inference. For example, you can write

val x = 1

and the compiler figures out that x is an integer. Scala also has something 
called structural typing, which I think is more or less equivalent to "duck 
typing," although I don't think it is used very often.

Are you ready to try Scala yet? 8-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Rick Johnson]

On Wednesday, June 5, 2013 8:37:20 PM UTC-5, Steven D'Aprano wrote:
> On Wed, 05 Jun 2013 09:15:01 -0700, Russ P. wrote:
> > On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
> >> On 05/06/2013 07:11, Russ P. wrote:

> What prevents bugs is the skill of the people writing the code, not the 
> compiler. Compile-time static type checking is merely a tool, which has 
> costs and benefits. It is ludicrous to think that any one single tool, or 
> the lack of that tool, will make all the difference between working code 
> and non-working code.

Yes, just as ludicrous as thinking that dynamic languages have abolished the 
evil practice of "type checking". 

> Static type-checking is no better, or worse, for "critical code" than 
> dynamic type-checking. One language chooses to deal with some errors at 
> compile-time, others deal with them at run-time. 

Wow, talk about ignoring the elephant in the room! I don't feel i need static 
typed languages for EVERY problem, however, i'm not foolish enough to believe 
that "compile time type checking" and "run-time type checking" are even 
comparable. Oversimplification?

> Either way, the 
> programmer has to deal with them in some way.
> A static type system forces you to deal with a limited subset of errors, 
> "type errors", in one way only: by removing any execution paths in the 
> software which would assign data of type X to a variable of type Y. For 
> reasons of machine efficiency, that is often a good was to deal with such 
> errors. But a dynamic type system makes different trade-offs.
> And of course, type errors are such a vanishingly small subset of all the 
> possible errors that might be made that, frankly, the difference in code 
> quality between those with static typing and those without is essentially 
> indistinguishable. There's no evidence that code written in static typed 
> languages is less buggy than code written in dynamic languages.

WOW! Your skill with the implicit Ad hominem is approaching guru status.

First you cleverly convert the base argument of this ongoing discussion from: 
"implicit conversion to boolean is bad", into the hot button topic of: "static 
vs dynamic typing". 

In this manner you can ratchet up the emotion of your supporters by employing 
the same political "slight of hand" used by countless political hacks: "Liberal 
vs Republican" ring a bell? When there is only two choices, the sheeple can be 
easily manipulated by the football game. Especially when the opposing sides 
have the same end-goal in mind. It's all a game of diversions you idiots!

Then you go and make a blanket statement that "appears" to weigh the 
differences of the two styles fairly, when in fact, what you've done is to 
falsely invalidate the opposition's entire argument based on a complete 
overstatement (not to mention that you stopped short of explaining the "trade 
offs" in detail):

> And of course, type errors are such a vanishingly
> small subset of all the possible errors that might be
> made that, frankly, the difference in code quality
> between those with static typing and those without is
> essentially indistinguishable.

Nice!

Well, then. You've slayed the enemy. If type errors are as rare as you claim, 
then by golly these crazy people who use static languages are really just 
fools. I mean, how could they not be? If they were as intelligent as YOU then 
they would see the truth!

Your attempts at sleight of hand are rather amusing. The whole point of this 
"implicit conversion to Boolean" discussion hinges around the fact that dynamic 
languages are okay for small to medium problems ( or for prototyping larger 
problems). But they cannot be depended on for mission critical code. And 
mission critical does not only encompass manned flights to mars, it could be 
any code that places your reputation on the line. 

I don't want Python to be a static typed language. Neither do i believe that 
duck typing is wrong for Python. HOWEVER, what i DO believe is that dynamic 
languages can be unreliable if we do not:

 1. Choose to be "explicit enough"

I've explained this in detail Ad-nauseam.

  2. Fail to type check where type checking is due. 
 
The second covers type checking objects that enter into new namespaces. That 
would cover all functions/methods arguments (at a minimum). 

We don't need to type check EVERY single object (but of course the programmer 
could IF he wanted to). If i declare a variable[1] that points to a list in a 
block of code, then i reference that variable[1] in the same block of code, i 
see no reason to type check that variable[1] first. That is overkill and that 
is why people are turned off by static languages.

However, if i declare the same variable[1] and then pass that variable[1] into 
a function, the function should do a type check on all the arguments to 
guarantee that these arguments are in fact what they should be. This is how you 
strike a balance between explicit and 

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Janssen]

> Whatever benefit there is in declaring the type of a function is lost due
> to the inability to duck-type or program to an interface. There's no type
> that says "any object with a 'next' method", for example. And having to
> declare local variables is a PITA with little benefit.
>
> Give me a language with type inference, and a nice, easy way to keep duck-
> typing, and I'll reconsider. But until then, I don't believe the benefit
> of static types comes even close to paying for the extra effort.

Okay, I'm going straighten out you foo(l)s once and for all.

Python has seduced us all into lazy typing.  That's what it is.
Manual type checking is obviously inferior to compiler type-checking.
 This is what I was trying to tell you all with the post of re-vamping
the Object model.

Python, and I along with it, went towards this idea of a grand god
Object that is the father of everything, but it turned out to be the
wrong direction.  Refer to my post on OOPv2.

The fact is, that none of us is close enough to God and the
programming art isn't evolved enough to try to accomplish some grand
generic object at the top of the ObjectModel.  It just isn't.  We were
better off closer to the machine.  Automatic conversion from int to
long was good enough.
-- 
MarkJ
Tacoma, Washington

P.S. See also PythonThreeThousand on wikiwikiweb

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Grant Edwards]

On 2013-06-06, Chris Angelico  wrote:

> Would you say that doubling the testing period is a good thing or a
> bad thing?

It could be a neutral thing (ignoring the costs involved).

I once read read an article claiming that as you test (and fix) any
large, complex piece of software, you asymptotically approach a
certain fixed "minimum number of bugs" that's determined by the
system's overall architecture, design and implentation.  Once you get
sufficiently close to that minimum, additional testing doesn't reduce
the number/severity of bugs -- it just "moves them around" by creating
additional bugs at the same rate you are eliminating old ones.  When
you get to that point, the only way to significantly improve the
situation is to toss the whole thing out and start over with a better
system architecture and/or development model.

After having maintined a few largish pieces of software for well over
a decade, I'm fairly convinced that's true -- especially if you also
consider post-deployment maintenance (since at that point you're
usually also trying to add features at the same time you're fixing
bugs).

-- 
Grant Edwards   grant.b.edwardsYow! I just went below the
  at   poverty line!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[rusi]

On Jun 6, 9:08 pm, Robert Kern  wrote:
> On 2013-06-06 16:41, Chris Angelico wrote:
>
> > Anyway, regardless of your language, there's always some criteria that
> > can't be coded. Suppose the valid input for a function were "integers
> > whose square roots are integers but whose cube roots are not". You
> > won't easily get compile-time checking of that.
>
> Say that on a Haskell list, and they'll take it as a challenge. :-)

Yes, all programming communities have blind-spots.  The Haskell
community's is that Haskell is safe and safe means that errors are
caught at compile-time.

Unfortunately* the halting problem stands.  When generalized to Rice
theorem it says that only trivial properties of programs are
algorithmically decidable:
http://mathworld.wolfram.com/RicesTheorem.html

And so the semantic correctness of a program -- a non-trivial property
-- is not decidable.

In short the Haskell dream is a pipe-dream**.

Discussed in more detail here: 
http://blog.languager.org/2012/08/functional-programming-philosophical.html.

Nevertheless I need to say: If a programmers comes to python from
Haskell, he will end up being a better programmer than one coming from
C or Java or…


* actually fortunately considering that for most of us programming is
our job :-)

** Haskellers would point out that there is agda which grows out of
Haskell and in agda one can encode arbitrary properties of types.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Fri, Jun 7, 2013 at 2:49 AM, Rick Johnson
 wrote:
> On Wednesday, June 5, 2013 2:15:57 AM UTC-5, Chris Angelico wrote:
>> [...]
>> I cannot name a single modern programming language that does NOT have
>> some kind of implicit boolification.
>
> Congrats: Again you join the ranks of most children who make excuses for 
> their foolish actions along the lines of:
>
>  "Hey, they did it first!"
>
> Well, the lemmings get what they deserve i suppose.

You say that like it's a bad thing.
http://www.catb.org/jargon/html/E/ELIZA-effect.html

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Rick Johnson]

On Wednesday, June 5, 2013 2:15:57 AM UTC-5, Chris Angelico wrote:
> [...]
> I cannot name a single modern programming language that does NOT have
> some kind of implicit boolification. 

Congrats: Again you join the ranks of most children who make excuses for their 
foolish actions along the lines of:

 "Hey, they did it first!"

Well, the lemmings get what they deserve i suppose. 


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Devin Jeanpierre]

On Thu, Jun 6, 2013 at 12:24 PM, Rick Johnson
 wrote:
> In Python, if you fail to use the return statement, then Python will return 
> None, NOT some some value that just happens to be the last line executed in 
> the function -- Ruby breaks the law of least astonishment.

Ruby comes from a tradition where this behavior is not astonishing.
Languages do not exist in a vacuum.

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Rick Johnson]

On Wednesday, June 5, 2013 6:18:13 PM UTC-5, Michael Torrie wrote:
> On 06/05/2013 12:11 AM, Russ P. wrote:
> > But then, what would you expect of a language that allows you to
> > write
> > x = 1 
> > x = "Hello"
> > It's all loosey goosey -- which is fine for many applications but
> > certainly not for critical ones.
> This comment shows me that you don't understand the difference between
> names, objects, and variables.  May sound like a minor quibble, but
> there're actually major differences between binding names to objects
> (which is what python does) and variables (which is what languages like
> C have).  It's very clear Rick does not have an understanding of this
> either.

Just because someone does not "prefer" this or that aspect of Python, does not 
mean they don't understand it. I understand "implicit conversion to Boolean" 
just fine, however, i don't like it. Actually, i hate it! I think it's foolish. 
It was invented by people who rather save a few keystrokes at the cost writing 
cryptic code. There are many good reasons for saving keystrokes, implicit 
conversion to Boolean is NOT one of them. 

I make the same argument for "return". Some languages allow implicit return 
values from functions/methods. When writing a function with Ruby, the return 
statement is optional:

## START RUBY CODE ##

def foo:
"implicit return"
end

rb> puts foo
"implicit return"

## END RUBY CODE ##

This is one area where Python shines! 

In Python, if you fail to use the return statement, then Python will return 
None, NOT some some value that just happens to be the last line executed in the 
function -- Ruby breaks the law of least astonishment.

The point is we must balance our selfish need to save keystrokes against the 
need of a reader to QUICKLY understand what he is reading. Python's "explicit 
return statement" satisfies both requirements, whereas, the optional return 
value of Ruby does not. We don't want to overly implicit, or overly explicit 
(as in the nightmare of "public static void foo", which is overkill (at least 
for a language as high level as Python)). 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Robert Kern]

On 2013-06-06 16:41, Chris Angelico wrote:


Anyway, regardless of your language, there's always some criteria that
can't be coded. Suppose the valid input for a function were "integers
whose square roots are integers but whose cube roots are not". You
won't easily get compile-time checking of that.


Say that on a Haskell list, and they'll take it as a challenge. :-)

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Fri, Jun 7, 2013 at 1:49 AM, Rick Johnson
 wrote:
> On Wednesday, June 5, 2013 11:59:07 AM UTC-5, Chris Angelico wrote:
>
>> Frankly, I don't think the language much matters. It's all
>> down to the skill of the programmers and testers. Ada
>> wasn't the source of the problem unless Ada has a bug in
>> it... which is going to be true of pretty much any
>> language. Maybe Python would be a better choice, maybe
>> not; but let me tell you this, if the choice of language
>> means the difference between testable in three months and
>> testable code in three years, I'm going for the former.
>
> Yes EVEN IF life or property hangs in the balance, the only important 
> decision is how much work YOU will be required to do -- Chris, why i am not 
> amazed by this bombastic display of selfishness?

I would like to say that you're not amazed because you're intelligent
enough to understand what I was saying, but I'm not sure it'd be true.

Let me spell it out for you.

* Deadlines are real things. They make a very audible "whooosh" as they go past.
* If the time frame for developing this is five years, then in five
years, the code must either be shipped or scrapped.
* Taking three years to get to a testable codebase allows two years to test.
* Taking three months to get testable allows over four years to test.

Would you say that doubling the testing period is a good thing or a bad thing?

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Rick Johnson]

On Wednesday, June 5, 2013 11:59:07 AM UTC-5, Chris Angelico wrote:

> Frankly, I don't think the language much matters. It's all
> down to the skill of the programmers and testers. Ada
> wasn't the source of the problem unless Ada has a bug in
> it... which is going to be true of pretty much any
> language. Maybe Python would be a better choice, maybe
> not; but let me tell you this, if the choice of language
> means the difference between testable in three months and
> testable code in three years, I'm going for the former.

Yes EVEN IF life or property hangs in the balance, the only important decision 
is how much work YOU will be required to do -- Chris, why i am not amazed by 
this bombastic display of selfishness?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Fri, Jun 7, 2013 at 1:35 AM, Robert Kern  wrote:
> On 2013-06-06 10:45, Chris Angelico wrote:
>
>> For the "accept any object that has a next() method" sorts of rules, I
>> don't know of any really viable system that does that usefully. The
>> concept of implementing interfaces in Java comes close, but the class
>> author has to declare that it's implementing some named interface. In
>> theory there could be something that deduces the validity from the
>> given structure, but I'm not aware of any language that does this. But
>> it would let you do stuff like this (prototyped in Python):
>
>
> As Serhiy notes, Go does this, almost exactly as you wrote it (modulo
> syntax).
>
> http://golang.org/doc/effective_go.html#interfaces_and_types

Thanks (and thanks for actually providing a link). Many years ago I
came to the conclusion that anything I could conceive in language
design has already been done somewhere :)

Anyway, regardless of your language, there's always some criteria that
can't be coded. Suppose the valid input for a function were "integers
whose square roots are integers but whose cube roots are not". You
won't easily get compile-time checking of that.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Fri, Jun 7, 2013 at 1:36 AM, rusi  wrote:
> On Jun 6, 8:26 pm, Chris Angelico  wrote:
>> On Fri, Jun 7, 2013 at 12:09 AM, rusi  wrote:
>> > When we switched from to python (via Scheme and a haskell-
>> > predecessor), I dont remember ever getting a segmentation fault.
>>
>> Oh, it's easy to segfault Python.
>>
>> import sys
>> sys.setrecursionlimit(9)
>> def foo(): foo()
>> foo()
>>
>> :)
>>
>> ChrisA
>
> And so you are hereby anointed into the august company of RR!!

Eh? No, I'm just adept at breaking stuff... I could probably segfault
a 100Mbit switch if I tried (or just got careless).

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[rusi]

On Jun 6, 8:26 pm, Chris Angelico  wrote:
> On Fri, Jun 7, 2013 at 12:09 AM, rusi  wrote:
> > When we switched from to python (via Scheme and a haskell-
> > predecessor), I dont remember ever getting a segmentation fault.
>
> Oh, it's easy to segfault Python.
>
> import sys
> sys.setrecursionlimit(9)
> def foo(): foo()
> foo()
>
> :)
>
> ChrisA

And so you are hereby anointed into the august company of RR!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Robert Kern]

On 2013-06-06 10:45, Chris Angelico wrote:


For the "accept any object that has a next() method" sorts of rules, I
don't know of any really viable system that does that usefully. The
concept of implementing interfaces in Java comes close, but the class
author has to declare that it's implementing some named interface. In
theory there could be something that deduces the validity from the
given structure, but I'm not aware of any language that does this. But
it would let you do stuff like this (prototyped in Python):

class Integers:
 def __init__(self): self.value=0
 def next(self):
 self.value+=1
 return self.value

interface Iterable:
 next(self)

def grab_three_values(Iterable iter):
 return iter.next(),iter.next(),iter.next()

With a language that checks these sorts of things at compile time,
it's not a big deal to test. With something fully dynamic like Python,
it's probably not worth the effort. But maybe checks like this could
be useful to something like Coverity.


As Serhiy notes, Go does this, almost exactly as you wrote it (modulo syntax).

http://golang.org/doc/effective_go.html#interfaces_and_types

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Fri, Jun 7, 2013 at 12:09 AM, rusi  wrote:
> When we switched from to python (via Scheme and a haskell-
> predecessor), I dont remember ever getting a segmentation fault.


Oh, it's easy to segfault Python.

import sys
sys.setrecursionlimit(9)
def foo(): foo()
foo()

:)

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[rusi]

On Jun 6, 6:45 am, Chris Angelico  wrote:
> On Thu, Jun 6, 2013 at 11:37 AM, Steven D'Aprano
>
>  wrote:
> > What prevents bugs is the skill of the people writing the code, not the
> > compiler.
>
> +1 QOTW.

In many Indian languages there is a saying: A poor dancer blames the
crooked floor. [Yeah… sounds tame in English]  -- which is probably
what Steven is saying.

However in defence of the crooked floor… 

When I taught C at the university in the early 90s[1], every third/
fourth compile+run of the kids would result in 'segmentation fault' if
they were lucky enough to be on unix, and OS crashes if they were on
DOS.
At first I would rail at the kids for not doing due diligence.  Over
time I came to the conclusion that if a system is designed in such a
way that everyone is wrong, then its the system that is wrong and not
everyone.

When we switched from to python (via Scheme and a haskell-
predecessor), I dont remember ever getting a segmentation fault.

[Well once RR gave some Wx code that I tried and python core dumped.
Whether this speaks for RR or Wx or a dangerous combo...]

So yes, elegant programming languages are not proof against inelegant
programmers.
Nevertheless, programming languages can be made in a way that makes
certain class of errors harder/easier to make.

Joel Spolsky moans that:
Java is not, generally, a hard enough programming language that it can
be used to discriminate between great programmers and mediocre
programmers.
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

And Paul Graham is even more provocative:
Java programmers are not as smart as python programmers
http://www.paulgraham.com/gh.html

[1] Prompted a paper in the 90s, with some modernizing modifications
http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Serhiy Storchaka]

06.06.13 12:45, Chris Angelico написав(ла):

For the "accept any object that has a next() method" sorts of rules, I
don't know of any really viable system that does that usefully. The
concept of implementing interfaces in Java comes close, but the class
author has to declare that it's implementing some named interface. In
theory there could be something that deduces the validity from the
given structure, but I'm not aware of any language that does this.


Go?


--
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Thu, Jun 6, 2013 at 7:29 PM, Steven D'Aprano
 wrote:
> Whatever benefit there is in declaring the type of a function is lost due
> to the inability to duck-type or program to an interface. There's no type
> that says "any object with a 'next' method", for example. And having to
> declare local variables is a PITA with little benefit.
>
> Give me a language with type inference, and a nice, easy way to keep duck-
> typing, and I'll reconsider. But until then, I don't believe the benefit
> of static types comes even close to paying for the extra effort.

Here are some classic ways to do the multiple-types-accepted option.

//C++ style: overloading
int max(int a,int b) {return a>b ? a : b;}
float max(float a,float b) {return a>b ? a : b;}
//C++ also lets you go for templates, but leave that aside

//Pike style: piped types
int|float max(int|float a,int|float b) {return a>b ? a : b;}
//This lets you write one lot of code but doesn't let
//you declare that both args must be the same type

# Python style: accept anything, then (maybe) check
def max(a,b): return a if a>b else b
//Pike does this too:
mixed max(mixed a,mixed b) {return a>b ? a : b;}
/* So does C, but only with pointers: */
void *max(void *a,void *b) {... uhh, this is nontrivial actually ...}

For the "accept any object that has a next() method" sorts of rules, I
don't know of any really viable system that does that usefully. The
concept of implementing interfaces in Java comes close, but the class
author has to declare that it's implementing some named interface. In
theory there could be something that deduces the validity from the
given structure, but I'm not aware of any language that does this. But
it would let you do stuff like this (prototyped in Python):

class Integers:
def __init__(self): self.value=0
def next(self):
self.value+=1
return self.value

interface Iterable:
next(self)

def grab_three_values(Iterable iter):
return iter.next(),iter.next(),iter.next()

With a language that checks these sorts of things at compile time,
it's not a big deal to test. With something fully dynamic like Python,
it's probably not worth the effort. But maybe checks like this could
be useful to something like Coverity.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Steven D'Aprano]

On Thu, 06 Jun 2013 12:29:44 +1000, Chris Angelico wrote:

> On Thu, Jun 6, 2013 at 11:56 AM, Steven D'Aprano
>  wrote:
>> On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote:
>>> As for Python, my experience with it is that, as your application
>>> grows, you start getting confused about what the argument types are or
>>> are supposed to be.
>>
>> Whereas people never get confused about the arguments in static typed
>> languages?
>>
>> The only difference is whether the compiler tells you that you've
>> passed the wrong type, or your unit test tells you that you've passed
>> the wrong type. What, you don't have unit tests? Then how do you know
>> that the code does the right thing when passed data of the right type?
>> Adding an extra couple of unit tests is not that big a burden.
> 
> The valid type(s) for an argument can be divided into two categories:
> Those the compiler can check for, and those the compiler can't check
> for. Some languages have more in the first category than others, but
> what compiler can prove that a string is an
> HTML-special-characters-escaped string? In a very few languages, the
> compiler can insist that an integer be between 7 and 30, but there'll
> always be some things you can't demonstrate with a function signature.
> 
> That said, though, I do like being able to make at least *some*
> declaration there. It helps catch certain types of error.

*shrug*

I don't terribly miss type declarations. Function argument declarations 
are a bit simpler in Pascal, compared to Python:


Function Add(A, B : Integer) : Integer; 
Begin
 Add := A + B;
End;


versus


def add(a, b):
if not (isinstance(a, int) and isinstance(b, int)):
raise TypeError
return a + b


but not that much simpler. And while Python can trivially support 
multiple types, Pascal cannot. (Some other static typed languages may.)

Whatever benefit there is in declaring the type of a function is lost due 
to the inability to duck-type or program to an interface. There's no type 
that says "any object with a 'next' method", for example. And having to 
declare local variables is a PITA with little benefit.

Give me a language with type inference, and a nice, easy way to keep duck-
typing, and I'll reconsider. But until then, I don't believe the benefit 
of static types comes even close to paying for the extra effort.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Ian Kelly]

On Wed, Jun 5, 2013 at 10:25 PM, Russ P.  wrote:
> I recall reading a few years ago that Guido was thinking about adding 
> optional type annotations. I don't know if that went anywhere or not, but I 
> thought it was a good idea. Eventually I got tired of waiting, and I realized 
> that I just wanted a statically typed language, so I started using one.

Python 3 has support for arbitrary function argument annotations.  The
language itself ascribes no special meaning to it, so it's up to the
user to add a type-checker (or whatever else they might want to use it
for).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Russ P.]

On Wednesday, June 5, 2013 7:29:44 PM UTC-7, Chris Angelico wrote:
> On Thu, Jun 6, 2013 at 11:56 AM, Steven D'Aprano
> 
>  wrote:
> 
> > On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote:
> 
> >> As for Python, my experience with it is that, as
> 
> >> your application grows, you start getting confused about what the
> 
> >> argument types are or are supposed to be.
> 
> >
> 
> > Whereas people never get confused about the arguments in static typed
> 
> > languages?
> 
> >
> 
> > The only difference is whether the compiler tells you that you've passed
> 
> > the wrong type, or your unit test tells you that you've passed the wrong
> 
> > type. What, you don't have unit tests? Then how do you know that the code
> 
> > does the right thing when passed data of the right type? Adding an extra
> 
> > couple of unit tests is not that big a burden.
> 
> 
> 
> The valid type(s) for an argument can be divided into two categories:
> 
> Those the compiler can check for, and those the compiler can't check
> 
> for. Some languages have more in the first category than others, but
> 
> what compiler can prove that a string is an
> 
> HTML-special-characters-escaped string? In a very few languages, the
> 
> compiler can insist that an integer be between 7 and 30, but there'll
> 
> always be some things you can't demonstrate with a function signature.
> 
> 
> 
> That said, though, I do like being able to make at least *some*
> 
> declaration there. It helps catch certain types of error.

I recall reading a few years ago that Guido was thinking about adding optional 
type annotations. I don't know if that went anywhere or not, but I thought it 
was a good idea. Eventually I got tired of waiting, and I realized that I just 
wanted a statically typed language, so I started using one.

Steven's view on static vs. dynamic typing are interesting, but I think they 
are "out of the mainstream," for whatever that's worth. Does that mean he is 
wrong? I don't know. But I do know that statically typed code just seems to me 
to fit together tighter and more solidly. Maybe it's a liberal/conservative 
thing. Do liberals tend to favor dynamic typing?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Thu, Jun 6, 2013 at 11:56 AM, Steven D'Aprano
 wrote:
> On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote:
>> As for Python, my experience with it is that, as
>> your application grows, you start getting confused about what the
>> argument types are or are supposed to be.
>
> Whereas people never get confused about the arguments in static typed
> languages?
>
> The only difference is whether the compiler tells you that you've passed
> the wrong type, or your unit test tells you that you've passed the wrong
> type. What, you don't have unit tests? Then how do you know that the code
> does the right thing when passed data of the right type? Adding an extra
> couple of unit tests is not that big a burden.

The valid type(s) for an argument can be divided into two categories:
Those the compiler can check for, and those the compiler can't check
for. Some languages have more in the first category than others, but
what compiler can prove that a string is an
HTML-special-characters-escaped string? In a very few languages, the
compiler can insist that an integer be between 7 and 30, but there'll
always be some things you can't demonstrate with a function signature.

That said, though, I do like being able to make at least *some*
declaration there. It helps catch certain types of error.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Steven D'Aprano]

On Wed, 05 Jun 2013 14:59:31 -0700, Russ P. wrote:


> I'm not an Ada guy, but Ada advocates claim that it reduces development
> time by half in the long run compared to C and C++ due to reduced
> debugging time and simpler maintenance. 

They may be right. Far too many people think that C and C++ are "best of 
breed" in static languages. They aren't.


> Then again, I think Java people make a similar claim.

Java people would take credit for the sun coming up if they could :-)


> As for Python, my experience with it is that, as
> your application grows, you start getting confused about what the
> argument types are or are supposed to be. 

Whereas people never get confused about the arguments in static typed 
languages?

The only difference is whether the compiler tells you that you've passed 
the wrong type, or your unit test tells you that you've passed the wrong 
type. What, you don't have unit tests? Then how do you know that the code 
does the right thing when passed data of the right type? Adding an extra 
couple of unit tests is not that big a burden.

Of course, if there was a way to automate that, why wouldn't you take 
advantage of it? Python currently has no standard way of doing such 
automated type tests, and probably won't ever get one. A static typed 
language gives you those tests for free, but in many languages at the 
cost that you probably end up spending more time fighting to satisfy the 
compiler than you save by not writing unit tests.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Thu, Jun 6, 2013 at 11:37 AM, Steven D'Aprano
 wrote:
> What prevents bugs is the skill of the people writing the code, not the
> compiler.

+1 QOTW.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Steven D'Aprano]

On Wed, 05 Jun 2013 09:15:01 -0700, Russ P. wrote:

> On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
>> On 05/06/2013 07:11, Russ P. wrote:
>> 
>> > But then, what would you expect of a language that allows you to
>> > write
>> >
>> > x = 1
>> > x = "Hello"
>> >
>> > It's all loosey goosey -- which is fine for many applications but
>> > certainly not for critical ones.
>> >
>> 
>> 
>> I want to launch this rocket with an expensive satellite on top.  I
>> know it's safe as the code is written in ADA.  Whoops :(
> 
> 
> So Python would have been a better choice? Yeah, right. 

Putting issues of efficiency aside, yes, it probably would have. Had the 
programmers not been so sure that the compiler was protecting them from 
bugs, a misplaced hope if there ever was one, they might have written 
some tests and noticed that their simulated rocket launch ended up going 
boom instead of into orbit.

I'm referring to the first test flight of the Ariane 5, which failed due 
to a software bug. There was no actual satellite on this flight. The 
failure Mark refers to was due to a leak in coolant pipes, which of 
course is a hardware problem and cannot be blamed on the software.

http://en.wikipedia.org/wiki/Ariane_5#Notable_launches



> If you know
> anything about that rocket mishap, you should know that Ada was not the
> source of the problem. Ada won't keep airplane wings from breaking
> either, by the way. It's not magic.

Again, referring to the infamous 64-bit float to 16-bit integer bug, Ada 
may not have been the *source* of the problem, but neither did it prevent 
it.

What prevents bugs is the skill of the people writing the code, not the 
compiler. Compile-time static type checking is merely a tool, which has 
costs and benefits. It is ludicrous to think that any one single tool, or 
the lack of that tool, will make all the difference between working code 
and non-working code.

Static type-checking is no better, or worse, for "critical code" than 
dynamic type-checking. One language chooses to deal with some errors at 
compile-time, others deal with them at run-time. Either way, the 
programmer has to deal with them in some way.

A static type system forces you to deal with a limited subset of errors, 
"type errors", in one way only: by removing any execution paths in the 
software which would assign data of type X to a variable of type Y. For 
reasons of machine efficiency, that is often a good was to deal with such 
errors. But a dynamic type system makes different trade-offs.

And of course, type errors are such a vanishingly small subset of all the 
possible errors that might be made that, frankly, the difference in code 
quality between those with static typing and those without is essentially 
indistinguishable. There's no evidence that code written in static typed 
languages is less buggy than code written in dynamic languages.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Michael Torrie]

On 06/05/2013 05:52 PM, Russ P. wrote:
> My comment shows you nothing about what I understand about names, 
> objects, and variables.

Yes that probably is true.

> You have chosen to question my understanding apparently because my
> point bothered you but you don't have a good reply. Then you link me
> with Rick for good measure. That's two ad hominems in three
> sentences.

Your statement didn't bother me.  I just felt, perhaps erroneously, that
such a comment needs clarification.  We get into trouble in python when
we get caught up in treating python names exactly like variables and
blame it on the lack of static typing.  In uni we looked at various
means of dealing with the name covering/hiding issue including renaming
or requiring that each binding be a unique name (meaning the second x =
"hello word" statement would be a runtime error).  Anyway, I got a bit
distracted by your example of using the same name twice with different
objects when the real issue that can cause pain is function call
parameter expectation.

My apologies for linking you to Rick.  You're right that was an
ad-hominem attack, though I didn't intend that!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Russ P.]

On Wednesday, June 5, 2013 4:18:13 PM UTC-7, Michael Torrie wrote:
> On 06/05/2013 12:11 AM, Russ P. wrote:
> 
> > But then, what would you expect of a language that allows you to
> 
> > write
> 
> > 
> 
> > x = 1 
> 
> > x = "Hello"
> 
> > 
> 
> > It's all loosey goosey -- which is fine for many applications but
> 
> > certainly not for critical ones.
> 
> 
> 
> This comment shows me that you don't understand the difference between
> 
> names, objects, and variables.  May sound like a minor quibble, but
> 
> there're actually major differences between binding names to objects
> 
> (which is what python does) and variables (which is what languages like
> 
> C have).  It's very clear Rick does not have an understanding of this
> 
> either.

My comment shows you nothing about what I understand about names, objects, and 
variables. You have chosen to question my understanding apparently because my 
point bothered you but you don't have a good reply. Then you link me with Rick 
for good measure. That's two ad hominems in three sentences.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Michael Torrie]

On 06/05/2013 12:11 AM, Russ P. wrote:
> But then, what would you expect of a language that allows you to
> write
> 
> x = 1 
> x = "Hello"
> 
> It's all loosey goosey -- which is fine for many applications but
> certainly not for critical ones.

This comment shows me that you don't understand the difference between
names, objects, and variables.  May sound like a minor quibble, but
there're actually major differences between binding names to objects
(which is what python does) and variables (which is what languages like
C have).  It's very clear Rick does not have an understanding of this
either.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Russ P.]

On Wednesday, June 5, 2013 9:59:07 AM UTC-7, Chris Angelico wrote:
> On Thu, Jun 6, 2013 at 2:15 AM, Russ P. wrote:
> 
> > On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
> 
> >> I want to launch this rocket with an expensive satellite on top.  I know
> 
> >>
> 
> >> it's safe as the code is written in ADA.  Whoops :(
> 
> >
> 
> >
> 
> > So Python would have been a better choice? Yeah, right. If you know 
> > anything about that rocket mishap, you should know that Ada was not the 
> > source of the problem. Ada won't keep airplane wings from breaking either, 
> > by the way. It's not magic.
> 
> 
> 
> Frankly, I don't think the language much matters. It's all down to the
> 
> skill of the programmers and testers. Ada wasn't the source of the
> 
> problem unless Ada has a bug in it... which is going to be true of
> 
> pretty much any language. Maybe Python would be a better choice, maybe
> 
> not; but let me tell you this, if the choice of language means the
> 
> difference between testable in three months and testable code in three
> 
> years, I'm going for the former.
> 
> 
> 
> ChrisA

I'm not an Ada guy, but Ada advocates claim that it reduces development time by 
half in the long run compared to C and C++ due to reduced debugging time and 
simpler maintenance. Then again, I think Java people make a similar claim. As 
for Python, my experience with it is that, as your application grows, you start 
getting confused about what the argument types are or are supposed to be. That 
requires the developer to keep much more of the design in his head, and that 
undesirable. Of course, you can always put the argument types in comments, but 
that won't be verified by the compiler.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Thu, Jun 6, 2013 at 2:15 AM, Russ P.  wrote:
> On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
>> I want to launch this rocket with an expensive satellite on top.  I know
>>
>> it's safe as the code is written in ADA.  Whoops :(
>
>
> So Python would have been a better choice? Yeah, right. If you know anything 
> about that rocket mishap, you should know that Ada was not the source of the 
> problem. Ada won't keep airplane wings from breaking either, by the way. It's 
> not magic.

Frankly, I don't think the language much matters. It's all down to the
skill of the programmers and testers. Ada wasn't the source of the
problem unless Ada has a bug in it... which is going to be true of
pretty much any language. Maybe Python would be a better choice, maybe
not; but let me tell you this, if the choice of language means the
difference between testable in three months and testable code in three
years, I'm going for the former.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Russ P.]

On Wednesday, June 5, 2013 1:59:01 AM UTC-7, Mark Lawrence wrote:
> On 05/06/2013 07:11, Russ P. wrote:
> 
> 
> 
> > But then, what would you expect of a language that allows you to write
> 
> >
> 
> > x = 1
> 
> > x = "Hello"
> 
> >
> 
> > It's all loosey goosey -- which is fine for many applications but certainly 
> > not for critical ones.
> 
> >
> 
> 
> 
> I want to launch this rocket with an expensive satellite on top.  I know 
> 
> it's safe as the code is written in ADA.  Whoops :(


So Python would have been a better choice? Yeah, right. If you know anything 
about that rocket mishap, you should know that Ada was not the source of the 
problem. Ada won't keep airplane wings from breaking either, by the way. It's 
not magic.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Terry Jan Reedy]

On 6/5/2013 2:11 AM, Russ P. wrote:


But then, what would you expect of a language that allows you to
write

x = 1

> x = "Hello"


It's all loosey goosey -- which is fine for many applications but
certainly not for critical ones.


I believe Shedskin, a Python *subset* compiler*, will reject that, 
because it compiles ints to C ints. Some code checkers might too.



--
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Lawrence]

On 05/06/2013 07:11, Russ P. wrote:


But then, what would you expect of a language that allows you to write

x = 1
x = "Hello"

It's all loosey goosey -- which is fine for many applications but certainly not 
for critical ones.



I want to launch this rocket with an expensive satellite on top.  I know 
it's safe as the code is written in ADA.  Whoops :(


--
"Steve is going for the pink ball - and for those of you who are 
watching in black and white, the pink is next to the green." Snooker 
commentator 'Whispering' Ted Lowe.


Mark Lawrence

--
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Russ P.]

On Wednesday, June 5, 2013 12:15:57 AM UTC-7, Chris Angelico wrote:
> On Wed, Jun 5, 2013 at 4:11 PM, Russ P. wrote:
> 
> > On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote:
> 
> >
> 
> >> Yes, but the problem is not "my approach", rather the lack
> 
> >>
> 
> >> of proper language design (my apologizes to the "anointed
> 
> >>
> 
> >> one". ;-)
> 
> >
> 
> > If you don't like implicit conversion to Boolean, then maybe you should be 
> > using another language -- and I mean that in a constructive sense. I'm not 
> > particularly fond of it either, but I switched from Python to another 
> > language a while back. The issue is not a lack of "proper language design" 
> > but rather a language design philosophy that values conciseness and 
> > simplicity over explicitness and rigor.
> 
> 
> 
> (Out of curiosity, which language? Feel free to not answer, or to
> 
> answer off-list, as that's probably not constructive to the thread.)

No problem. I'm using Scala. It has a sophisticated type system. The language 
is not perfect, but it seems to suit my needs fairly well.

> 
> 
> I cannot name a single modern programming language that does NOT have
> 
> some kind of implicit boolification. The only such language I know of
> 
> is REXX, which has a single data type for everything, but insists on
> 
> the exact strings "1" and "0" for True and False, anything else is an
> 
> error. Every other language has some definition of "these things are
> 
> true, these are false"; for instance:


Scala (and Java) don't do that. Nor does Ada. That's because Ada is designed 
for no-nonsense critical systems. It is the standard higher-order language for 
flight control systems, for example. 


> > It's all loosey goosey -- which is fine for many applications but certainly 
> > not for critical ones.
> 
> 
> 
> The looseness doesn't preclude critical applications. It's all a
> 
> question of what you're testing. Does your code care that this be a
> 
> list, and not something else? Then test! You have that option. What
> 
> happens if it isn't a list, and something is done that bombs with an
> 
> exception? Maybe that's not a problem.
> 
> 
> 
> Critical applications can often be built in layers. For instance, a
> 
> network server might listen for multiple socket connections, and for
> 
> each connection, process multiple requests. You would want to catch
> 
> exceptions at the two boundaries there; if a request handler crashes,
> 
> the connection should not be dropped, and if a connection handler
> 
> crashes, the server should keep running. With some basic defenses like
> 
> that, your code need no longer concern itself with trivialities - if
> 
> something goes wrong, there'll be an exception in the log. (BTW, this
> 
> is one of the places where a bare or very wide except clause is
> 
> appropriate. Log and move on.)


Well, I don't really want to open the Pandora's box of static vs. dynamic 
typing. Yes, with enough testing, I'm sure you can get something good out of a 
dynamically typed language for small to medium-sized applications, but I have 
my doubts about larger applications. However, I don't claim to be an expert. 
Someone somewhere has probably developed a solid large application in Python. 
But I'll bet a dollar to a dime that it took more work than it would have taken 
in a good statically typed language. Yes, extensive testing can go a long way, 
but extensive testing combined with good static typing can go even further for 
the same level of effort.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Wed, Jun 5, 2013 at 4:11 PM, Russ P.  wrote:
> On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote:
>
>> Yes, but the problem is not "my approach", rather the lack
>>
>> of proper language design (my apologizes to the "anointed
>>
>> one". ;-)
>
> If you don't like implicit conversion to Boolean, then maybe you should be 
> using another language -- and I mean that in a constructive sense. I'm not 
> particularly fond of it either, but I switched from Python to another 
> language a while back. The issue is not a lack of "proper language design" 
> but rather a language design philosophy that values conciseness and 
> simplicity over explicitness and rigor.

(Out of curiosity, which language? Feel free to not answer, or to
answer off-list, as that's probably not constructive to the thread.)

I cannot name a single modern programming language that does NOT have
some kind of implicit boolification. The only such language I know of
is REXX, which has a single data type for everything, but insists on
the exact strings "1" and "0" for True and False, anything else is an
error. Every other language has some definition of "these things are
true, these are false"; for instance:

* C-family languages treat all nonzero integers as true
* Shells treat 0 as "success" and nonzero as "error", and therefore as
"true" and "false" respectively (yes, this IS an inversion)
* Pike allows any variable to contain the integer 0, regardless of its
declared type, and thus is a sort of "null" value which is false; all
strings, arrays, mappings, etc are true
* Python treats an empty "thing" as false and a nonempty one as true

SQL is like REXX in that it's fairly strict; a condition must be a
boolean (example from PostgreSQL):

rosuav=> select 1+2 where 1;
ERROR:  argument of WHERE must be type boolean, not type integer
LINE 1: select 1+2 where 1;
 ^

But an explicit conversion is permitted:

rosuav=> select 1+2 where cast (5 as boolean);
 ?column?
--
3
(1 row)


> It's all loosey goosey -- which is fine for many applications but certainly 
> not for critical ones.

The looseness doesn't preclude critical applications. It's all a
question of what you're testing. Does your code care that this be a
list, and not something else? Then test! You have that option. What
happens if it isn't a list, and something is done that bombs with an
exception? Maybe that's not a problem.

Critical applications can often be built in layers. For instance, a
network server might listen for multiple socket connections, and for
each connection, process multiple requests. You would want to catch
exceptions at the two boundaries there; if a request handler crashes,
the connection should not be dropped, and if a connection handler
crashes, the server should keep running. With some basic defenses like
that, your code need no longer concern itself with trivialities - if
something goes wrong, there'll be an exception in the log. (BTW, this
is one of the places where a bare or very wide except clause is
appropriate. Log and move on.)

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Russ P.]

On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote:

> Yes, but the problem is not "my approach", rather the lack
> 
> of proper language design (my apologizes to the "anointed
> 
> one". ;-)

If you don't like implicit conversion to Boolean, then maybe you should be 
using another language -- and I mean that in a constructive sense. I'm not 
particularly fond of it either, but I switched from Python to another language 
a while back. The issue is not a lack of "proper language design" but rather a 
language design philosophy that values conciseness and simplicity over 
explicitness and rigor. 

Implicit conversion to Boolean is only one of many language features that are 
questionable for critical production software. Another is the convention of 
interpreting negative indices as counting backward from the end of a list or 
sequence. Yeah, I thought that was elegant... until it bit me. Is it a bad 
idea? Not necessarily. It certainly enhances programmer productivity, and it 
can be done correctly "almost" all the time. But that one time in a hundred or 
a thousand when you accidentally use a negative index can be a bitch.

But then, what would you expect of a language that allows you to write

x = 1
x = "Hello"

It's all loosey goosey -- which is fine for many applications but certainly not 
for critical ones.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[alex23]

On Jun 5, 3:28 pm, Steven D'Aprano  wrote:
> How many years has Rick been coming here, proclaiming loudly  [a]nd yet, 
> he still has no clue what
>  actually means.

It's not just duck typing.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Steven D'Aprano]

On Wed, 05 Jun 2013 02:27:26 +1000, Chris Angelico wrote:

> On Wed, Jun 5, 2013 at 2:19 AM, Rick Johnson
>  wrote:
>> On Jun 4, 11:00 am, Chris Angelico  wrote:
>>> You know, if you want a language with strict type declarations and
>>> extreme run-time efficiency, there are some around.
>>
>> I don't like declaring types everywhere, i hate it. I prefer duck typed
>> languages, HOWEVER, in order for duck typing to work consistently you
>> must have checks and balances that the programmer can apply when he
>> feels necessary. My "is_valid" built in will bridge the gap. We won't
>> be forced to declare types, but we should ALWAYS add "type checks" to
>> our "truth tests" unless we want to create subtle bugs. "is_valid" IS
>> the answer!
> 
> Option 1:
> 
> void C_function(int x)
> 
> Option 2:
> 
> def Python_function(x):
> assert isinstance(x,int)
> 
> Is there a fundamental difference? You're basically proposing Option 2
> while detesting Option 1.


How many years has Rick been coming here, proclaiming loudly how much he 
loves Python's duck-typing? Ten years? And yet, he still has no clue what 
it actually means.

If you're performing a type-check, IT ISN'T DUCK-TYPING.

Duck typing means you don't care whether you have an int, so long as 
whatever object you get is usable where an int is usable. 

Now, there are many places in my own code where I decide that I wish to 
prohibit duck-typing. "Here I insist on an actual int, not just any old 
number." There are, sometimes, good reasons for this. But every time I do 
this, I am *not* duck-typing, I am doing a runtime type check which is 
completely opposite in intent to duck-typing. (There's no short name for 
this -- it's not quite static typing, because it happens at runtime and 
isn't enforced by the language.) 

It's almost like Rick declares that he's a great supporter of the free 
market, and that everyone should be free to buy and trade in whatever 
property they wish, while insisting that nothing can be bought or sold 
without permission from the government first.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Michael Torrie]

On 06/04/2013 05:21 PM, Rick Johnson wrote:
> If you still feel that this idea is garbage, then, keep on writing
> your sloppy code. My proposal is the best method to handle the
> problems that arise with duck typed languages in a manner that is not
> restrictive or laborious -- it's actually quite elegant.

Like most of your proposals, this does not have anything to do with the
python syntax itself.  You just demonstrated code that does what you
want.  So use it then.  Adopt it in your own code, encourage others to
use it.  No changes to Python are needed.  If this technique proves its
value, then it will be adopted.  If not, it will die.  Start using it in
one of your major open source projects.

> *school-bell-rings*

It's one thing to patronize people as you try to do to D'Aprano (and yes
I admit that most replies to your posts are often patronizing to you in
return), but you do realize this infantile attempt to try to make
yourself look smarter than others really reflects poorly on you?  I for
one feel badly for you on this count, or at least embarrassed.  So just
a suggestion... drop the school bell and teacher stuff (or at least
share your qualifications with us).  It's really tiring, though to be
fair not quite as tiring as trying to help someone with an iron skull
get a CGI script working.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Steven D'Aprano]

On Tue, 04 Jun 2013 05:23:19 -0700, jmfauth wrote:

> How is is possible to arrive to such a situation ? The answer if far
> beyond my understanding

Truer words have never been spoken.


> (although I have my opinion on the subject).


http://en.wikipedia.org/wiki/Dunning–Kruger_effect



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[alex23]

On Jun 5, 2:09 am, Rick Johnson  wrote:
> This is how you design a language for consistency and readability.

Great! Now you can shut up and get back to work on RickPython4000.
Come back and let us know all about it when it's done.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Mark Lawrence]

On 05/06/2013 00:21, Rick Johnson wrote:
[snip]

Would you be kind enough not to smoke too much wacky baccy before 
posting, thanks.


--
"Steve is going for the pink ball - and for those of you who are 
watching in black and white, the pink is next to the green." Snooker 
commentator 'Whispering' Ted Lowe.


Mark Lawrence

--
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Rick Johnson]

On Jun 4, 12:42 pm, Ian Kelly  wrote:

> > By this manner, we can roll three common tests into one
> > method:
> > * Boolean conversion
> > * member truthiness for iterables
> > * type checking
> How exactly does this is_valid method perform the first two?  Are you
> suggesting that an empty sequence should not be considered "valid"?

I'm suggesting that the rules for Python's current "implicit
conversion to Boolean" simply be moved into a "explicit function"
named "isvalid", that also does a type check. Here is some Python code
that might help you understand.

py> def isvalid(object_, type_):
... if isinstance(object_, type_) and object_:
... return True
... return False
py> isvalid([], list)
False
py> isvalid([1], list)
True
py> isvalid(0, int)
False
py> isvalid(1, int)
True
py> isvalid({}, dict)
False
py> isvalid("", str)
False
py> isvalid(" ", str)
True

Now, let's go back to my earlier example of where i was expecting a
list but got a string instead. If i use Python's current implicit
conversion to Boolean my code will do something i don't want it to do.

py> lst = " "
py> if lst:
... print("I'm a liar")
... else:
... print("I'm honest")
I'm a liar

But unlike this simple example (which failed quickly) in the real
world, it may not fail for a long time. And when it does fail, you
will be pulling your hair out tracking down the origin of the bug. If
however i use my "isvalid" function, my conditional will not lie to
me:

py> lst = " "
py> if isvalid(lst, list):
... print("I'm a liar")
... else:
... print("I'm honest")
I'm honest

Now. You're not always going to need to "isvalid" function. Sometimes
you just need to test type, sometimes you just need convert to
Boolean, and sometimes you can just fly by the seat of your pants. The
point is, remove implicitly and inject explicitly.

Furthermore: If the current "implicit conversion to Boolean" can be
optimized by Python, then there is no reason why an explicit "isvalid"
function cannot -- any talk to the contrary is just BS.

If you still feel that this idea is garbage, then, keep on writing
your sloppy code. My proposal is the best method to handle the
problems that arise with duck typed languages in a manner that is not
restrictive or laborious -- it's actually quite elegant.

*school-bell-rings*
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Ian Kelly]

On Tue, Jun 4, 2013 at 9:44 AM, Rick Johnson
 wrote:
> It is my firm belief that truth testing a value that is not
> a Boolean should raise an exception. If you want to convert
> a type to Boolean then pass it to the bool function:
>
> lst = [1,2,3]
> if bool(lst):
> do_something
>
> This would be "explicit enough"

That is *exactly* equivalent to the same test without the bool
function, and it gives the reader zero additional information about
what "lst" is, so it boggles me that you approve of this "if
bool(lst):" monstrosity while decrying the equivalent and slightly
more efficient "if lst:".

I think part of your complaint concerns the fact that the reader must
understand the rules by which a truth value is implicitly obtained
from lst in the statement "if lst:".  But the reader must know the
*same* rules in order to understand the more explicit "if bool(lst):",
so there is no benefit to the latter in that regard either.

> Yes i do care about the length or i would not have asked.
> I'm asking Python to tell me if the iterable has members,
> amd if it does, i want to execute a block of code, if it
> does not, i want to do nothing. But i'm also informing the
> reader of my source code that the symbol i am truth testing
> is expected to be an iterable with a __len__ method.

Caring that the object has a length is not the same as caring about
what the object's length is.  Steven's point stands, that your code
inefficiently asks the object for some property that you don't (yet)
care about.

> "if lst" does not give me the same answer (or imply the same
> meaning to a reader), it merely tells me that the implict
> conversion has resulted in a True value, but what if the lst
> symbol is pointing to a string? Then i will falsely believe
> i have a list with members when i actually have a string
> with length greater than zero.

Your "if len(lst) > 0" fails to differentiate lists from strings in
exactly the same way.

> I agree. Summing the list members just to guarantee that the
> iterable has members is foolish, however, python gives me no
> other choice IF i want to be "explicit enough". In a
> properly designed language, the base iterable object would
> supply a "hasLength" or "hasMembers" method that would
> return a much faster check of:
>
> try:
> iterable[0]
> except IndexError:
> return False
> else:
> return True
>
> That check would guarantee the iterable contained at least
> one member without counting them all.

You said earlier in your post that "bool(lst)" was "explicit enough",
and this is exactly what it does.

> When i am writing code i prefer to be "explicit enough" so
> that IF my assumptions about the exact type of an object are
> incorrect, the code will fail quickly enough that i can
> easily find and correct the problem.

In a duck-typing language you should not be making assumptions about
the "exact type" of an object in the first place.  If I'm writing a
function that receives a list-like argument, then at the *most
specific* I will assume that the object passed in is a MutableSequence
(but since I prefer to keep my functions functional where practical,
more usually I will assume only that the object is an iterable or a
generic sequence).  If the caller wants to pass in a deque or some
user-defined generic MutableSequence instead, then let them do so.  I
will also clearly document that assumption; if the caller can't be
bothered to read the docs and passes in an object that breaks that
assumption, then that's their own damn problem when it doesn't work.
This is a programming language for consenting adults.

> But we are really ignoring the elephant in the room. Implict
> conversion to Boolean is just a drop in the bucket compared
> to the constant "shell game" we are subjected to when
> reading source code. We so naively believe that a symbol
> named "lst" is a list object or a symbol "age" is a integer,
> when we could be totally wrong! This is the source of many
> subtle bugs!!!

I am more likely to believe that an object is a list based on the
documentation than on the mere fact that it is named "lst".  The
variable *does* have documentation, doesn't it?  If when debugging I
have reason to suspect that the documentation is incorrect or is being
ignored, then I'll add an assertion to test it.

> There must be some method by which we can truth test an
> iterable object and verify it has members, but do so in a
> manner that is valid for all types AND exposes the "expected
> type" in the method name. hmm...

This is nonsense.  If it exposes the "expected type" in the name, then
it can only be valid for that expected type.

> Adding a method like "is_valid" to every object can seem
> logical, however, this can fail just as miserably as
> Python's current implicit bool. And, more disastrously, an
> "is_valid" method is not going to raise an error (where it
> should) because it works for all types.

Actually it sounds completely illogic

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Jason Swails]

On Tue, Jun 4, 2013 at 11:44 AM, Rick Johnson
wrote:

>
> This implicit conversion seems like a good idea at first,
> and i was caught up in the hype myself for some time: "Hey,
> i can save a few keystrokes, AWESOME!". However, i can tell
> you with certainty that this implicit conversion is folly.
> It is my firm belief that truth testing a value that is not
> a Boolean should raise an exception. If you want to convert
> a type to Boolean then pass it to the bool function:
>
> lst = [1,2,3]
> if bool(lst):
> do_something
>
> This would be "explicit enough"


i
f lst:
do_something

is equivalent to

if bool(lst):
   do_something

why not just have your editor autobool so you can spend more time coding
and less time stamping around?  That way the person that finds booled code
more readable can have what he wants and the people that find it less
readable can have what they want.

Win-win

BTW, you should do pointless comparisons like

if condition is True:
do_something

rather than

if condition == True
do_something
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Ned Batchelder]

On 6/4/2013 12:19 PM, Rick Johnson wrote:

On Jun 4, 11:00 am, Chris Angelico  wrote:

You know, if you want a language with strict type declarations and
extreme run-time efficiency, there are some around.

I don't like declaring types everywhere, i hate it. I prefer duck
typed languages, HOWEVER, in order for duck typing to work
consistently you must have checks and balances that the programmer can
apply when he feels necessary. My "is_valid" built in will bridge the
gap. We won't be forced to declare types, but we should ALWAYS add
"type checks" to our "truth tests" unless we want to create subtle
bugs. "is_valid" IS the answer!



You are mis-using the term "duck typing." It doesn't mean just, "no type 
declarations." It also means, "the type of the value is irrelevant, all 
that matters is what it can do."  Insisting that something be a list (or 
a dict, ...) is unnecessary and counter to the duck-typing philosophy.  
What's important is that you can iterate, or index it, or whatever it is 
you want to do with the list.  The abstract base classes in the 
collections module were designed to help with determining these 
capabilities: 
http://docs.python.org/2/library/collections.html#collections-abstract-base-classes 
Of course, often, it's best just to do what you want to do rather than 
checking first.


Also, I have no idea why [] isn't a "valid" list.  Surely different 
applications will have different needs for what counts as valid once the 
type-check is passed.


--Ned.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Wed, Jun 5, 2013 at 2:19 AM, Rick Johnson
 wrote:
> On Jun 4, 11:00 am, Chris Angelico  wrote:
>> You know, if you want a language with strict type declarations and
>> extreme run-time efficiency, there are some around.
>
> I don't like declaring types everywhere, i hate it. I prefer duck
> typed languages, HOWEVER, in order for duck typing to work
> consistently you must have checks and balances that the programmer can
> apply when he feels necessary. My "is_valid" built in will bridge the
> gap. We won't be forced to declare types, but we should ALWAYS add
> "type checks" to our "truth tests" unless we want to create subtle
> bugs. "is_valid" IS the answer!

Option 1:

void C_function(int x)

Option 2:

def Python_function(x):
assert isinstance(x,int)

Is there a fundamental difference? You're basically proposing Option 2
while detesting Option 1.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Rick Johnson]

On Jun 4, 11:00 am, Chris Angelico  wrote:
> You know, if you want a language with strict type declarations and
> extreme run-time efficiency, there are some around.

I don't like declaring types everywhere, i hate it. I prefer duck
typed languages, HOWEVER, in order for duck typing to work
consistently you must have checks and balances that the programmer can
apply when he feels necessary. My "is_valid" built in will bridge the
gap. We won't be forced to declare types, but we should ALWAYS add
"type checks" to our "truth tests" unless we want to create subtle
bugs. "is_valid" IS the answer!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Rick Johnson]

On Jun 4, 10:44 am, Rick Johnson  wrote:

> What we need is a method by which we can validate a symbol
> and simultaneously do the vaidation in a manner that will
> cast light on the type that is expected. In order for this
> to work, you would need validators with unique "type names"
>
>     if var.is_validList():
>     elif var.is_validString():
>     elif var.is_vaildTuple():
>     elif var.is_validInteger():
>     elif var.is_validFloat():
>     elif var.is_validDict():
>     etc...

Actually, instead of forcing all types to have many "specific"
methods, one builtin could solve the entire issue. The function would
be similar to isinstance() taking two arguments "object" and "type",
however, it will not only guarantee type but also handle the
conversion to Boolean:

   if is_valid(var, list):
   # if this block executes we know
   # the var is of  and
   # var.length is greater than one.
   else:
   # if this block executes we know
   # that var is not of 
   # or, var.length equals zero.

The is_valid function would replace implicit Boolean conversion for
all types in manner that is "explicit enough" whilst maintaining
finger longevity. This is how you design a language for consistency
and readability.

Again. PUCKER UP WHO-VILLE!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Fábio Santos]

On 4 Jun 2013 17:04, "Chris Angelico"  wrote:
>
> On Wed, Jun 5, 2013 at 1:44 AM, Rick Johnson
>  wrote:
> > But we are really ignoring the elephant in the room. Implict
> > conversion to Boolean is just a drop in the bucket compared
> > to the constant "shell game" we are subjected to when
> > reading source code. We so naively believe that a symbol
> > named "lst" is a list object or a symbol "age" is a integer,
> > when we could be totally wrong! This is the source of many
> > subtle bugs!!!
>
> You know, if you want a language with strict type declarations and
> extreme run-time efficiency, there are some around. I think one of
> them might even be used to make the most popular Python. Give it a
> try, you might like it! There's NO WAY that you could accidentally
> pass a list to a function that's expecting a float, NO WAY to
> unexpectedly call a method on the wrong type of object. It would suit
> you perfectly!
>

I agree. I have never had this kind of issues in a dynamic language. Except
when passing stuff to Django's fields. And in JavaScript. It seems like the
thing was made to create references to `undefined`. And make them easily
convertible to numbers and strings so that our calculations mysteriously
fail when we're missing a function argument somewhere.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Chris Angelico]

On Wed, Jun 5, 2013 at 1:44 AM, Rick Johnson
 wrote:
> But we are really ignoring the elephant in the room. Implict
> conversion to Boolean is just a drop in the bucket compared
> to the constant "shell game" we are subjected to when
> reading source code. We so naively believe that a symbol
> named "lst" is a list object or a symbol "age" is a integer,
> when we could be totally wrong! This is the source of many
> subtle bugs!!!

You know, if you want a language with strict type declarations and
extreme run-time efficiency, there are some around. I think one of
them might even be used to make the most popular Python. Give it a
try, you might like it! There's NO WAY that you could accidentally
pass a list to a function that's expecting a float, NO WAY to
unexpectedly call a method on the wrong type of object. It would suit
you perfectly!

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Bools and explicitness [was Re: PyWart: The problem with "print"]

[Rick Johnson]

On Tuesday, June 4, 2013 12:39:59 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 03 Jun 2013 18:37:24 -0700, Rick Johnson wrote:

> Consider a simple thought experiment. Suppose we start with a sequence of 
> if statements that begin simple and get more complicated:
> if a == 1: ...
> if a == 1 and b > 2*c: ...
> if a == 1 and b > 2*c or d%4 == 1: ...
> if a == 1 and b > 2*c or d%4 == 1 and not (d**3//7)%3 == 0: ...
> I don't believe that any of these tests are improved by adding an 
> extraneous "== True" at the end:
> if (a == 1) == True: ...
> if (a == 1 and b > 2*c) == True: ...
> if (a == 1 and b > 2*c or d%4 == 1) == True: ...
> if (a == 1 and b > 2*c or d%4 == 1 and not (d**3//7)%3 == 0) == True: ...

And i agree!

You are misunderstanding my very valid point. Post-fixing a
"== True" when truth testing a *real* Boolean (psst: that's
a True or False object) is superfluous, I'm referring to
truth testing non-Boolean values. So with that in mind, the
following is acceptably "explicit enough" for me:

a = True
if a:
do_something()

However, since Python allows implicit conversion to Boolean
for ALL types, unless we know for sure, beyond any
reasonable doubt, that the variable we are truth testing is
pointing to a True or False object, we are taking too many
chances and will eventually create subtle bugs.

a = " "
if a:
do_something()

When if write code that "truth tests", i expect that the
value i'm testing is a True or False object, not an empty
list that *magically* converts to False when i place an "if"
in front of it, or a list with more members that magically
converts to True when i place an "if" in front of it.

This implicit conversion seems like a good idea at first,
and i was caught up in the hype myself for some time: "Hey,
i can save a few keystrokes, AWESOME!". However, i can tell
you with certainty that this implicit conversion is folly.
It is my firm belief that truth testing a value that is not
a Boolean should raise an exception. If you want to convert
a type to Boolean then pass it to the bool function:

lst = [1,2,3]
if bool(lst):
do_something

This would be "explicit enough"


> If you are unfamiliar with Python, then you have to learn what the 
> semantics of "if lst" means. Just as you would have to learn what 
> "if len(lst) > 0" means.

Again, i understand the folly of "implicit Boolean
conversion" just fine.

> > I prefer to be explicit at the cost of a few keystrokes:
> >   if len(lst) > 0:
> This line of code is problematic, for various reasons:
> - you're making assumptions about the object which are unnecessary;
> - which breaks duck-typing;
> - and risks doing too much work, or failing altogether.
> You're looking up the length of the lst object, but you don't really care 
> about the length. 

Yes i do care about the length or i would not have asked.
I'm asking Python to tell me if the iterable has members,
amd if it does, i want to execute a block of code, if it
does not, i want to do nothing. But i'm also informing the
reader of my source code that the symbol i am truth testing
is expected to be an iterable with a __len__ method.

"if lst" does not give me the same answer (or imply the same
meaning to a reader), it merely tells me that the implict
conversion has resulted in a True value, but what if the lst
symbol is pointing to a string? Then i will falsely believe
i have a list with members when i actually have a string
with length greater than zero.

> You only care about whether there is something there or 
> not, whether lst is empty or not. It makes no difference whether lst 
> contains one item or one hundred million items, and yet you're asking to 
> count them all. Only to throw that count away immediately!

I agree. Summing the list members just to guarantee that the
iterable has members is foolish, however, python gives me no
other choice IF i want to be "explicit enough". In a
properly designed language, the base iterable object would
supply a "hasLength" or "hasMembers" method that would
return a much faster check of:

try:
iterable[0]
except IndexError:
return False
else:
return True

That check would guarantee the iterable contained at least
one member without counting them all.

> Looking at the length of a built-in list is cheap, but why assume it is a 
> built-in list? Perhaps it is a linked list where counting the items 
> requires a slow O(N) traversal of the entire list. Or some kind of lazy 
> sequence that has no way of counting the items remaining, but knows 
> whether it is exhausted or not.

Yes, but the problem is not "my approach", rather the lack
of proper language design (my apologizes to the "anointed
one". ;-)

> The Python way is to duck-type, and to let the lst object decide for 
> itself whether it's empty or not:
> if lst: ...
> not to make assumptions about the specific type and performance of the 
> object.

Well Steven, in the real world sometime

Re: PyWart: The problem with "print"

[Mark Lawrence]

On 04/06/2013 14:29, rusi wrote:

On Jun 4, 5:23 pm, jmfauth  wrote:

On 2 juin, 20:09, Rick Johnson  wrote:




I never purposely inject ANY superfluous cycles in my code except in
the case of testing or development. To me it's about professionalism.
Let's consider a thought exercise shall we?




The flexible string representation is the perfect example
of this lack of professionalism.
Wrong by design, a non understanding of the mathematical logic,
of the coding of characters, of Unicode and of the usage of
characters (everything is tight together).

How is is possible to arrive to such a situation ?
The answer if far beyond my understanding (although
I have my opinion on the subject).

jmf


The Clash of the Titans

Lé jmf chârgeth with mightƴ might
And le Mond underneath trembleth
Now RR mounts his sturdy steed
And the windmill yonder turneth



+1 funniest poem of the week :)

--
"Steve is going for the pink ball - and for those of you who are 
watching in black and white, the pink is next to the green." Snooker 
commentator 'Whispering' Ted Lowe.


Mark Lawrence

--
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[rusi]

On Jun 4, 5:23 pm, jmfauth  wrote:
> On 2 juin, 20:09, Rick Johnson  wrote:
>
>
>
> > I never purposely inject ANY superfluous cycles in my code except in
> > the case of testing or development. To me it's about professionalism.
> > Let's consider a thought exercise shall we?
>
> 
>
> The flexible string representation is the perfect example
> of this lack of professionalism.
> Wrong by design, a non understanding of the mathematical logic,
> of the coding of characters, of Unicode and of the usage of
> characters (everything is tight together).
>
> How is is possible to arrive to such a situation ?
> The answer if far beyond my understanding (although
> I have my opinion on the subject).
>
> jmf

The Clash of the Titans

Lé jmf chârgeth with mightƴ might
And le Mond underneath trembleth
Now RR mounts his sturdy steed
And the windmill yonder turneth
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[jmfauth]

On 2 juin, 20:09, Rick Johnson  wrote:

> >
> >
>
> I never purposely inject ANY superfluous cycles in my code except in
> the case of testing or development. To me it's about professionalism.
> Let's consider a thought exercise shall we?
>





The flexible string representation is the perfect example
of this lack of professionalism.
Wrong by design, a non understanding of the mathematical logic,
of the coding of characters, of Unicode and of the usage of
characters (everything is tight together).

How is is possible to arrive to such a situation ?
The answer if far beyond my understanding (although
I have my opinion on the subject).

jmf


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Chris Angelico]

On Tue, Jun 4, 2013 at 11:37 AM, Rick Johnson
 wrote:
> The print function is the very definition of a "syntactic sugar".
>
> For example:
> print("some sting")
>
> is much more readable than:
>
> sys.stdout.write("some string"+"\n")
> ...
> Again, the removal of a print function (or print statement)
> will not prevent users from calling the write method on
> sys.stdout or sys.stderr (or ANY "stream object" for that matter!)

And you could abolish ALL of the builtins by requiring that you import
ctypes and implement them all yourself. That is not the point of the
term. If print() is mere syntactic sugar, then everything is syntactic
sugar for Brainf* code.

The point of syntactic sugar is that there is a trivially-equivalent
underlying interpretation. For instance, in C, array subscripting is
trivially equivalent to addition and dereferencing:

a[i]   <->   *(a+i)

This is syntactic sugar. The Python print() function does much more
than write(), so it is NOT syntactic sugar.

> Many times you'll get a result (or an input) that you expect
> to be a Boolean, but instead is a string. A good example of
> poor coding is "dialog box return values". Take your
> standard yes/no/cancel dialog, i would expect it to return
> True|False|None respectively, HOWEVER, some *idiot* decided
> to return the strings 'yes'|'no'|'cancel'.

Why True|False|None? Why should they represent Yes|No|Cancel?
Especially, *why None*? What has None to do with Cancel?

> However, with Python's implicit conversion to Boolean, the
> same conditional will ALWAYS be True: because any string
> that is not the null string is True (as far as Python is
> concerned). This is an example of Python devs breaking TWO
> Zens at once:
>
>  "explicit is better than implicit"
>  "errors should NEVER pass silently"

Right, because it's Python's fault that you can't use implicit boolean
conversion to sanely test for something that has three possible
outcomes. I think there's something in the nature of a boolean test
that makes this awkward, but I can't quite see it... hmm, some kind of
integer issue, I think...

> Obviously you don't appreciate the value of "explicit enough".
>
>   if VALUE:
>
> is not explicit enough, however
>
>   if bool(VALUE)
>
> or at least:
>
>   if VALUE == True
>
> is "explicit enough".

Why? The 'if' implies a boolean context. In C, it's common to compare
integers for nonzeroness with a bare if; it's also common, though far
from universal, to compare strings for nullness - effectively
equivalent to "is not None". You don't need to be any more explicit
than that.

Granted, the definitions of truthiness differ from language to
language. In C, a NULL pointer is false and any actual pointer is
true, so an empty string is true (to the extent that C even has the
concept of strings, but leave that aside). In Pike, any array is true,
but the absence of an array can be indicated with (effectively) a
null, whereas Python deems that an empty list is false. Still, most
languages do have some system of coercion-to-boolean. (Notable
exception: REXX. An IF statement will accept *only* the two permitted
boolean values, anything else is an error.)

> However, if i choose to be explicit and use:
>
>   "if len(VALUE) > 0:
>
> then the code will fail when it should: at the comparison
> line.  Because any object that does not provide a __len__
> method would cause Python to raise NameError.

I thought you were dead against wasting CPU cycles! Your code here has
to calculate the actual length of the object, then compare it with
zero; the simple boolean check merely has to announce the presence or
absence of content. This is a HUGE difference in performance, and you
should totally optimize this down for the sake of that. Don't bother
measuring it, this will make more difference to your code than
replacing bubble sort with bogosort!

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Bools and explicitness [was Re: PyWart: The problem with "print"]

[Steven D'Aprano]

On Mon, 03 Jun 2013 18:37:24 -0700, Rick Johnson wrote:
> On Sunday, June 2, 2013 1:58:30 PM UTC-5, Steven D'Aprano wrote:
>> On Sun, 02 Jun 2013 10:04:00 -0700, Rick Johnson wrote:

>> > A "wise programmer" may think he's solved the problem by writing a
>> > function called "debugprint" that looks like this:
>> > > def debugprint(*args):
>> > if DEBUG == True:
>> > print(*args)
>>
>> No no no, that's not how you do it. It should be:
>> if DEBUG == True == True:
>>
>> Wait, no, I got that wrong. It should be:
>> if DEBUG == True == True == True:
>>
>> Hang on, I've nearly got it!
>> if DEBUG == True == True == True == True:
>>
>> Or, you could program like a professional, and say:
>> if DEBUG:
> 
> Obviously you don't appreciate the value of "explicit enough".
> 
>   if VALUE:
> 
> is not explicit enough, however

Consider a simple thought experiment. Suppose we start with a sequence of 
if statements that begin simple and get more complicated:

if a == 1: ...

if a == 1 and b > 2*c: ...

if a == 1 and b > 2*c or d%4 == 1: ...

if a == 1 and b > 2*c or d%4 == 1 and not (d**3//7)%3 == 0: ...


I don't believe that any of these tests are improved by adding an 
extraneous "== True" at the end:

if (a == 1) == True: ...

if (a == 1 and b > 2*c) == True: ...

if (a == 1 and b > 2*c or d%4 == 1) == True: ...

if (a == 1 and b > 2*c or d%4 == 1 and not (d**3//7)%3 == 0) == True: ...

At some point your condition becomes so complicated that you may wish to 
save it as a separate variable, or perhaps you need to check the flag in 
a couple of places and so calculate it only once. Moving the flag out 
into a separate variable doesn't make "== True" any more useful or 
helpful.

flag = a == 1
if flag == True: ...


But even if it did, well, you've just entered the Twilight Zone, because 
of course "flag == True" is just a flag, so it too needs to be tested 
with "== True":

flag = (a == 1) == True
if flag == True: ...

but that too is just a flag so it needs more "explicitness"... and so on 
forever. This conclusion is of course nonsense. Adding "== True" to your 
boolean tests isn't helpful, so there's no need for even one, let alone 
an infinite series of "== True".

"if flag" is as explicit as it needs to be. There's no need to 
artificially inflate the "explicitness" as if being explicit was good in 
and of itself. We don't normally write code like this:

n += int(1)

just to be explicit about 1 being an int. That would be redundant and 
silly. In Python, 1 *is* an int.


[...]
>   if lst:
> 
> I don't like that because it's too implict. What exactly about the list
> are we wanting to test?

If you are unfamiliar with Python, then you have to learn what the 
semantics of "if lst" means. Just as you would have to learn what 
"if len(lst) > 0" means.


> I prefer to be explicit at the cost of a few keystrokes:
> 
>   if len(lst) > 0:

This line of code is problematic, for various reasons:

- you're making assumptions about the object which are unnecessary;

- which breaks duck-typing;

- and risks doing too much work, or failing altogether.

You're looking up the length of the lst object, but you don't really care 
about the length. You only care about whether there is something there or 
not, whether lst is empty or not. It makes no difference whether lst 
contains one item or one hundred million items, and yet you're asking to 
count them all. Only to throw that count away immediately!

Looking at the length of a built-in list is cheap, but why assume it is a 
built-in list? Perhaps it is a linked list where counting the items 
requires a slow O(N) traversal of the entire list. Or some kind of lazy 
sequence that has no way of counting the items remaining, but knows 
whether it is exhausted or not.

The Python way is to duck-type, and to let the lst object decide for 
itself whether it's empty or not:

if lst: ...


not to make assumptions about the specific type and performance of the 
object.


> Consider the following:
> 
>  What if the symbol `value` is expected to be a list, however, somehow
>  it accidentally got reassigned to another type. If i choose to be
>  implicit and use: "if value", the code could silently work for a type i
>  did not intend, therefore the program could go on for quite some time
>  before failing suddenly on attribute error, or whatever.

`if len(lst) > 0` also works for types you don't intend. Any type that 
defines a __len__ method which returns an integer will do it.

Tuples, sets and dicts are just the most obvious examples of things that 
support len() but do not necessarily support all the things you might 
wish to do to a list.



> However, if i choose to be explicit and use:
> 
>   "if len(VALUE) > 0:
> 
> then the code will fail when it should: at the comparison line.

Except of course when it doesn't.


> Because
> any object that does not provide a __len__ method would cause Python to
> raise NameError.

TypeError.



> By being "e

Re: PyWart: The problem with "print"

[Steven D'Aprano]

On Tue, 04 Jun 2013 05:16:13 +0200, Vito De Tullio wrote:

> Rick Johnson wrote:
> 
>> Take your
>> standard yes/no/cancel dialog, i would expect it to return
>> True|False|None respectively,
> 
> you clearly mean True / False / FileNotFound.
> 
> ( http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx )


No no, he actually means 

return True
return False
raise an exception


Or perhaps 

0
1
2

Or perhaps:

'yes'
'no'
'cancel'

like all right-thinking people expect *wink*

Of course the one thing that a programmer should never, ever do, under 
pain of maybe having to learn something, is actually check the 
documentation of an unfamiliar library or function before making 
assumptions of what it will return. If you follow this advice, you too 
can enjoy the benefits of writing buggy code.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Rick Johnson]

On Monday, June 3, 2013 10:16:13 PM UTC-5, Vito De Tullio wrote:
> Rick Johnson wrote:
> > Take your
> > standard yes/no/cancel dialog, i would expect it to return
> > True|False|None respectively,
> you clearly mean True / False / FileNotFound.

No, i clearly meant what i said :-). FileDialogs only return
one of two values; either a valid path or a value
representing "failure". I suppose FileNotFound is a custom
exception? That will work however i wonder if exception
handling is overkill for this?

  try:
  path = filedialog.open("path")
  except FileNotFound:
  return
  do_something(path)

As opposed to:

  path = filedialog.open("path")
  if path:
  do_something(path)

Or, if Python was really cool!

  if filedialog.open("path") as path:
  do_something(path)

However, i think True|False|None is the best return values
for a yes|no|cancel choice. Consider:

  result = yesnocancel("save changes?")
  if result:
  # Try to save changes and close.
  if self.fileSave():
  app.close()
  else:
  show_error()
  elif result is False:
  # Close without saving changes.
  app.close()
  else:
  # Canceled: Do nothing.
  return
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Vito De Tullio]

Rick Johnson wrote:

> Take your
> standard yes/no/cancel dialog, i would expect it to return
> True|False|None respectively,

you clearly mean True / False / FileNotFound.

( http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx )

-- 
ZeD

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Rick Johnson]

On Sunday, June 2, 2013 1:58:30 PM UTC-5, Steven D'Aprano wrote:
> On Sun, 02 Jun 2013 10:04:00 -0700, Rick Johnson wrote:

Oh Steven, you've really outdone yourself this time with the
theatrics. I hope you scored some "cool points" with your
minions. Heck, you almost had me convinced until i slapped
myself and realized your whole argument is just pure BS. For
the sake of the lemmings, i must dissect your BS and expose
it's methane emitting innards for all to smell.

> > Many
> > languages provide a function, method, or statement by which users can
> > write easily to stdout, and Python is no exception with it's own "print"
> > function. However, whilst writing to stdout via "print" is slightly less
> > verbose than calling the "write" method of "sys.stdout", we don't really
> > gain much from this function except a few keystrokes... is this ALL
> > print should be? A mere syntactical sugar?
>
> Perhaps you should read the docs before asking rhetorical questions,
> because the actual answer is, No, print is not mere syntactical sugar
> saving a few keystrokes.
> [...]

And perhaps you should read a dictionary and obtain (at
minimum) a primary school level education in English before
making such foolish statements, because, OBVIOUSLY you don't
know the definition of "syntactical sugar"... shall i
educate you?



#   Wikipedia: "syntactic sugar"   #

# In computer science, syntactic sugar is syntax within a  #
# programming language that is designed to make things #
# easier to read or to express. It makes the language  #
# "sweeter" for human use: things can be expressed more#
# clearly, more concisely, or in an alternative style that #
# some may prefer[...] #


The print function is the very definition of a "syntactic sugar".

For example:
print("some sting")

is much more readable than:

sys.stdout.write("some string"+"\n")

or:

sys.stderr.write("some string"+"\n")

or:

streamFoo.write("blah")

But wait, there's more!


# Wikipedia: "syntactic sugar" (continued) #

# [...]Specifically, a construct in a language is called   #
# syntactic sugar if it can be removed from the language   #
# without any effect on what the language can do:  #
# functionality and expressive power will remain the same. #


Again, the removal of a print function (or print statement)
will not prevent users from calling the write method on
sys.stdout or sys.stderr (or ANY "stream object" for that matter!)

The only mistake i made was to specify stdout.write
specifically instead of generally referring to the print
function as a sugar for "stream.write()".

> > I've found that many subtle bugs are caused by not limiting the inputs
> > to sane values (or types). And with Python's duct typing
> [...]
> > and implicit
> > casting to Boolean, you end up with all sorts of misleading things
> > happening! Maybe you're testing for truth values and get a string
> > instead; which screws everything up!!!
> Only if you're a lousy programmer who doesn't understand Python's truth
> model.

I understand the Python truth model quite well, i just don't
happen to like it. Implicit conversion to Boolean breaks the
law of "least astonishment".

Many times you'll get a result (or an input) that you expect
to be a Boolean, but instead is a string. A good example of
poor coding is "dialog box return values". Take your
standard yes/no/cancel dialog, i would expect it to return
True|False|None respectively, HOWEVER, some *idiot* decided
to return the strings 'yes'|'no'|'cancel'.

If you tried to "bool test" a string (In a properly designed
language that does NOT support implicit Boolean conversion)
you would get an error if you tried this:

  py> string = " "
  py> if string:
  ... do_something()
  ERROR: Cannot convert string to Boolean!

However, with Python's implicit conversion to Boolean, the
same conditional will ALWAYS be True: because any string
that is not the null string is True (as far as Python is
concerned). This is an example of Python devs breaking TWO
Zens at once:

 "explicit is better than implicit"
 "errors should NEVER pass silently"

And even though Python does not raise an error, it should!

> > A "wise programmer" may think he's solved the problem by writing a
> > function called "debugprint" that looks like this:
> > > def debugprint(*args):
> > if DEBUG == True:
> > print(*args)
> No no no, that's not how you do it. It should be:
> if DEBUG == True == True:
> Wait,

Re: PyWart: The problem with "print"

[Chris Angelico]

On Tue, Jun 4, 2013 at 6:31 AM, Steven D'Aprano
 wrote:
> ... quite frankly I have no sympathy for
> the view that CPU cycles are so precious that we mustn't waste them. If
> that were the case, Python is the wrong language.

CPU cycles *are* valuable still, though. The efficiency of your code
determines how well it scales - but we have to be talking 100tps vs
1000tps here. There needs to be a huge difference for it to be at all
significant.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Steven D'Aprano]

On Mon, 03 Jun 2013 15:09:48 -0400, Jason Swails wrote:

> But unlike RR, who suggests some elaborate interpreter-wide, ambiguous
> ignore-rule to squash out all of these functions, I'm simply suggesting
> that sometimes it's worth commenting-out debug print calls instead of
> 'just leaving them there because you won't notice the cost' :).

+1

Further to this idea, many command line apps have a "verbose" mode, where 
they print status messages as the app runs. Some of these include 
multiple levels, so you can tune just how many messages you get, commonly:

- critical messages only
- important or critical messages
- warnings, important or critical messages
- status, warnings, important or critical messages
- all of the above, plus debugging messages
- all of the above, plus even more debugging messages

Since this verbosity level is selectable at runtime, the code itself must 
include many, many calls to some equivalent to print, enough calls to 
print to cover the most verbose case, even though most of the time most 
such calls just return without printing.

This is a feature. And like all features, it has a cost. If (generic) 
your application does not benefit from verbose print statements scattered 
all throughout it, *don't put them in*. But if it will, then there is a 
certain amount of overhead to this feature. Deal with it, either by 
accepting the cost, or by writing more code that trades off complexity 
for efficiency. It's 2013, not 1975, and computers have more than 32K of 
RAM and the slowest CPU on the market is a million times faster than the 
ones that took us to the moon, and quite frankly I have no sympathy for 
the view that CPU cycles are so precious that we mustn't waste them. If 
that were the case, Python is the wrong language.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Jason Swails]

ack, sorry for the double-post.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Jason Swails]

On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly  wrote:

> On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails 
> wrote:
> > I'm actually with RR in terms of eliminating the overhead involved with
> > 'dead' function calls, since there are instances when optimizing in
> Python
> > is desirable.  I actually recently adjusted one of my own scripts to
> > eliminate branching and improve data layout to achieve a 1000-fold
> > improvement in efficiency (~45 minutes to 0.42 s. for one example) ---
> all
> > in pure Python.  The first approach was unacceptable, the second is fine.
> > For comparison, if I add a 'deactivated' debugprint call into the inner
> loop
> > (executed 243K times in this particular test), then the time of the
> > double-loop step that I optimized takes 0.73 seconds (nearly doubling the
> > duration of the whole step).
>
> It seems to me that your problem here wasn't that the time needed for
> the deactivated debugprint was too great. Your problem was that a
> debugprint that executes 243K times in 0.73 seconds is going to
> generate far too much output to be useful, and it had no business
> being there in the first place.  *Reasonably* placed debugprints are
> generally not going to be a significant time-sink for the application
> when disabled.


Well in 'debug' mode I wouldn't use an example that executed the loop 200K
times -- I'd find one that executed a manageable couple dozen, maybe.
 When 'disabled,' the print statement won't do anything except consume
clock cycles and potentially displace useful cache (the latter being the
more harmful, since most applications are bound by the memory bus).  It's
better to eliminate this dead call when you're not in 'debugging' mode.
 Admittedly such loops should be tight enough that debugging statements
inside the inner loop are generally unnecessary, but perhaps not always.

But unlike RR, who suggests some elaborate interpreter-wide, ambiguous
ignore-rule to squash out all of these functions, I'm simply suggesting
that sometimes it's worth commenting-out debug print calls instead of 'just
leaving them there because you won't notice the cost' :).

> The easiest way to eliminate these 'dead' calls is to simply comment-out
> the
> > print call, but I would be quite upset if the interpreter tried to
> outsmart
> > me and do it automagically as RR seems to be suggesting.
>
> Indeed, the print function is for general output, not specifically for
> debugging.  If you have the global print deactivation that RR is
> suggesting, then what you have is no longer a print function, but a
> misnamed debug function.
>

Exactly.  I was just trying to make the point that it is -occasionally-
worth spending the time to comment-out certain debug calls rather than
leaving 'dead' function calls in certain places.

All the best,
Jason
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Jason Swails]

On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly  wrote:

> On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails 
> wrote:
> > I'm actually with RR in terms of eliminating the overhead involved with
> > 'dead' function calls, since there are instances when optimizing in
> Python
> > is desirable.  I actually recently adjusted one of my own scripts to
> > eliminate branching and improve data layout to achieve a 1000-fold
> > improvement in efficiency (~45 minutes to 0.42 s. for one example) ---
> all
> > in pure Python.  The first approach was unacceptable, the second is fine.
> > For comparison, if I add a 'deactivated' debugprint call into the inner
> loop
> > (executed 243K times in this particular test), then the time of the
> > double-loop step that I optimized takes 0.73 seconds (nearly doubling the
> > duration of the whole step).
>
> It seems to me that your problem here wasn't that the time needed for
> the deactivated debugprint was too great. Your problem was that a
> debugprint that executes 243K times in 0.73 seconds is going to
> generate far too much output to be useful, and it had no business
> being there in the first place.  *Reasonably* placed debugprints are
> generally not going to be a significant time-sink for the application
> when disabled.


Well in 'debug' mode I wouldn't use an example that executed the loop 200K
times -- I'd find one that executed a manageable couple dozen, maybe.
 When 'disabled,' the print statement won't do anything except consume
clock cycles and potentially displace useful cache (the latter being the
more harmful, since most applications are bound by the memory bus).  It's
better to eliminate this dead call when you're not in 'debugging' mode.
 (When active, it certainly would've taken more than 0.73
seconds) Admittedly such loops should be tight enough that debugging
statements inside the inner loop are generally unnecessary, but perhaps not
always.

But unlike RR, who suggests some elaborate interpreter-wide, ambiguous
ignore-rule to squash out all of these functions, I'm simply suggesting
that sometimes it's worth commenting-out debug print calls instead of 'just
leaving them there because you won't notice the cost' :).

> The easiest way to eliminate these 'dead' calls is to simply comment-out
> the
> > print call, but I would be quite upset if the interpreter tried to
> outsmart
> > me and do it automagically as RR seems to be suggesting.
>
> Indeed, the print function is for general output, not specifically for
> debugging.  If you have the global print deactivation that RR is
> suggesting, then what you have is no longer a print function, but a
> misnamed debug function.
>

Exactly.  I was just trying to make the point that it is -occasionally-
worth spending the time to comment-out certain debug calls rather than
leaving 'dead' function calls in certain places.

All the best,
Jason

-- 
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Ian Kelly]

On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails  wrote:
> I'm actually with RR in terms of eliminating the overhead involved with
> 'dead' function calls, since there are instances when optimizing in Python
> is desirable.  I actually recently adjusted one of my own scripts to
> eliminate branching and improve data layout to achieve a 1000-fold
> improvement in efficiency (~45 minutes to 0.42 s. for one example) --- all
> in pure Python.  The first approach was unacceptable, the second is fine.
> For comparison, if I add a 'deactivated' debugprint call into the inner loop
> (executed 243K times in this particular test), then the time of the
> double-loop step that I optimized takes 0.73 seconds (nearly doubling the
> duration of the whole step).

It seems to me that your problem here wasn't that the time needed for
the deactivated debugprint was too great. Your problem was that a
debugprint that executes 243K times in 0.73 seconds is going to
generate far too much output to be useful, and it had no business
being there in the first place.  *Reasonably* placed debugprints are
generally not going to be a significant time-sink for the application
when disabled.

> The easiest way to eliminate these 'dead' calls is to simply comment-out the
> print call, but I would be quite upset if the interpreter tried to outsmart
> me and do it automagically as RR seems to be suggesting.

Indeed, the print function is for general output, not specifically for
debugging.  If you have the global print deactivation that RR is
suggesting, then what you have is no longer a print function, but a
misnamed debug function.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Dave Angel]

On 06/03/2013 04:49 AM, Mark Lawrence wrote:

On 03/06/2013 04:10, Dan Sommers wrote:

On Sun, 02 Jun 2013 20:16:21 -0400, Jason Swails wrote:


... If you don't believe me, you've never hit a bug that 'magically'
disappears when you add a debugging print statement ;-).


Ah, yes.  The Heisenbug.  ;-)

We used to run into those back in the days of C and assembly language.
They're much harder to see in the wild with Python.



Strikes me it's a bit like problems when prototyping circuit boards. The
card doesn't work, so you mount it on an extender card, problem goes
away, remove extender card, problem reappears.  Wash, rinse, repeat :)



That's when you use a little kappy-zapper spray.

--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Robert Kern]

On 2013-06-03 05:20, Dan Sommers wrote:

On Sun, 02 Jun 2013 23:23:42 -0400, Jason Swails wrote:



... (And yes, a good portion of our code is -still- in Fortran -- but
at least it's F90+ :).


I am a huge proponent of using the right tool for the job.  There is
nothing wrong with some well-placed FORTRAN, as long as the PSF


No, no. It's the PSU that you have to worrNO CARRIER

--
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Mark Lawrence]

On 03/06/2013 04:10, Dan Sommers wrote:

On Sun, 02 Jun 2013 20:16:21 -0400, Jason Swails wrote:


... If you don't believe me, you've never hit a bug that 'magically'
disappears when you add a debugging print statement ;-).


Ah, yes.  The Heisenbug.  ;-)

We used to run into those back in the days of C and assembly language.
They're much harder to see in the wild with Python.



Strikes me it's a bit like problems when prototyping circuit boards. 
The card doesn't work, so you mount it on an extender card, problem goes 
away, remove extender card, problem reappears.  Wash, rinse, repeat :)


--
"Steve is going for the pink ball - and for those of you who are 
watching in black and white, the pink is next to the green." Snooker 
commentator 'Whispering' Ted Lowe.


Mark Lawrence

--
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Alister]

On Mon, 03 Jun 2013 17:17:12 +1000, Chris Angelico wrote:

> On Mon, Jun 3, 2013 at 3:49 PM, Michael Torrie 
> wrote:
>> On 06/02/2013 12:18 PM, Rick Johnson wrote:
>>> On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote:
 On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote:
> On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson
 [...] Or use the logging module.  It's easy to get going quickly
 (just call logging.basicConfig at startup time), and with a little
 care and feeding, you can control the output in more ways than can
 fit into the margin. Oh, yeah, I'm sure it introduces some overhead. 
 So does everything else.
>>>
>>> I hate log files, at least during development or testing. I prefer to
>>> debug on the command line or using my IDE. Log files are for release
>>> time, not development.
>>
>> Except that it's not.  Have you even looked at what the logging module
>> is?  It most certainly can log to stderr if you provide no logging
>> handler to write to a file.
> 
> Plus, writing to a file actually makes a lot of sense for development
> too. It's far easier to run the program the same way in dev and release,
> which often means daemonized. I like to have Upstart manage all my
> services, for instance.
> 
> ChrisA

further point
the production logging code needs to be implemented and tested at 
development time anyway so why not make use of it instead of creating 
additional redundant code?



-- 
It is a lesson which all history teaches wise men, to put trust in ideas,
and not in circumstances.
-- Emerson
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Chris Angelico]

On Mon, Jun 3, 2013 at 3:49 PM, Michael Torrie  wrote:
> On 06/02/2013 12:18 PM, Rick Johnson wrote:
>> On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote:
>>> On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote:
 On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson
>>> [...] Or use the logging module.  It's easy to get going quickly
>>> (just call logging.basicConfig at startup time), and with a little
>>> care and feeding, you can control the output in more ways than can
>>> fit into the margin. Oh, yeah, I'm sure it introduces some
>>> overhead.  So does everything else.
>>
>> I hate log files, at least during development or testing. I prefer to
>> debug on the command line or using my IDE. Log files are for release
>> time, not development.
>
> Except that it's not.  Have you even looked at what the logging module
> is?  It most certainly can log to stderr if you provide no logging
> handler to write to a file.

Plus, writing to a file actually makes a lot of sense for development
too. It's far easier to run the program the same way in dev and
release, which often means daemonized. I like to have Upstart manage
all my services, for instance.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print")

[Devin Jeanpierre]

On Mon, Jun 3, 2013 at 12:34 AM, Dan Sommers  wrote:
> On Mon, 03 Jun 2013 13:37:27 +1000, Tim Delaney wrote:
>
>> With the increase in use of higher-level languages, these days
>> Heisenbugs most often appear with multithreaded code that doesn't
>> properly protect critical sections, but as you say, with lower-level
>> languages uninitialised memory is a common source of them.
>
> Aside from an I/O caching bug directly affected by calling print or
> somefile.write (where somefile is stdout), how else could I create a
> Heisenbug in pure Python?

The garbage collector can do this, but I think in practice it's
ridiculously rare, since __del__ is almost never useful due to its
unreliability*. The problem is that the garbage collector can do
whatever it wants. For example, in CPython it is called after so many
cycles have been created. This allows code and user actions to
inadvertently affect the garbage collector, and therefore, the
invocation of __del__.

If your __del__ does anything that accesses mutable global state also
used elsewhere, it's conceivable that the order of someone else's
access and __del__'s invocation depends on the GC. One order or the
other might be the wrong one which causes a failure. As it happens,
the "bt" command in pdb creates a cycle and might trigger the garbage
collector, causing __del__ to run immediately, and potentially hiding
the failure.

This isn't really "pure python" in that Python doesn't even guarantee
__del__ is ever called at all, let alone why. It's completely
implementation-specific, and not a property of Python the language.

-- Devin

.. [*] Some people use it as an "unreliable fallback"; this turns
their magical autosaving code into an attractive and yet horribly
dangerous nuisance. Friends don't let friends use __del__.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Michael Torrie]

On 06/02/2013 12:18 PM, Rick Johnson wrote:
> On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote:
>> On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote:
>>> On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson
>> [...] Or use the logging module.  It's easy to get going quickly 
>> (just call logging.basicConfig at startup time), and with a little
>> care and feeding, you can control the output in more ways than can
>> fit into the margin. Oh, yeah, I'm sure it introduces some
>> overhead.  So does everything else.
> 
> I hate log files, at least during development or testing. I prefer to
> debug on the command line or using my IDE. Log files are for release
> time, not development.

Except that it's not.  Have you even looked at what the logging module
is?  It most certainly can log to stderr if you provide no logging
handler to write to a file.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print")

[Chris Angelico]

On Mon, Jun 3, 2013 at 2:34 PM, Dan Sommers  wrote:
> On Mon, 03 Jun 2013 13:37:27 +1000, Tim Delaney wrote:
>
>> With the increase in use of higher-level languages, these days
>> Heisenbugs most often appear with multithreaded code that doesn't
>> properly protect critical sections, but as you say, with lower-level
>> languages uninitialised memory is a common source of them.
>
> Aside from an I/O caching bug directly affected by calling print or
> somefile.write (where somefile is stdout), how else could I create a
> Heisenbug in pure Python?

If you have a @property, merely retrieving it could affect things. It
shouldn't happen, but bugs can be anywhere. Basically, ANY Python code
can trigger ANY Python code.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Python Heisenbugs? (was: Re: PyWart: The problem with "print")

[Dan Sommers]

On Mon, 03 Jun 2013 13:37:27 +1000, Tim Delaney wrote:

> With the increase in use of higher-level languages, these days
> Heisenbugs most often appear with multithreaded code that doesn't
> properly protect critical sections, but as you say, with lower-level
> languages uninitialised memory is a common source of them.

Aside from an I/O caching bug directly affected by calling print or
somefile.write (where somefile is stdout), how else could I create a
Heisenbug in pure Python?

To bring this thread back around full circle:  I suppose that if I had a
local function called print, and decided that I needed some debugging
output, I could be in for a surprise; or a local module called logging,
and decided to use the logging module instead of calling print directly.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Dan Sommers]

On Sun, 02 Jun 2013 23:23:42 -0400, Jason Swails wrote:

> On Sun, Jun 2, 2013 at 11:10 PM, Dan Sommers 
> wrote:

>> Ah, yes.  The Heisenbug.  ;-)
> 
> Indeed.  Being in the field of computational chemistry/physics, I was
> almost happy to have found one just to say I was hunting a Heisenbug.
> It seems to be a term geared more toward the physics-oriented
> programming crowd.

I'd been using the word Heisenbug for years with only a pop-culture clue
as to what it meant.  Many years later, I went to college, studied
physics (and math), and had one self-study semester of computational
physics on my way to my undergraduate degree.  After a career in
software development, including a few years in the financial industry,
with lots of floating point economic models, I must say that it was very
enlightening.

>> They're much harder to see in the wild with Python.
> 
> Yea, I've only run into Heisenbugs with Fortran or C/C++.  Every time
> I've seen one it's been due to an uninitialized variable somewhere --
> something valgrind is quite good at pinpointing ...

Uninitialized variables and off-by-one pointer operations.  Little can
screw up a calculation like mistaking a stack frame link for a floating
point number.  :-)

> ... (And yes, a good portion of our code is -still- in Fortran -- but
> at least it's F90+ :).

I am a huge proponent of using the right tool for the job.  There is
nothing wrong with some well-placed FORTRAN, as long as the PSF
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Tim Delaney]

On 3 June 2013 13:23, Jason Swails  wrote:

> Yea, I've only run into Heisenbugs with Fortran or C/C++.  Every time I've
> seen one it's been due to an uninitialized variable somewhere -- something
> valgrind is quite good at pinpointing.  (And yes, a good portion of our
> code is -still- in Fortran -- but at least it's F90+ :).
>

With the increase in use of higher-level languages, these days Heisenbugs
most often appear with multithreaded code that doesn't properly protect
critical sections, but as you say, with lower-level languages uninitialised
memory is a common source of them.

I had a fun one once (in C++, but could have happened in any language)
where a semaphore was being acquired twice on the one thread. There were 10
semaphore slots available, and very occasionally the timings would result
in one of the threads deadlocking. Fortunately, by reducing to a single
thread + single semaphore slot I was able to turn it from a Heisenbug to a
100% replicable bug.

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Jason Swails]

On Sun, Jun 2, 2013 at 11:10 PM, Dan Sommers  wrote:

> On Sun, 02 Jun 2013 20:16:21 -0400, Jason Swails wrote:
>
> > ... If you don't believe me, you've never hit a bug that 'magically'
> > disappears when you add a debugging print statement ;-).
>
> Ah, yes.  The Heisenbug.  ;-)
>

Indeed.  Being in the field of computational chemistry/physics, I was
almost happy to have found one just to say I was hunting a Heisenbug.  It
seems to be a term geared more toward the physics-oriented programming
crowd.


> We used to run into those back in the days of C and assembly langua
> 
> ge.
> 
> They're much harder to see in the wild with Python.
> 
>

Yea, I've only run into Heisenbugs with Fortran or C/C++.  Every time I've
seen one it's been due to an uninitialized variable somewhere -- something
valgrind is quite good at pinpointing.  (And yes, a good portion of our
code is -still- in Fortran -- but at least it's F90+ :).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Dan Sommers]

On Sun, 02 Jun 2013 20:16:21 -0400, Jason Swails wrote:

> ... If you don't believe me, you've never hit a bug that 'magically'
> disappears when you add a debugging print statement ;-).

Ah, yes.  The Heisenbug.  ;-)

We used to run into those back in the days of C and assembly language.
They're much harder to see in the wild with Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Chris Angelico]

On Mon, Jun 3, 2013 at 10:16 AM, Jason Swails  wrote:
> Copy-and-pasting your timeit experiment on my machine yields different
> timings (Python 2.7):
>
 import sys
 timeit.timeit('debugprint("asdf")','def debugprint(*args):\n\tif not
 DEBUG: return\n\tsys.stdout.write(*args)\nDEBUG=False',number=100)
> 0.15644001960754395
>
> which is ~150 ns/function call, versus ~1300 ns/function call.  And there
> may be even more extreme examples, this is just one I was able to cook up
> quickly.

The exact time will of course vary enormously. My point still would
stand at 1300ns; it's still extremely low compared to many other
overheads.

> This is, I'm sad to say, where my alignment with RR ends.  While I use
> prints in debugging all the time, it can also become a 'crutch', just like
> reliance on valgrind or gdb.  If you don't believe me, you've never hit a
> bug that 'magically' disappears when you add a debugging print statement
> ;-).

Yes, I've had situations like that. They are, however, EXTREMELY rare
compared to the times when a bug magically becomes shallow when you
add a debugging print!

> The easiest way to eliminate these 'dead' calls is to simply comment-out the
> print call, but I would be quite upset if the interpreter tried to outsmart
> me and do it automagically as RR seems to be suggesting.  And if you're
> actually debugging, then you typically only add a few targeted print
> statements -- not too hard to comment-out.  If it is, and you're really that
> lazy, then by all means add a new, greppable function call and use a sed
> command to comment those lines out for you.

Yes. I also have high hopes for some of the cool AST manipulation
that's being developed at the moment; it should be relatively easy to
have a simple flag that controls whether debugprint (btw, I'd shorten
the name) represents code or no-code.

But consider all the other things that you probably do in your Python
programs. Every time you reference something as "module.name", you
require a lookup into the current module's  namespace to find the
module name, then into that module's namespace to find the object you
want. Snagging names as locals is a common optimization, but is far
from universally applied. Why? Because the readability cost just isn't
worth it. We use Python because it is "fast enough", not because it
lets us squeeze every CPU cycle out of the code.

That said, I can often smoke Python with Pike, thanks to a few rather
cool optimizations (including looking up module names at compile time,
which reduces what I just said above). Maybe in the future some of
these optimizations will be done, I don't know. But for 99.9% of
Python scripts, you will *never* see the performance difference.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Jason Swails]

On Sun, Jun 2, 2013 at 1:20 PM, Chris Angelico  wrote:

>
> Hmm. Could be costly. Hey, you know, Python has something for testing that.
>
> >>> timeit.timeit('debugprint("asdf")','def debugprint(*args):\n\tif not
> DEBUG: return\n\tprint(*args)\nDEBUG=False',number=100)
> 0.5838018519113444
>
> That's roughly half a second for a million calls to debugprint().
> That's a 580ns cost per call. Rather than fiddle with the language,
> I'd rather just take this cost. Oh, and there's another way, too: If
> you make the DEBUG flag have effect only on startup, you could write
> your module thus:
>

This is a slightly contrived demonstration... The time lost in a function
call is not just the time it takes to execute that function.  If it
consistently increases the frequency of cache misses then the cost is much
greater -- possibly by orders of magnitude if the application is truly
bound by the bandwidth of the memory bus and the CPU pipeline is almost
always saturated.

I'm actually with RR in terms of eliminating the overhead involved with
'dead' function calls, since there are instances when optimizing in Python
is desirable.  I actually recently adjusted one of my own scripts to
eliminate branching and improve data layout to achieve a 1000-fold
improvement in efficiency (~45 minutes to 0.42 s. for one example) --- all
in pure Python.  The first approach was unacceptable, the second is fine.
 For comparison, if I add a 'deactivated' debugprint call into the inner
loop (executed 243K times in this particular test), then the time of the
double-loop step that I optimized takes 0.73 seconds (nearly doubling the
duration of the whole step).  The whole program is too large to post here,
but the relevant code portion is shown below:

 i = 0
 begin = time.time()
 for mol in owner:
for atm in mol:
   blankfunc("Print i %d" % i)
   new_atoms[i] = self.atom_list[atm]
   i += 1
 self.atom_list = new_atoms
 print "Done in %f seconds." % (time.time() - begin)

from another module:

DEBUG = False

[snip]

def blankfunc(instring):
   if DEBUG:
  print instring

Also, you're often not passing a constant literal to the debug print --
you're doing some type of string formatting or substitution if you're
really inspecting the value of a particular variable, and this also takes
time.  In the test I gave the timings for above, I passed a string the
counter substituted to the 'dead' debug function.  Copy-and-pasting your
timeit experiment on my machine yields different timings (Python 2.7):

>>> import sys
>>> timeit.timeit('debugprint("asdf")','def debugprint(*args):\n\tif not
DEBUG: return\n\tsys.stdout.write(*args)\nDEBUG=False',number=100)
0.15644001960754395

which is ~150 ns/function call, versus ~1300 ns/function call.  And there
may be even more extreme examples, this is just one I was able to cook up
quickly.

This is, I'm sad to say, where my alignment with RR ends.  While I use
prints in debugging all the time, it can also become a 'crutch', just like
reliance on valgrind or gdb.  If you don't believe me, you've never hit a
bug that 'magically' disappears when you add a debugging print statement
;-).

The easiest way to eliminate these 'dead' calls is to simply comment-out
the print call, but I would be quite upset if the interpreter tried to
outsmart me and do it automagically as RR seems to be suggesting.  And if
you're actually debugging, then you typically only add a few targeted print
statements -- not too hard to comment-out.  If it is, and you're really
that lazy, then by all means add a new, greppable function call and use a
sed command to comment those lines out for you.

BTW: *you* in the above message refers to a generic person -- none of my
comments were aimed at anybody in particular

All the best,
Jason

P.S. All that said, I would agree with ChrisA's suggestion that the
overhead is negligible is most cases...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyWart: The problem with "print"

[Ned Batchelder]

On 6/2/2013 2:18 PM, Rick Johnson wrote:

On Sunday, June 2, 2013 12:49:02 PM UTC-5, Dan Sommers wrote:

On Mon, 03 Jun 2013 03:20:52 +1000, Chris Angelico wrote:

On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson

[...]
Or use the logging module.  It's easy to get going quickly
(just call logging.basicConfig at startup time), and with
a little care and feeding, you can control the output in
more ways than can fit into the margin. Oh, yeah, I'm sure
it introduces some overhead.  So does everything else.

I hate log files, at least during development or testing. I prefer to debug on 
the command line or using my IDE. Log files are for release time, not 
development.

Rick, you should give the logging module a try.  The default 
configuration from basicConfig is that the messages all go to stderr, so 
no log files to deal with.  And it's configurable in the ways you want, 
plus a lot more.


--Ned.


--
http://mail.python.org/mailman/listinfo/python-list