Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
...
> > >>> class A(object):
note that A is new-style...
> >>> class x:
...while x is old-style.
Here's a small script to explore the problem...:
import sys
class oldstyle:
def __getitem__(self, index): print index,
class newstyle(object,
On Sun, 03 Sep 2006 16:29:11 +0200, Bruno Desthuilliers <[EMAIL PROTECTED]>
wrote:
>Paul Rubin a écrit :
>> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>>
>>>I've rarely encoutered "silent" data corruption with Python - FWIW, I
>>>once had such a problem, but with a lower-level statically type
Paul Rubin a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>
>>I've rarely encoutered "silent" data corruption with Python - FWIW, I
>>once had such a problem, but with a lower-level statically typed
>>language (integer overflow), and I was a very newbie programmer by that
>>time. Usua
Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> I've rarely encoutered "silent" data corruption with Python - FWIW, I
> once had such a problem, but with a lower-level statically typed
> language (integer overflow), and I was a very newbie programmer by that
> time. Usually, one *very quickly* no
> Oh, I was just addressing your bit about not knowing unit tests.
> Doctests can be quicker to put together and have only a small learning
> curve.
OK, I see what you mean. And you're right. I'm struggling mightily right
now with trying to come up with sane unit tests for a bunch of
generalized
Joel Hedlund wrote:
> > You might try doctests, they can be easier to write and fit into the
> > unit test framework if needed.
>
> While I firmly believe in keeping docs up to date, I don't think that
> doctests alone can solve the problem of maintaining data integrity in
> projects with more com
> You might try doctests, they can be easier to write and fit into the
> unit test framework if needed.
While I firmly believe in keeping docs up to date, I don't think that
doctests alone can solve the problem of maintaining data integrity in
projects with more comlex interfaces (which is what
Joel Hedlund wrote:
>
> Hmmm... So. I should build grimly paranoid parsers for external data, use
> duck-typed interfaces everywhere on the inside, and simply callously
> disregard developers who are disinclined to read documentation? I could do
> that.
>
> > if you're really serious, unit tests
Joel Hedlund wrote:
>> I still wait for a
>> proof that it leads to more robust programs - FWIW, MVHO is that it
>> usually leads to more complex - hence potentially less robust - code.
>
> MVHO? I assume you are not talking about Miami Valley Housing
> Opportunities here,
Nope --> My Very Humbl
> I still wait for a
> proof that it leads to more robust programs - FWIW, MVHO is that it
> usually leads to more complex - hence potentially less robust - code.
MVHO? I assume you are not talking about Miami Valley Housing Opportunities
here, but bloat probably leads to bugs, yes.
> Talking ab
Joel Hedlund wrote:
>> I'm not sure that trying to fight against the language is a sound
>> approach, whatever the language.
>
> That's the very reason I posted in the first place. I feel like I'm
> fighting the language, and since python at least to me seems to be so
> well thought out in all ot
> I'm not sure that trying to fight against the language is a sound
> approach, whatever the language.
That's the very reason I posted in the first place. I feel like I'm fighting
the language, and since python at least to me seems to be so well thought
out in all other aspects, the most obviou
> And while we're at it : please avoid top-posting.
Yes, that was sloppy. Sorry.
/Joel
--
http://mail.python.org/mailman/listinfo/python-list
Joel Hedlund wrote:
> Bruno >> Your email address seem to be wrong.
let's say "disguised" !-)
> I tried to reply to you
> directly in order to avoid thread bloat but my mail bounced.
I don't think it's a good idea anyway - this thread is on topic here and
may be of interest to others too IMHO
Joel Hedlund wrote:
>> Short answer: Use Traits. Don't invent your own mini-Traits.
>
> Thanks for a quick and informative answer! I'll be sure to read up on
> the subject. (And also: thanks Bruno for your contributions!)
>
>> Types are very frequently exactly the wrong thing you want to check fo
Bruno >> Your email address seem to be wrong. I tried to reply to you
directly in order to avoid thread bloat but my mail bounced.
Thanks for the quick reply though. I've skimmed through some docs on your
suggestions and I'll be sure to read up on them properly later. But as I
said to Robert Ke
> Short answer: Use Traits. Don't invent your own mini-Traits.
Thanks for a quick and informative answer! I'll be sure to read up on the
subject. (And also: thanks Bruno for your contributions!)
> Types are very frequently exactly the wrong thing you want to check for.
I see what you mean. Al
Joel Hedlund a écrit :
> Hi!
>
> The question of type checking/enforcing has bothered me for a while,
(snip)
>
> I've also whipped up some examples in order to put the above questions
> in context and for your amusement. :-)
(snip)
> These are the attached modules:
>
> * nocheck_module.py:
>
Joel Hedlund wrote:
> Hi!
>
> The question of type checking/enforcing has bothered me for a while, and
> since this newsgroup has a wealth of competence subscribed to it, I
> figured this would be a great way of learning from the experts. I feel
> there's a tradeoff between clear, easily readda
Hi!
The question of type checking/enforcing has bothered me for a while, and
since this newsgroup has a wealth of competence subscribed to it, I
figured this would be a great way of learning from the experts. I feel
there's a tradeoff between clear, easily readdable and extensible code
on one
20 matches
Mail list logo
