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 wh
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
> >
> 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,
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({}
>> 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') #
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 correct
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 re
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
understandin
>> 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). Bu
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
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
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 conversa
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 wi
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
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 experienc
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,
> 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 la
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 asymptotic
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
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
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
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 traditi
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 n
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 tha
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 bu
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
>
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 clo
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 segf
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(
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
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:
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…
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
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 v
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 ar
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 wan
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 con
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 neve
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++
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
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 loo
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
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 a
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
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
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?
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 applicati
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 tha
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.
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 des
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
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 langu
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
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 do
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
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
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'
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
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
>
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
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
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
> type
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
consist
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 va
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
> > rea
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
> name
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 >
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
68 matches
Mail list logo
