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

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

PyWart: The problem with "print"

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

Contents

  PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-02 10:04 -0700
    Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 03:20 +1000
      Re: PyWart: The problem with "print" Dan Sommers <dan@tombstonezero.net> - 2013-06-02 17:49 +0000
        Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-02 11:18 -0700
          Re: PyWart: The problem with "print" Ned Batchelder <ned@nedbatchelder.com> - 2013-06-02 16:45 -0400
          Re: PyWart: The problem with "print" Michael Torrie <torriem@gmail.com> - 2013-06-02 23:49 -0600
          Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 17:17 +1000
            Re: PyWart: The problem with "print" Alister <alister.ware@ntlworld.com> - 2013-06-03 08:01 +0000
      Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-02 11:09 -0700
        Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-02 19:03 +0000
        Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 06:21 +1000
        Re: PyWart: The problem with "print" jmfauth <wxjmfauth@gmail.com> - 2013-06-04 05:23 -0700
          Re: PyWart: The problem with "print" rusi <rustompmody@gmail.com> - 2013-06-04 06:29 -0700
            Re: PyWart: The problem with "print" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-04 14:35 +0100
          Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-05 05:03 +0000
    Re: PyWart: The problem with "print" Andrew Berg <robotsondrugs@gmail.com> - 2013-06-02 12:30 -0500
    Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 03:34 +1000
    Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-02 18:58 +0000
      Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 06:28 +1000
      Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-03 18:37 -0700
        Re: PyWart: The problem with "print" Vito De Tullio <vito.detullio@gmail.com> - 2013-06-04 05:16 +0200
          Re: PyWart: The problem with "print" Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-03 20:53 -0700
          Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-04 04:30 +0000
        Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-04 05:39 +0000
          Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 08:44 -0700
            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-05 02:00 +1000
              Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 09:19 -0700
                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-05 02:27 +1000
                  Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-05 05:28 +0000
                    Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-04 22:31 -0700
                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Ned Batchelder <ned@nedbatchelder.com> - 2013-06-04 13:25 -0400
            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 09:09 -0700
              Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-04 18:31 -0700
            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Fábio Santos <fabiosantosart@gmail.com> - 2013-06-04 17:10 +0100
            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Jason Swails <jason.swails@gmail.com> - 2013-06-04 13:32 -0400
            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-04 11:42 -0600
              Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-04 16:21 -0700
                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-05 00:37 +0100
                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Michael Torrie <torriem@gmail.com> - 2013-06-04 23:28 -0600
            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-04 23:11 -0700
              Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-05 17:15 +1000
                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 00:47 -0700
                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 09:49 -0700
                  Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 02:59 +1000
                  Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Dan Stromberg <drsalists@gmail.com> - 2013-06-06 18:26 -0700
              Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-05 09:59 +0100
                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 09:15 -0700
                  Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 02:59 +1000
                    Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 14:59 -0700
                      Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-06 01:56 +0000
                        Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 12:29 +1000
                          Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 21:25 -0700
                            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-06 00:06 -0600
                          Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-06 09:29 +0000
                            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 19:45 +1000
                            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Serhiy Storchaka <storchaka@gmail.com> - 2013-06-06 14:12 +0300
                            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Robert Kern <robert.kern@gmail.com> - 2013-06-06 16:35 +0100
                            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 01:41 +1000
                            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Robert Kern <robert.kern@gmail.com> - 2013-06-06 17:08 +0100
                              Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 10:27 -0700
                                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-06-06 14:44 -0400
                            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 10:59 -0700
                              Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-06 17:53 -0700
                                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 18:44 -0700
                                  Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-06 19:03 -0700
                                    Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 22:01 -0700
                                  Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-07 02:29 +0000
                                    Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 20:14 -0700
                                      Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 20:24 -0700
                                        Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Mark Janssen <dreamingforward@gmail.com> - 2013-06-06 20:30 -0700
                                        Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 20:43 -0700
                            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-06 11:08 -0700
                    Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 08:49 -0700
                      Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 02:00 +1000
                        Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Grant Edwards <invalid@invalid.invalid> - 2013-06-06 17:32 +0000
                  Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-06 01:37 +0000
                    Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-06 11:45 +1000
                      Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 07:09 -0700
                        Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 01:26 +1000
                          Re: Bools and explicitness [was Re: PyWart: The problem with "print"] rusi <rustompmody@gmail.com> - 2013-06-06 08:36 -0700
                            Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Chris Angelico <rosuav@gmail.com> - 2013-06-07 01:46 +1000
                    Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 11:03 -0700
                      Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 11:11 -0700
              Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Terry Jan Reedy <tjreedy@udel.edu> - 2013-06-05 12:10 -0400
              Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Michael Torrie <torriem@gmail.com> - 2013-06-05 17:18 -0600
                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] "Russ P." <Russ.Paielli@gmail.com> - 2013-06-05 16:52 -0700
                  Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Michael Torrie <torriem@gmail.com> - 2013-06-05 19:20 -0600
                Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-06 09:24 -0700
                  Re: Bools and explicitness [was Re: PyWart: The problem with "print"] Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-06-06 12:39 -0400
                    Re: Bools and explicitness [was Re: PyWart: The problem with "print"] alex23 <wuwei23@gmail.com> - 2013-06-06 17:55 -0700
        Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-04 17:30 +1000
    Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-02 20:16 -0400
      Re: PyWart: The problem with "print" Dan Sommers <dan@tombstonezero.net> - 2013-06-03 03:10 +0000
        Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-02 23:23 -0400
          Re: PyWart: The problem with "print" Dan Sommers <dan@tombstonezero.net> - 2013-06-03 04:20 +0000
            Re: PyWart: The problem with "print" Robert Kern <robert.kern@gmail.com> - 2013-06-03 11:52 +0100
        Re: PyWart: The problem with "print" Tim Delaney <timothy.c.delaney@gmail.com> - 2013-06-03 13:37 +1000
          Python Heisenbugs?  (was: Re: PyWart: The problem with "print") Dan Sommers <dan@tombstonezero.net> - 2013-06-03 04:34 +0000
            Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print") Chris Angelico <rosuav@gmail.com> - 2013-06-03 15:05 +1000
            Re: Python Heisenbugs? (was: Re: PyWart: The problem with "print") Devin Jeanpierre <jeanpierreda@gmail.com> - 2013-06-03 03:06 -0400
        Re: PyWart: The problem with "print" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-03 09:49 +0100
        Re: PyWart: The problem with "print" Dave Angel <davea@davea.name> - 2013-06-03 08:56 -0400
    Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-03 12:02 +1000
    Re: PyWart: The problem with "print" Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-03 11:12 -0600
    Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-03 15:09 -0400
      Re: PyWart: The problem with "print" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-03 20:31 +0000
        Re: PyWart: The problem with "print" Chris Angelico <rosuav@gmail.com> - 2013-06-04 06:44 +1000
    Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-03 15:10 -0400
    Re: PyWart: The problem with "print" Jason Swails <jason.swails@gmail.com> - 2013-06-03 15:11 -0400

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

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

Super OT divergence because I am a loser nerd:

On Thu, Jun 6, 2013 at 1:27 PM, rusi <rustompmody@gmail.com> 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

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

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

> 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://c2.com/cgi/wiki?WikiWikiWeb>

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

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

On Jun 7, 3:59 am, Mark Janssen <dreamingforw...@gmail.com> 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.

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

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

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

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

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

On Jun 7, 11:44 am, Mark Janssen <dreamingforw...@gmail.com> 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.

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

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

On 6/6/13, alex23 <wuwei23@gmail.com> wrote:
> On Jun 7, 11:44 am, Mark Janssen <dreamingforw...@gmail.com> 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

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

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

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

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

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

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

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

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

On Jun 7, 8:14 am, Mark Janssen <dreamingforw...@gmail.com> 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

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

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

> 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

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

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

On Jun 7, 8:24 am, rusi <rustompm...@gmail.com> wrote:
> On Jun 7, 8:14 am, Mark Janssen <dreamingforw...@gmail.com> 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)

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

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

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
> 
> > <steve+comp.lang.python@pearwood.info> 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-)

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

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

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?

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

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

On Fri, Jun 7, 2013 at 1:49 AM, Rick Johnson
<rantingrickjohnson@gmail.com> 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

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

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

On 2013-06-06, Chris Angelico <rosuav@gmail.com> 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.edwards        Yow! I just went below the
                                  at               poverty line!
                              gmail.com            

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

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

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

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

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

On Thu, Jun 6, 2013 at 11:37 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> What prevents bugs is the skill of the people writing the code, not the
> compiler.

+1 QOTW.

ChrisA

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

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

On Jun 6, 6:45 am, Chris Angelico <ros...@gmail.com> wrote:
> On Thu, Jun 6, 2013 at 11:37 AM, Steven D'Aprano
>
> <steve+comp.lang.pyt...@pearwood.info> 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… <wink>

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

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

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

On Fri, Jun 7, 2013 at 12:09 AM, rusi <rustompmody@gmail.com> 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(999999999)
def foo(): foo()
foo()

:)

ChrisA

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

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

On Jun 6, 8:26 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Jun 7, 2013 at 12:09 AM, rusi <rustompm...@gmail.com> 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(999999999)
> def foo(): foo()
> foo()
>
> :)
>
> ChrisA

And so you are hereby anointed into the august company of RR!!

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

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

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

csiph-web