Python 2.4c1 vs. 2.4

[Russ]

My sysadmin recently installed 2.4c1 on our network. Should we now
install 2.4, or is it the same as 2.4c1? Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

parameter files

[Russ]

I have a python module (file) that has a set of parameters associated
with it. Let's say the module is called "code.py." I would like to keep
the parameter assignments in a separate file so that I can save a copy
for each "run" without having to save the entire code.py file. Let's
say the parameter file is called "parameters.py."

Normally, code.py would simply import the parameters.py file. However,
I don't want the parameters to be accessible to any other file that
imports the code.py file. to prevent such access, I preface the name of
each parameter with an underscore. But then the parameters aren't even
visible in code.py! So I decided to use "execfile" instead of import so
the parameters are visible.

That solved the problem, but I am just wondering if there is a better
and/or more standard way to handle a situation like this. Any
suggestions? Thanks.

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

Re: parameter files

[Russ]

> I would try a configuration file, instead of a python module.
> See ConfigParser:
> .
> You can save values for each "run" in a separate [section].
> Execfile is a pretty big hammer for this.

Hey, that looks interesting, but those docs don't do it for me. Can you
point me to some more extensive examples of how to use ConfigParser?
Thanks.

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

Re: parameter files

[Russ]

Thanks for the examples.

I don't think you understood what I meant by a "run." All I meant is
that I want to save the configuration, for reference purposes, that was
used for a particular run. That way I can reproduce the results if
necessary, and I can avoid confusion about which parameters were used
to get particular results.

I don't need a section for each run. I only need one set of parameters.
I suppose I could use the sections for different modules or classes,
each of which needs its own parameters.


Gabriel Genellina wrote:
> At Thursday 14/9/2006 01:10, Russ wrote:
>
> > > I would try a configuration file, instead of a python module.
> > > See ConfigParser:
> > > <http://docs.python.org/lib/module-ConfigParser.html>.
> > > You can save values for each "run" in a separate [section].
> > > Execfile is a pretty big hammer for this.
> >
> >Hey, that looks interesting, but those docs don't do it for me. Can you
> >point me to some more extensive examples of how to use ConfigParser?
>
> Just forget about interpolation and such; declare a section for each
> run in your config file:
>
> [run_name_one]
> a=123
> b=Test
> c=4.0
>
> [run_two]
> a=456
> b=Whatever
> c=0.1
>
> config = ConfigParser.ConfigParser()
> config.read(filename)
> a = config.getint('run_two','a') # a==456
> b = config.get('run_name_one','b') # b=='Test'
> section = 'run_two'
> c = config.getfloat(section,'c') # c==0.1
>
>
> Gabriel Genellina
> Softlab SRL
>
>
>
>
>
> __
> Preguntá. Respondé. Descubrí.
> Todo lo que querías saber, y lo que ni imaginabas,
> está en Yahoo! Respuestas (Beta).
> ¡Probalo ya! 
> http://www.yahoo.com.ar/respuestas

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

Why not just show the out-of-range index?

[Russ]

Every Python programmer gets this message occasionally:

IndexError: list index out of range

The message tells you where the error occurred, but it doesn't tell you
what the range and the offending index are. Why does it force you to
determine that information for yourself when it could save you a step
and just tell you? This seems like a "no-brainer" to me. Am I missing
something?

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

Re: Why not just show the out-of-range index?

[Russ]

> Rather, they (like I) will encourage to OP to submit a patch that fixes the 
> problem.

Now, that would be rather silly. I would have to familiarize myself
with the code for the Python interpreter, then send a patch to the
maintainers (and hope they notice it in their inboxes), while the
maintainers themselves could probably "fix" the problem in two minutes
flat. No thanks!

My suggestion is trivial to implement and would benefit every Python
programmer (even if only slightly), so I don't think it is too much to
ask for.

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

Re: Why not just show the out-of-range index?

[Russ]

Jean-Paul Calderone wrote:

> And I have some laundry that I would like you to do for me.  Let me know
> when a convenient time for you to pick it up would be.

What that has to do with this thread escapes me, but since you
apparently have nothing better to do than track down information that
should have been provided to you, it's no wonder you don't have enough
time to do your own laundry.

When you call information to get a phone number, do you first ask if
they have the number, then call back a second time to get it if the
answer is yes?

If a policemen gives you a speeding ticket, do you expect him to tell
you how fast he thinks you were going, or are you content to wait for
the court date?

Get your mother to do your laundry -- after she dresses you in the
morning.

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

Re: Why not just show the out-of-range index?

[Russ]

John Machin wrote:

> Perhaps a better analogy is that the OP has observed (correctly IMHO)
> that the robes of *all* Pythonistas, including those not yet born and
> those not yet converted from heathen languages, could be whiter than
> what they are. There are others whose capability to implement an
> enhancement is likely to be much greater than his.

I love Python, but every time I get an out-of-range error message, I
wonder why it didn't just tell me what the out-of-range index was and
what the allowable range was. Certainly that information must be
available to the exception handler, or how would it know that it is out
of range? And no, it's not a big deal, maybe it's even trivial, but
after about the 100th time I finally decided to suggest that it be
fixed. I started with comp.lang.python because I had no idea whether
this issue had been dealt with already, but I am certainly willing to
file a feature request if necessary.

> Would the following be acceptable, BTW?
>
> | >>> [4, 5, 6][10]
> | IndexError: list index 10 out of range(3)
> | >>> [4, 5, 6][-4]
> | IndexError: list index -4 out of range(3)

That seems fine to me.

> Footnote: Based on 2.4.3 source, quite a few files, many with multiple
> lines to patch:

Holy cow! I can't believe that many changes would be necessary unless
the IndexError exception is scattered all over the place. I would hope
that one well-placed change could fix the bulk of cases.

Oh, and thanks for bringing your attention to this matter. This is one
of those little issues that comes up so often that I think fixing it
could make a significant difference in the overall efficiency of Python
programming.

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

Re: Why not just show the out-of-range index?

[Russ]

Dennis Lee Bieber wrote:

>   OTOH: IndexError is something I seldom see -- most Python statements
> are intelligent enough to not need ad hoc indexing. About the only type
> that I've seen is just an, almost obvious, off-by-one problem...
>
>   for i in xrange(len(a)):
>   a[i] = a[i] + a[i+1]
>
> in which knowing the discrete values isn't that significant (to me, at
> least)
>
>   It doesn't occur in things like
>
>   for itm in a:

I agree that implicit indexing (your latter construct) is preferable to
explicit indexing if the index is not needed for any other purpose. But
sometimes the index itself is needed for some computation. And
sometimes a list is "randomly" accessed without a loop at all.

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

Re: Why not just show the out-of-range index?

[Russ]

Fredrik Lundh wrote:
> Russ wrote:
>
> > Holy cow! I can't believe that many changes would be necessary unless
> > the IndexError exception is scattered all over the place. I would hope
> > that one well-placed change could fix the bulk of cases.
>
> when you write x[i], the interpreter makes no assumptions about x and i
> and len(x); it just calls the corresponding method (__getitem__), either
> directly, or via a C-level internal slot.
>
> there's no way to generate the error message you want in a single place
> without changing the semantics of x[i].

Then how about just changing __getitem__ for the built-in list type.
Wouldn't that take care of the vast majority of cases? Let anyone who
writes their own __getitem__ handle it themselves if they wish. I'm
just asking. I don't claim to know anything about the internals of the
Python interpreter.

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

Re: Why not just show the out-of-range index?

[Russ]

Robert Kern wrote:

> No one is castigating the OP for bringing up the issue. His suggestion that 
> his
> time is worth more than that of anyone else, though, is drawing some ire.

I'm afraid that any such "suggestion" is purely in your own
imagination. My time? Do you think I am the only one who has
IndexErrors?

> Fortunately, he seems to have backed off this position and seems amenable to
> doing something more productive than posting here.

I made a simple suggestion to enhance the convenience and productivity
of Python, and I was attacked for even discussing it rather than
immediately doing it myself. WTF?

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

Re: Why not just show the out-of-range index?

[Russ]

Fredrik Lundh wrote:
> Russ wrote:
>
> >> No one is castigating the OP for bringing up the issue. His suggestion 
> >> that his
> >> time is worth more than that of anyone else, though, is drawing some ire.
> >
> > I'm afraid that any such "suggestion" is purely in your own
> > imagination.
>
>"Now, that would be rather silly. I would have to familiarize myself
>with the code for the Python interpreter, then send a patch to the
>maintainers (and hope they notice it in their inboxes), while the
>maintainers themselves could probably "fix" the problem in two minutes
>flat. No thanks!"

That is a perfectly reasonable statement. Forgive me if I
underestimated the difficulty of implementing the feature I suggested,
but I still don't think it would be difficult for the code maintainers
to implement. They are obviously familiar with the code, but I'm not!

> and a couple of other posts with a similar tone.  open source developers
> tend to ignore people who use the "you're just a bunch of code monkeys"
> intimidation approach, especially when combined with an undertone of
> "what I'm proposing should be easy, and if it isn't, that's because
> you're incompetent".  claiming to talk for everyone else doesn't really
> help, either.

Boy, some of you guys seem to have a very low self esteem, reading
insults where none exist. "Just a bunch of code monkeys"?!! Where in
the friggin' world did I say anything remotely resembling that? I
happen to be a proud "code monkey" myself, for crying out loud!  And
excuse me for suggesting a minor new feature to enhance the
productivity of Python without implementing it myself! Geez!

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

Re: Why not just show the out-of-range index?

[Russ]

Robert Kern wrote:

> Nothing is going to happen until you do one of these two things. Being more 
> rude
> (and yes, you are being incredibly rude and insulting) won't move things 
> along.

I re-read the thread, and I don't see anywhere where I was rude except
in reply to rudeness by others. Sorry, but I haven't mastered the "turn
the other cheek" thing yet.

My suggestion that it would be much easier for the Python maintainers
than for me to implement the requested feature is just basic common
sense. I would have to spend many hours or days just to familiarize
myself with the code, but they are obviously already very familiar with
it. And they would probably have to spend nearly as much time checking
my patch as they would writing it themselves anyway.

By the way, your parenthical assertion that I am "being incredibly rude
and insulting" is itself an unwarranted and devious insult, and I will
not let you get away with it without being called on it. But I'm
willing to forget about it and move on, and I'll assume you are too.

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

Re: Why not just show the out-of-range index?

[Russ]

Carsten Haese wrote:

> You may not have meant this to be rude, but it does come off as rude and
> arrogant, and I'll explain to you why: In your first post you stated
> that the feature seems like a no-brainer to you. That implies to the
> reader that you might have the necessary skill to implement the feature
> yourself, hence Robert's suggestion to submit a patch was, in the
> context you gave yourself, neither unreasonable nor silly. I can see how
> your calling a reasonable suggestion by a valuable community member
> "silly" would be construed as rude and arrogant.
>
> Hope this helps,

OK, fair enough. I shouldn't have called his suggestion "silly." When I
replied to him I honestly thought it was, but in retrospect I now see
that it wasn't. My mistake.

By the way, I consider myself a pretty good Python programmer, but I
haven't used C in many years, and I have no desire to ever use it -- or
even see it -- again. That's one of the reasons I use Python in the
first place. (I am fortunate enough to get to choose the language I
use.) I think it's unfortunate that Python is written in C, but I won't
get into that now. (And yes, I am aware of Jython, but I don't care
much for Java either.)

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

Re: Why not just show the out-of-range index?

[Russ]

Fredrik Lundh wrote:

> > Sorry I haven't thought this through 100%
>
> obviously not.


And you didn't like the "tone" of some of my earlier posts?

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

Re: Why not just show the out-of-range index?

[Russ]

Fredrik Lundh wrote:

> you're forgetting that you're dealing with "squeaky wheel contributors"
> here, not the kind of nice and helpful persons that actually make open
> source work.

Please refrain from dishing out gratutious insults until you have a
clue what you are talking about. It just so happens that I *have* made
significant contributions to open-source software.

A few years ago, I spent several man-months of my own time developing a
free, open-source, full-featured GUI for voting:

http://russp.org/GVI.htm

GVI, The Graphical Voter Interface, is a GUI (Graphical User Interface)
for voting, suitable for use in private or public elections. Although
it could be adapted for online voting, it is currently intended only
for conventional "precinct" voting. For security reasons, GVI does not
require that the voter have access to a keyboard. It can handle
write-ins and multi-language elections, and it can automate voting
along party lines. GVI can be used for Condorcet Voting and Instant
Runoff Voting, which allow voters to rank the candidates in order of
preference. It can also be used for Approval Voting, which allows
voters to select more than one candidate.

More recently, I developed a free, open-source Python package for
dealing with physical scalars. It has an innovative feature that
preserves the efficiency of built-in numerical types with an optional
switch:

http://russp.org/scalar.htm

A Python class was designed to represent physical scalars and to
eliminate errors involving implicit physical units (e.g., confusing
angular degrees and radians). The standard arithmetic operators are
overloaded to provide syntax identical to that for built-in numeric
types. The scalar class comes with a complete implementation of the
standard metric system of units and many standard non-metric units. It
also allows the user to easily define a specialized or reduced set of
appropriate physical units for any particular application or domain.
Once an application has been developed and tested, the units can easily
be switched off, if desired, to achieve the execution efficiency of
operations on built-in numeric types (which can be two orders of
magnitude faster). The scalar class can also be used for discrete units
to enforce type checking of integer counts, thereby enhancing the
built-in dynamic type checking of Python.

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

Re: Why not just show the out-of-range index?

[Russ]

Folks,

I'm truly sorry that so many feathers got ruffled in this thread. Let's
see if I can put this thing to rest gracefully.

Russ wrote:

> My suggestion is trivial to implement and would benefit every Python
> programmer (even if only slightly), so I don't think it is too much to
> ask for.

Apparently I was wrong about the implementation being trivial. Tasks
often seem trivial -- until you actually try to do them. Yes, I should
have known better. Had I not wrote that little gem, I suppose a lot of
bad feelings could have been avoided.

Would it be nice to get the specifics about an index error? Yes. But is
it actually worth implementing? Well, since I have no intention of
implementing it myself, I can't make that call. I can only hope that
the Python maintainers decide that it is worth their effort to make
Python more convenient for the user. But even if they don't, I still
intend to continue using Python. The call is theirs to make. As I said
earlier, the "issue" is hardly a major one, and I'm sorry it got blown
out of proportion.

At this point I don't even plan to submit a formal request. I have too
many accounts and passwords already. If someone else wants to do it,
please have at it.

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

Re: Why not just show the out-of-range index?

[Russ]

stdazi wrote:
> Usually, when I make some coding mistake (index out of range - in this
> case) I just care to fix the mistake and I usually don't mind to
> inspect by how much the index was overflowed. It really seems like a
> feature that should be embedded in some Python debugger than a feature
> in the interpreter itself.

Then why have the interpreter generate error messages at all? I think
it makes sense to make the interpreter as self-contained as possible,
within reason, so you don't depend on a debugger any more than
necessary.

And it's not that I care "how much the index was overflowed." It's that
something unexpected happened, and I want a clue what it was. I'll need
to find out somehow anyway. What is the next logical step if not to
find out what the out-of-range index was?

Having said that, I reiterate that I don't know the implementation
difficulty, so I defer on the decision as to whether it is worth
implementing or not.

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

Re: Why not just show the out-of-range index?

[Russ]

> - because error messages are not debugging tools (better use unit

Then what are they? Machine-generated poetry?

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

Re: Automatic debugging of copy by reference errors?

[Russ]

greg wrote:

> You need to stop using the term "copy by reference",
> because it's meaningless. Just remember that assignment

I agree that "copy by reference" is a bad choice of words. I meant pass
by reference and assign by reference. But the effect is to make a
virtual copy, so although the phrase is perhaps misleading, it is not
"meaningless."



> Again, this is something you'll find easier when
> you've had more experience with Python. Generally,
> you only need to copy something when you want an
> independent object that you can manipulate without
> affecting anything else, although that probably
> doesn't sound very helpful.

Yes, I realize that, but deciding *when* you need a copy is the hard
part.

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

representing physical units

[Russ]

I know that python packages are available for representing physical
units, but I am getting frustrated trying to find them and determine
which is the best.

Rather than just using conventional dimensionless numbers with implicit
units, I would like to have a way to explicitly represent the units. If
incompatible units are added or subtracted, I would like to have an
error detected. Auto-conversions (e.g., from feet to miles) to enforce
consistency before adding or subtracting are not necessary. I would
even like to be able to multiply units. For example, I would like to
have meters returned when I multiply meters/second by seconds.

Where can I find a good package that does this? Thanks.

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

aborting without killing the python interpreter

[Russ]

I wrote a simple little function for exiting with an error message:

def error ( message ): print_stack(); exit ("\nERROR: " + message +
"\n")

It works fine for executing as a script, but when I run it
interactively in the python interpreter it kills the interpreter.
That's not what I want. Is there a simple way to have a script
terminate but not have it kill the python interpreter when I run it
interactively? I suspect I may need to use exceptions, but I'm hoping
not to need them. Thanks.

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

deriving from float or int

[Russ]

Does it ever make sense to derive a class from a basic type such as
float or int? Suppose, for example, that I want to create a class for
physical scalars with units. I thought about deriving from float, then
adding the units. I played around with it a bit, but it doesn't seem to
work very well. Am I missing something here? Thanks.

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

Re: deriving from float or int

[Russ]

The problem is that when I derive a new class from float, the darn
thing won't let me create a constructor that accepts more than one
argument. I need two arguments: one for the numerical value and one for
the units. But when I try to give the constructor two arguments, I get
this when I call the constructor:

TypeError: float() takes at most 1 argument (2 given)

In other words, python doesn't seem to want to let me "extend" the
float type. I don't understand the reason for that, but I assume there
is a reason.

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

"configuring" a class

[Russ]

I would like to let the user of one of my classes "configure" it by
activating or de-activating a particular behavior (for all instances of
the class).

One way to do this, I figured, is to have a static class variable,
along with a method to set the variable. However, I am stumped as to
how to do that in python. Suggestions welcome.

The next best thing, I figure, is to just use a global variable.
Several "methods" of the class then check the value of the global
variable to determine what to do. The user can then just set the
variable to get the desired behavior.

However, I tried this and it does not seem to work. I imported the
class, then set the global variable. But the new value of the variable
somehow did not get back into the class methods that need to see it.

Can anyone give me a clue about this? If there is a better way, please
let me know. Thanks.

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

compiling python and calling it from C/C++

[Russ]

Is it possible to compile python code into a library (on unix), then
link to it and call it from C/C++? If so, where can I learn how.
Thanks.

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

Re: compiling python and calling it from C/C++

[Russ]

Diez B. Roggisch wrote:
> Russ schrieb:
> > Is it possible to compile python code into a library (on unix), then
> > link to it and call it from C/C++? If so, where can I learn how.
>
> You can't compile python, but what you can do is create a
> library-wrapping around it using elmer which will make it C-callable.
>
> http://elmer.sourceforge.net/

This looks promising. Thanks.

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

type conversions for comparison operators

[Russ]

I recently discovered a bug in one of my programs that surprised me
because I thought Python's dynamic type checking would have
caught it.

Suppose I have a function that returns an integer, such as

def numItems: return len(self.items)

Now I want to do a test like this:

if object.numItems() > 2: 

But suppose I mistakenly leave off the parentheses:

if object.numItems > 2: 

I would have thought that Python would choke on this, but it
doesn't. Apparently, Python converts the operands to a common
type, but that seems risky to me. Is there a good reason for allowing
a function to be compared to an integer? Thanks.

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

automatic type conversion for comparison operators

[Russ]

I posted a message on this several days ago, but it apparently got
lost
in googlespace, so I'll try it again.

I recently discovered a bug in my code that apparently resulted from
the automatic conversion of a function pointer to an integer.

Say you have a class member function called getCount(), which
returns an integer. Now suppose you write something like

if obj.getCount < 3: ...

This is an error because the parentheses were left off. But Python
somehow compares the function pointer with an integer without
complaining. Unless there is a darn good reason for allowing
comparisons of this type (and I can't think of one), I think
Python should flag this as an Exception.

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

Re: automatic type conversion for comparison operators

[Russ]

Dan Bishop wrote:

> BTW, are you a former Pascal programmer?

No. Why do you ask? [The code snippet I wrote was made up to get a
point across. I
did not actually use that function name in my code.]

> > But Python
> > somehow compares the function pointer with an integer without
> > complaining. Unless there is a darn good reason for allowing
> > comparisons of this type (and I can't think of one), I think
> > Python should flag this as an Exception.
>
> IIRC, the reason is for backwards compatibility with a long-obsolete
> version of Python in which it wasn't possible for __cmp__ to throw an
> exception.  That's not darn good, so this behavior is already slated
> for removal in version 3.0.

That's good to know. Thanks.

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

status of Programming by Contract (PEP 316)?

[Russ]

I just stumbled onto PEP 316: Programming by Contract for Python
(http://www.python.org/dev/peps/pep-0316/). This would be a great
addition to Python, but I see that it was submitted way back in 2003,
and its status is "deferred." I did a quick search on
comp.lang.python,
but I don't seem to see much on it. Does anyone know what the real
status is of getting this into standard Python? Thanks.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

On Aug 28, 9:35 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Russ wrote:
> > I just stumbled onto PEP 316: Programming by Contract for Python
> > (http://www.python.org/dev/peps/pep-0316/). This would be a great
> > addition to Python, but I see that it was submitted way back in 2003,
> > and its status is "deferred." I did a quick search on
> > comp.lang.python,
> > but I don't seem to see much on it. Does anyone know what the real
> > status is of getting this into standard Python? Thanks.
>
> PEP's with "deferred" status typically aren't going into Python any time
> soon, if ever.  Since the due date for all Python 3 core changes is long
> past due, you won't even be seeing it in Python 3.
>
> Steve

Thanks for that information. That's too bad, because it seems like a
strong positive capability to add to Python. I wonder why the cold
reception. Were there problems with the idea itself or just the
implementation? Or is it just a low priority?

In any case, I guess it is still perfectly usable even if it isn't
part of the core Python. Has anyone used it? If so, how well did it
work? Thanks.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

On Aug 28, 10:58 pm, Michele Simionato <[EMAIL PROTECTED]>
wrote:

> Why do you think that would ad a strong positive capability?
> To me at least it seems a big fat lot of over-engineering, not
> needed in 99% of programs. In the remaining 1%, it would still not
> be needed since Python provides out of the box very powerful
> metaprogramming capabilities so that you can implement
> yourself the checks you need, if you really need them.

I get the strong impression you don't really understand what
programming by contract is.

I have not yet personally used it, but I am interested in anything
that can help to make my programs more reliable. If you are
programming something that doesn't really need to be correct, than you
probably don't need it. But if you really need (or want) your software
to be correct and reliable as possible, I think you you should be
interested in it. You might want to read this:

http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

> But it's always a good idea to make your software "correct and as
> reliable as possible", isn't it? The problem is the external constraints
> on the project. As the old saying goes: "Cheap, fast, reliable: choose
> any two".

If you are suggesting that "programming by contract" is not
appropriate for every application, you will get no argument from me.
All I am suggesting is that having the option to use it when you need
it is very desirable, and it can possibly enhance the versatility of
Python by making Python more suitable for *some* mission-critical
applications.

I once read a book on something called SPARK Ada, which also supports
programming by contract. I was pleasantly surprised to discover
yesterday that support for the such methods is also available for
Python. However, the support would obviously be a bit stronger if it
were in the core Python distribution.

What I really like about the implementation I cited above is that the
invariants and the pre and post-conditions can all be put right in the
doc string at the beginning of each class or function. You can think
of it as a detailed specification of the intent (or of some of the
requirements or constraints) of the class or function -- which can be
*automatically* checked during testing. It can also be used for
explicit type checking.

It's like having some of your most critical unit tests built right
into your code. It may make your code very verbose, but it will also
be very complete.



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

Re: status of Programming by Contract (PEP 316)?

[Russ]

> I disagree. IMO automatic testing is thousands of times better than
> design by contract and Python has already all the support you need
> (unittest, doctest, py.test, nose, ...)

In theory, anything you can verify with "design by contract" you can
also verify with unittest and the rest. However, "design by contract"
has a major practical advantage: if you have real (or simulated)
inputs available, you don't need to write a test driver or generate
test inputs for each class or function.

All you need to do is to run your program with the real (or simulated)
inputs, all the internal data that gets passed around between classes
and functions gets generated as usual, and everything gets tested
automatically. In other words, you are spared the potentially
considerable effort of generating and storing samples of all the
internal data that gets passed around internally.

You may want to do unit tests also, of course. Separate unit tests
will give you more control and allow you to test individual classes
and functions using a wider variety of inputs. But if your design by
contract is comprehensive (i.e., passing it guarantees correct
functioning of your code), then your unit tests can simply make use of
the tests already available in the design by contract. So you've done
no extra work in setting up the design by contract anyway.

Another significant advantage of "design by contract" is that the
tests are all right there in your source code, where they are much
less likely to get lost or ignored by subsequent programmers who need
to maintain the code.  Relying on separate units tests is a bit like
relying on extended "comments" or design documents that are separate
from the code. Yes, those are certainly useful, but they do not
eliminate the need for comments in the code.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

> PEP 316 introduces new syntax for a limited use feature. That's pretty
> much a no-starter, in my opinion, and past experience tends to bear
> that out. Furthermore, it predates decorators  and context managers,
> which give all the syntax support you need and let you move the actual
> DBC features into a library. I can't remember if I mentioned this
> before but I believe that Philip Ebys PEAK toolkit has some stuff you
> could use for DBC.

I don't see how you can avoid adding some new syntax, given that
Python does not
currently have syntax for specifying invariants and pre- and post-
conditions. And if I am
not mistaken, the new syntax would appear only in doc strings, not in
the regular Python
code itself. We're not really talking here about changing the core
Python syntax itself,
so I don't see it as a "non-starter." Anyone who chooses not to use
would be completely
unaffected.

As far as I can tell, Terence Way has done a nice job of implementing
design by contract for
Python, but perhaps a better approach is possible. The advantage of
making part of the
core Python distribution is that it would get vetted more thoroughly.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

> Things get vetted *before* they get added to the core, not after.

I realize that. I meant that it would get vetted in the process of
putting it into the core. That
would provide more confidence that it was done the best possible way
-- or close to it.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

Bruno Desthuilliers wrote:
> Russ a écrit :
> (snip)
>
> > I don't see how you can avoid adding some new syntax, given that
> > Python does not
> > currently have syntax for specifying invariants and pre- and post-
> > conditions.
>
> class Parrot(object):
>@pre(lambda x : x != 42)
>@post(lambda result: result != 42)
>@invariant(lambda self: self.x == 42)
>def reliable_method(self, x):
>  # your code here
>  return something

That looks like new syntax to me. Did I miss your point?

I have no strong leaning about what the exact syntax should be for
programming by contract.
The syntax you show above seems reasonable, except that I am not sure
about requiring
that everything be put inside parentheses. That seems a bit confining
for more complex
conditions.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

Bruno Desthuilliers wrote:
> Russ a écrit :
> > On Aug 28, 10:58 pm, Michele Simionato <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> >>Why do you think that would ad a strong positive capability?
> >>To me at least it seems a big fat lot of over-engineering, not
> >>needed in 99% of programs. In the remaining 1%, it would still not
> >>be needed since Python provides out of the box very powerful
> >>metaprogramming capabilities so that you can implement
> >>yourself the checks you need, if you really need them.
> >
> >
> > I get the strong impression you don't really understand what
> > programming by contract is.
>
> I get the strong impression you don't really understand how
> condescending you are.

When someone writes something as ignorant as that, they need to be
called on it.

So you can implement everything you need already in Python? Yes, of
course, and you
can do it in machine language too -- if you have the time to waste.

> > I have not yet personally used it,
>
> You have no working experience with the concept, but you think it should
> make it into Python's core ???

I don't need to use it to understand the concept. That has been
explained
brilliantly by the Eiffel and SPARK Ada folks.

I am also smart enough to figure out that
it can greatly enhance unit testing, and it can also be used as an
integral part of unit testing.
Once you have the conditions in place, all you need to do in your unit
tests is to send inputs
to the unit and wait to see if exceptions are thrown.

In fact, I would even propose a new name for "programming by
contract." I would call it
"self-testing code" because the code essentially tests itself every
time it is run with the
checks activated.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

> > That looks like new syntax to me.
>
> It's the syntax for decorator functions, and it's not that new - it
> cames with Python 2.4, released November 30, 2004.

After looking more carefully at your example, I don't think it is as
clean and logical as the
PEP 316 syntax. At first I thought that your pre and post-conditions
applied to the class,
but now I realize that they apply to the function. I prefer to see the
conditions inside
the function in the doc string. That just seems more logical to me.
With all due respect,
your proposal is interesting, but I think it overextends the "function
decorator" idea a bit.

A nit-pick I might have with the PEP 316 syntax is that I think
"invariant" should be spelled
out rather than abbreviated as "inv".  The same might apply to "pre-
condition" and
"post-condition". But that's obviously no big deal.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

Ryan Ginstrom wrote:

> I tried using DBC for a time in C++ (using a library with a clever
> assembly-language hack). I personally found it neater having such code in
> unit tests, but obviously, it's a matter of preference.

I agree that it ultimately boils down to preference, but as I tried to
explain earlier, I don't
think that unit tests are equivalent to DBC (or, as I referred to it
earlier, "self-testing code").

Unit tests are not automatically executed when you run your
application. You need to write
the drivers and generate sample inputs to all the functions in your
application, which
can be very time-consuming. And if you think you can anticipate all
the weird internal data
that might come up in the execution of your application, then either
your application is very
simple or you are fooling yourself.

With self-testing code, on the other hand, all you need to do is to
get sample inputs to
your application (not internal inputs to functions) and run the entire
application. That is
much simpler and more comprehensive than unit testing.

Again, I recognize that it doesn't necessarily replace unit testing
completely. For one thing,
unit testing can test for specific outputs for specific inputs,
whereas you wouldn't want to
clutter your actual code with such specific cases. For example, a unit
test for a sorting
function could provide a specific input and test for a specific
output, but you probably
wouldn't want to clutter your code with such a case. The self-tests in
your code would be
more for general tests. PEP 316 provides an excellent of comprehensive
tests for a sorting
function. If you pass those tests, you can be sure your function
worked correctly.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

> Pre and post conditions applying to the class ? Now that's an
> interesting concept. IIRC, Eiffels pre and post conditions only apply to
> methods, and I fail to see how they could apply to a class. But since
> you're an expert on the subject, I don't doubt you'll enlighten us ?

I made a simple mistake. Excuse me. Oh wait ... aren't you one of the
sensitivity police who
laid into me for criticizing someone else. For the record, the guy I
criticized
made ridiculous assertions about DBC. All I did was to make a simple
mistake about
an inconsequential matter. No, pre and post conditions obviously don't
apply to classes,
but all I said was that that's how it appeared to me "at first
glance."

If you are upset about my criticism of one of your colleagues, please
tell him to quite making
outrageous assertions about something he obviously knows little about.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

> FWIW, the "Eiffel and SPARK Ada folks" also "brilliantly explained" why
> one can not hope to "write reliable programs" without strict static
> declarative type-checking.

And they are probably right.

I don't think you understand what they mean by "reliable
programs." Any idea how much Python is used for flight control systems
in commercial
transport aircraft or jet fighters? How about ballistic missile launch
and guidance systems?
Any idea why?

For the record, I think that DBS could possibly make Python more
suitable for *some*
mission-critical or perhaps even safety-critical applications, but it
will never be able
to compete with SPARK Ada or even Ada at the highest level of that
domain.

The important question is this: why do I waste my time with bozos like
you?

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

Paul Rubin wrote:
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> > FWIW, the "Eiffel and SPARK Ada folks" also "brilliantly explained"
> > why one can not hope to "write reliable programs" without strict
> > static declarative type-checking.
>
> I don't know about Eiffel but at least an important subset of SPARK
> Ada's DBC stuff is done using static analysis tools (not actually
> built into the compiler as it happens) to verify statically
> (i.e. without actually running the code) that the code fulfills the
> DBC conditions.  I don't see any way to do that with Python
> decorators.

Yes, thanks for reminding me about that. With SPARK Ada, it is
possible for some real
(non-trivial) applications to formally (i.e., mathematically) *prove*
correctness by static
analysis. I doubt that is possible without "static declarative type-
checking."

SPARK Ada is for applications that really *must* be correct or people
could die. With all
due respect, most (not all, but most) Python programmers never get
near such programs
and have no idea about how stringent the requirements are. Nor do most
programmers
in general, for that matter. (It's not an insult)

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

> I've always wondered... Are the compilers (or interpreters), which take
> these programs to machine code, also formally proven correct?

No, they are not formally proven correct (too complicated for that),
but I believe they are certified to a higher level than your "typical"
compiler. I think that Ada compilers used for certain safety-critical
applications must meet higher standards than, say, GNU Ada, for
example.

And the OS
> in which those programs operate, are they also formally proven correct?

Same as above, if I am not mistaken.

> And the hardware, microprocessor, electric supply, etc. are they also
> 'proven correct'?

I think the microprocessors used for flight control, for example, are
certified to a higher level than standard microprocessors.

How would you prove a power supply to be "correct"? I'm sure they meet
higher reliability standards too.


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

Re: status of Programming by Contract (PEP 316)?

[Russ]

> I guess one difference from unit test philosophy is > that at least
> sometime, you'd run the entire application with all > the dbc checks
> enabled, and just live with the slowdown.

Yes, that's right. You don't expect to run efficiently with the self-
test checks activated, but you can test your code more conveniently
and comprehensively than unit tests by simply running your program as
usual -- except with the checks activated. If you do that for any
significant period of time, many bugs will find themselves, I'm sure.

Also, to repeat once again, the embedded self-test (DbC) checks can be
used for unit testing too. You simply activate the self-tests when you
do your unit testing, and wait for them to throw exceptions. So it
seems to me that you've killed two birds with one stone.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

> Python really isn't suitable for in-flight controls > for various
> reasons, and mission critical concerns is a minor one (systems with

Do you know anything about the FAA certification process for flight-
critical systems? I am not an expert on it, but I know it is very
expensive. If I am not mistaken, getting such code certified is more
expensive than developing it in the first place. Why would that be so
if, as you claim, "mission critical concerns is a minor one"?

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

On Aug 30, 7:20 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> Russ <[EMAIL PROTECTED]> wrote:
>
>...
>
> > programs." Any idea how much Python is used for flight control systems
> > in commercial
> > transport aircraft or jet fighters?


Hi Alex. I've always enjoyed your Piggies talks at
Google (although I missed he last one because I was out
of town). I'm disappointed to see that you seem to have
taken personal offense from remarks I made to someone else who
attacked
me first. I will take issue with some of your remarks,
bit none of it is intended to be personal, and I sincerely hope
you don't take it that way.


> Are there differences in reliability requirements between the parts of
> such control systems that run on aircraft themselves, and those that run
> in airports' control towers?  Because Python *IS* used in the latter
> case, cfr <http://www.python.org/about/success/frequentis/> ... if
> on-plane control SW requires hard-real-time response, that might be a
> more credible reason why Python would be inappropriate (any garbage
> collected language is NOT a candidate for hard-real-time SW!) than your
> implied aspersions against Python's reliability.


I've seen that site before. They have a nice product
that was developed in Python, but it is not clear to me
that is actually safety-critical. It appears to be a
GUI designer for displays at air traffic control towers.
I can't tell if this is "just" a development tool, or if it
the python-based product is actually used directly by
controllers. Also, this product does not seem to actually
display aircraft to controllers. It seems to be more of
a semi-static display of runway conditions. Not to
minimize its importance, but I don't know if this product
actually qualifies as safety critical, and if it does,
it probably does so only marginally.


> According to
> <http://uptime.pingdom.com/site/month_summary/site_name/www.google.com>,
> Google's current uptime is around 99.99%, with many months at 100% and a
> few at 99.98% -- and that's on *cheap*, not-that-reliable commodity HW,
> and in real-world conditions where power can go away, network cables can
> accidentally get cut, etc.  I'm Uber Tech Lead for Production Systems at
> Google -- i.e., the groups I uber-lead are responsible for some software
> which (partly by automating things as much as possible) empowers our
> wondrous Site Reliability Engineers and network specialists to achieve
> that uptime in face of all the Bad Stuff the world can and does throw at
> us.  Guess what programming language I'm a well-known expert of...?


I certainly cannot deny the success of Google, but I
don't think that a high uptime with thousands of servers
is comparable to reliable safety-critical software. You
can't put thousands of flight management computers on
an airplane and just switch over to another as they go
fail. And if a web server gives bogus results nobody
worries much, but if a flight computer gives bogus
outputs, some people worry a lot.

By the way, I use Google Groups, and it has a few
annoying glitches. For example, I couldn't read your
post without scrolling horizontally. With all the money
and manpower at Google's disposal, couldn't you fix that
problem? Another problem I have had for months is that
when I write a message to post, I get no auto scrolling,
so I have to add manual line breaks to keep the text from
running out of the window -- then the reader sees all
those ugly misplaced line breaks in the output. These are
just annoyances, but why hasn't Google fixed them yet?

The point I am trying to make is that, while Google does
great things, and is very successful commercially, the
quality of its code could certainly use some improvement.
Microsoft is also very successful commercially, but
certainly you wouldn't argue that is is a result of the
quality of its software, I hope.

I may have a simplistic view, but I have always thought
that the requirements of most Google code are the very
antithesis of the requirements of safety critical code.
When I do a search, I
fully expect most of the results to be crap. It's a
scattershot approach. If I get one good result, I am
usually happy. Safety critical software is exactly the
opposite: if you get one *bad* result, you could be in
a heap of something nasty.



> > The important question is this: why do I waste my time with bozos like
> > you?
>
> Yeah, good question indeed, and I'm asking myself that -- somebody who
> posts to this group in order to attack the reliability of the language
> the group is about (and appears to be supremely ignorant about its use


I am sorry that you took offense at my pointing out the
weaknesses of Python. It's a great language for certain
kinds of application

Re: status of Programming by Contract (PEP 316)?

[Russ]

Michele Simionato wrote:

> I am curious. Why do you think I attacked you? The conversion went as
> follows:

I don't think you attacked me. I was referring to another person, who
apparently came to your
defense and *did* attack me.

For the record, I apologize for saying that you don't seem to know
what DbC is. I shouldn't
have made it personal. I should have just made the points I made and
let them stand on their
own.

Having said that, I think that some of the statements you made were
clearly excessive.
Unit testing is a thousand times better than DbC? How could that
possibly be? As I
tried to explain, DbC can be *used* for unit testing and *also* for
integrated system testing.

> I would not call that an attack. If you want to see an attack, wait
> for
> Alex replying to you observations about the low quality of code at
> Google! ;)

I don't know much about Google code, but I know that the line breaking
logic (or lack
thereof) on Google Groups is a constant annoyance to me. But maybe I
just haven't
figured out how to use it yet.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

Steve Holden wrote:

> Frankly I am getting a little tired of they way you are unable to even
> recognize that your readers may well have a sensible appreciation of the
> difficulties about which you write. As has been pointed out already,
> many readers here are extremely experienced programmers.

> You said in an earlier post "that's not an insult", but that isn't
> really up to you to decide. If it gives offense then it probably is,
> whether it was intended to do so or not. You don't seem to appreciate
> the insulting nature of your tone, and calling people bozos is not
> likely to endear you to most c.l.py readers since it comes off as arrogant.

You quoted what I wrote in reply to a personal attack against me, but
you conveniently
neglected to quote the original insult that I was replying to. OK,
I'll concede that I shouldn't
have replied to a personal insult with another insult, but why am I
the only one at fault here
rather than the guy who started it?

Frankly, Mr. Holden, I'm getting a bit tired of the clannish behavior
here, where
"outsiders" like me are held to a higher standard than your "insider"
friends. I don't know
who you are, nor do I care what you and your little group think about
me.

As for DbC or what I call "self-testing code," I have come to the
(tentative) realization that
it is easy to implement in current Python -- without resorting to the
"decorators" hack.
OK, maybe this should have been obvious to me from the
start, but here goes:

All you really need to test the pre-conditions of a function
is a call at the top of the function to another function that checks
the inputs. To test the
post-conditions, you just need a call at the bottom of the function,
just before the return,
that checks the return values. Those functions can also check the
invariants. Then you
define a global variable to switch all the self-test functions on or
off at once.

An advantage of this approach is that all the self tests can be put at
the bottom of the file
(or perhaps in another file) to reduce "clutter" in the primary code.

I'd still prefer PEP 316, but this seems like a reasonable
alternative.

One suggestion I have for PEP 316 is to provide a way to place the
self-test
checks in a separate file to reduce clutter.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

Alex Martelli wrote:

> Russ specifically mentioned *mission-critical applications* as being
> outside of Python's possibilities; yet search IS mission critical to
> Google.  Yes, reliability is obtained via a "systems approach",

Alex, I think you are missing the point. Yes, I'm sure that web
searches are critical to
Google's mission and commercial success. But the point is that a few
subtle bugs cannot
destroy Google. If your search engines and associated systems have
bugs, you fix them
(or simply tolerate them) and continue on. And if a user does not get
the results he wants,
he isn't likely to die over it -- or even care much.

Online financial transactions are another matter altogether, of
course. User won't die, but
they will get very irate if they lose money. But I don't think that's
what you are talking about
here.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

Neil Cerutti wrote:

> Who watches the watchmen? The contracts are composed by the
> programmers writing the code. Is it likely that the same person
> who wrote a buggy function will know the right contract?

The idea here is that errors in the self-testing code are unlikely to
be correlated with
errors in the primary code. Hence, you get a sort of multiplying
effect on reliability. For
example, if the chance of error in the primary code and the self-test
code are each 0.01,
the chance of an undetected error is approximately 0.01^2 or 0.0001.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

Steve Holden wrote:

> Well that's a healthy attitude, but I am concerned that the Python
> community should be as welcoming as possible, so I don't like the fact
> that you feel you are being treated differently from anyone else.

I certainly appreciate that. And I will try my best to refrain from
the little personal zingers (and
the big ones too).

> > All you really need to test the pre-conditions of a function
> > is a call at the top of the function to another function that checks
> > the inputs. To test the
> > post-conditions, you just need a call at the bottom of the function,
> > just before the return,
> > that checks the return values. Those functions can also check the
> > invariants. Then you
> > define a global variable to switch all the self-test functions on or
> > off at once.
> >
> It does constrain functions to return only from the bottom of their
> code, though, which not all Python functions currently do. Though
> there's nothing to stop you putting the calls before every return.

Oops! I didn't think of that. The idea of putting one before every
return certainly doesn't
appeal to me. So much for that idea.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

Ricardo Aráoz wrote:

> Actually my point was that if a program is to be trusted in a critical
> situation (critical as in catastrophe if it goes wrong) then the OS, the
>  compiler/interpreter etc should abide by the same rules. That is
> obviously not possible, so there's not much case in making the time
> investment necessary for correctness proof of a little program (or
> usually a little function inside a program) when the possibilities for
> failure are all around it and even in the code that will run that
> function. And we should resort to other more sensible answers to the
> safety problem.

I don't quite see it that way.

I would agree that if your OS and compiler are unreliable, then it
doesn't make much sense to bend over backwards worrying about the
reliability of your
application. But for real safety-critical applications, you have no
excuse for not using a
highly reliable OS and compiler. For really critical stuff, I think
the real-time OSs are usually
stripped down to
the bare basics. And if you are using something like SPARK Ada, the
language itself is
stripped of many of the fancier features in Ada itself. (There's also
something called the
Ada Ravenscar profile, which I believe is geared for safety-critical
use but is not quite as
restrictive as SPARK.)

Keep in mind that the OS and compiler are typically also
used for many other applications, so they tend to get tested fairly
thoroughly. And remember
also that you won't have extraneous applications running -- like a web
browser
or a video game, so the OS will probably not be heavily stressed. The
most likely source
of failure is likely to be your application, so bending over backwards
to get it right makes
sense.

Then again, if you are running C on Windows, you might as well just
give up on reliability
from the start. You don't have a prayer.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

On Aug 31, 6:45 pm, Steve Holden

> We probably need to distinguish between "mission-critical", where a
> program has to work reliably for an organization to meet its goals, and
> "safety-critical" where people die or get hurt if the program misbehaves.

The term "mission critical" itself can have a wide range of
connotations.

If a software failure would force a military pilot to abort his
mission and hobble back home with a partially disabled aircraft,
that's what I think of as "mission critical" software.

If Google needs reliable software on its servers to maintain its
revenue stream, that's another kind of "mission critical" software,
but the criticality is certainly less immediate in that case.

In the first case, the software glitch definitely causes mission
failure. In the Google case, the software problems *may* ultimately
cause mission failure, but probably only if nothing is done for quite
some time to rectify the situation. If that is the case, then the
software itself is not the critical factor unless it cannot be
corrected and made to function properly in a reasonable amount of time.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

On Sep 1, 4:25 am, Bryan Olson

> Design-by-contract (or programming-by-contract) shines in large
> and complex projects, though it is not a radical new idea in
> software engineering. We pretty much generally agree that we want
> strong interfaces to encapsulate implementation complexity.
> That's what design-by-contract is really about.
>
> There is no strong case for adding new features to Python
> specifically for design-by-contract. The language is flexible
> enough to support optionally-executed pre-condition and
> post-condition checks, without any extension. The good and bad
> features of Python for realizing reliable abstraction are set
> and unlikely to change. Python's consistency and flexibility
> are laudable, while duck-typing is a convenience that will
> always make it less reliable than more type-strict languages.


Excellent points. As for "no strong case for adding new features to
Python specifically for design-by-contract," if you mean adding
something to language itself, I agree, but I see nothing wrong with
adding it to the standard libraries, if that is possible without
changing the language itself. Someone please correct me if I am wrong,
but I think PEP adds only to the libraries.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

On Sep 1, 6:51 pm, [EMAIL PROTECTED] (Alex Martelli)

> try:
>   blah blah with as many return statements as you want
> finally:
>   something that gets executed unconditionally at the end

Thanks. I didn't think of that.

So design by contract *is* relatively easy to use in Python already.
The main issue, I suppose, is one of aesthetics. Do I want to use a
lot of explicit function calls for pre and post-conditions and "try/
finally" blocks in my code to get DbC (not to mention a global
variable to enable or disable it)?

I suppose if I want it badly enough, I will. But I also happen to be a
bit obsessive about the appearance of my code, and this does
complicate it a bit. The nice thing about having it in the doc string
(as per PEP 316) is that, while it is inside the function, it is also
separate from the actual code in the function. I like that. As far as
I am concerned, the self-test code shouldn't be tangled up with the
primary code.

By the way, I would like to make a few comments about the
"reliability" of Python code. Apparently I offended you the other day
by claiming or implying that Python code is inherently unreliable. I
think it is probably possible to write very reliable code in Python,
particularly for small to medium sized applications, but you probably
need top notch software engineers to do it. And analyzing code or
*proving* that a program is correct is technically harder without
static typing. In highly regulated safety critical domains, you need
more than just reliable code; you need to *demonstrate* or *prove* the
reliability somehow.

I personally use Python for its clean syntax and its productivity with
my time, so I am certainly not denigrating it. For the R&D work I do,
I think it is very appropriate. But I did raise a few eyebrows when I
first started using it. I used C++ several years ago, and I thought
about switching to Ada a few years ago, but Ada just seems to be
fading away (which I think is very unfortunate, but that's another
story altogether).

In any case, when you get right down to it, I probably don't know what
the hell I'm talking about anyway, so I will bring this rambling to a
merciful end.

On, one more thing. I see that the line wrapping on Google Groups is
finally working for me after many months. Fantastic! I can't help but
wonder if my mentioning it to you a few days ago had anything to do
with it.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

On Sep 1, 10:44 pm, Russ <[EMAIL PROTECTED]> wrote:

> On, one more thing. I see that the line wrapping on Google Groups is
> finally working for me after many months. Fantastic! I can't help but
> wonder if my mentioning it to you a few days ago had anything to do
> with it.

Well, it's working on the input side anyway.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

On Sep 1, 10:05 pm, Russ <[EMAIL PROTECTED]> wrote:

> changing the language itself. Someone please correct me if I am wrong,
> but I think PEP adds only to the libraries.

I meant to write PEP 316, of course.

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

Re: status of Programming by Contract (PEP 316)?

[Russ]

On Sep 1, 11:04 pm, Paul Rubin wrote:

> I still don't understand why you don't like the decorator approach,
> which can easily implement the above.

Well, maybe decorators are the answer. If a function needs only one
decorator for all the conditions and invariants (pre and post-
conditions), and if it can just point to functions defined elsewhere
(rather than defining everything inline), then perhaps they make
sense. I guess I need to read up more on decorators to see if this is
possible.

In fact, the ideal would be to have just a single decorator type, say
"contract" or "self_test", that takes an argument that points to the
relevant functions to use for the function that the decorator applies
to. Then the actual self-test functions could be pushed off somewhere
else, and the "footprint" on the primary code would be minimal

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

programming by contract using "decorators"

[Russ]

In the thread I started a few days ago, I was told that "programming
by contract," could be done with "decorators." I was skeptical that
this was a good approach, but as an exercise, I tried to code it up in
a reasonably elegant form. I'd like to think I succeeded -- and I must
admit that those who told me it could be done with decorators were
right.

My code is shown below. It shows a function called "myfunction," and
another function for testing it called "myfunction_test." More
detailed explanation follows the listing. Comments and feedback are
welcome, of course.

#!/usr/bin/env python

def contract(test, check=0):
"enforce programming by contract"

if check: return test

def null(func):
def null2(*args, **keys):
return func(*args, **keys)
return null2

return null

def getarg(args, keys, num, name):

if name in keys: return keys[name]
return args[num]

def myfunction_test(myfunction):
"contract test for function myfunction"

def test(*args, **keys):

x = getarg(args, keys, 0, 'x')
y = getarg(args, keys, 1, 'y')
z = getarg(args, keys, 2, 'z')

# preconditions would go here, if there were any

result = myfunction(x, y, z) # execute function

assert result == x**2 + 3 * y + z # post-condition

return result

return test

#===

CheckContracts = 1

@contract(myfunction_test, CheckContracts)

def myfunction(x, y, z): return x**2 + 3 * y + z

print myfunction(4, z=1, y=3)

--- end of listing -

Here's what is going on. At the bottom of the listing, you will see
the definition of a function called "myfunction," followed by a call
of the function. It's a trivial function, but I gave it three
arguments just to test passing them out of order by keyword.

Just above the definition of "myfunction" is a "decorator" called
"contract," which takes two arguments. The first argument specifies
the name of the self-test contract function, which is
"myfunction_test" in this case. The second argument is used to enable
or disable the contract tests.

Note that I could have just called the decorator "myfunction_test" and
omitted the "contract" decorator, but I think this form, although
slightly less efficient, is more readable. It also allows the enabling/
disabling logic to be put in one function rather than having to repeat
it in every contract test function.

Dealing with the arguments was not a trivial matter -- at least not
for me. I had to experiment a bit to get it right. The "getarg"
function is simply a utility for parsing the ordered and keyword
arguments. It's very simple, but if something like this already
exists, please let me know. Thanks.

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

generating stats from stdout on a regular interval

[russ]

Hi all,

Very new to Python - but excited to see what is possible - it sounds
very suitable for a project of mine I need a little help with.

I've got an executable which writes out data to stdout in a CSV sort
of format - I'd like to grab the data from stdout and create stats
from it at a regular interval, i.e. every 10 min.  Probably push the
stats out to a CSV file.

The popen2 module can read the stdout just like a file, and the csv
module can handle the reading / writing.  How do I go about
'processing' the stdout every 10 min?

Thanks,
Russ

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

Re: how can I clear a dictionary in python

[Russ]

This little squabble got me thinking. I normally just use the
myDict={} method of "clearing" a
dictionary when I know there are no other references to it. However, I
wonder how the
efficiency of relying on the garbage collector to clear a dictionary
compares with using the
"clear" method. Does anyone know?

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

Re: Units of measurement

[Russ]

Robert Kern wrote:
> Paul Rubin wrote:
> > I'm sure this has been done before, but it just struck my fancy, an
> > example of Python's "emulating numeric types", inspired by the old
> > Unix "units" utility, and the Frink language.
>
> Oh yeah, it's been done before. Several times over, in fact.



> And there was another one announced here sometime in the past year or so, 
> IIRC,
> but I don't recall the name of it or that of the author.  :-(

Perhaps you are referring to the scalar class at
http://RussP.us/scalar.htm

The nice thing about this one (which I wrote myself) is that after you
do your development and are ready for "production" runs, you can easily
disable the unit checks and get the efficiency of built-in numeric
types. That can be two orders of magnitude faster!

It comes with a complete user manual too (pdf and html). I'm using it
for my engineering work, and it's working great!

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

Re: Is any python like linux shell?

[Russ]

Frank Potter wrote:
> I learned some python in windows.
> And now I've turned to linux.
> I read a book and it teaches how to write shell script with bash,
> but I don't feel like the grammar of bash.
> Since I know about python,
> I want to get a linux shell which use python grammar.
> I searched by google and I found pysh, which is not maintained any
> more.
> There's another script named pyshell, which is not likely what I'm
> searching for.
> So, will somebody please tell me if there are any python like shells
> for linux?

You could in principle use Python as a general-purpose interactive
shell, but it wouldn't make much sense. Bash is more convenient for
basic operations such as changing directories, listing directories,
copying files, etc.

For more advanced scripting, I use both bash and Python. I use bash
typically as an executive for scripting Python programs. For example, I
use bash for stepping through a list of directories and running a set
of python programs in each directory. Sure, I could use Python for the
whole thing, but simply starting programs and moving files around is
more straightforward in bash than in Python.

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

Re: Overloading assignment operator

[Russ]

Achim Domma wrote:
> Hi,
>
> I want to use Python to script some formulas in my application. The user
> should be able to write something like
>
> A = B * C
>
> where A,B,C are instances of some wrapper classes. Overloading * is no
> problem but I cannot overload the assignment of A. I understand that
> this is due to the nature of Python, but is there a trick to work around
> this?
> All I'm interested in is a clean syntax to script my app. Any ideas are
> very welcome.
>
> regards,
> Achim

Why do you need to overload assignment anyway? If you overloaded "*"
properly, it should return
the result you want, which you then "assign" to A as usual. Maybe I'm
missing something.

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

generating Java bytecode

[Russ]

I would like to generate Java bytecode from Python source. I know this
is possible using Jython, but I am having problems getting my code to
run on Jython. Is there another way to get Java bytecode? Thanks.

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

setup.py installation and module search path

[Russ]

When I run setup.py to install a pure python package, is it supposed
to
automatically set my search path to find the installed modules? Or am
I
supposed to set my PYTHONPATH variable myself in my .bashrc file?

And what if I don't have root priviledge? Then what is supposed to
happen? Can anyone give me a clue? Thanks.

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

Re: setup.py installation and module search path

[Russ]

Larry Bates wrote:

> I'm no expert, but I think what normally happens is the module gets
> installed into ../pythonxx/lib/site-packages/ and if it
> installs __init__.py file there they get automatically searched.
> At least that the way things work for me.

But if I don't have root priviledge, that doesn't happen. Is there a
setup.py option to get a
package installed just in my own account in such a way that my module
search path gets
updated?

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

jython import search path

[Russ]

I have a Python program that I want to run in Jython so I can get Java
bytecode output. The program runs fine in Python, but when I change
the first line of the main program to make it run in Jython, it fails
to find some of the imported modules. These are just plain Python
imports of code I wrote myself in another directory.

Apparently Jython does not use the PYTHONPATH environment variable. I
created an environment variable called JYTHONPATH just to see what
would happen, but it didn't work either. How am I supposed to tell
Jython where to search for imported modules? Thanks.

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

Re: jython import search path

[Russ]

On Feb 21, 4:15 pm, Larry Bates <[EMAIL PROTECTED]> wrote:
> Russ wrote:
> > I have a Python program that I want to run in Jython so I can get Java
> > bytecode output. The program runs fine in Python, but when I change
> > the first line of the main program to make it run in Jython, it fails
> > to find some of the imported modules. These are just plain Python
> > imports of code I wrote myself in another directory.
>
> > Apparently Jython does not use the PYTHONPATH environment variable. I
> > created an environment variable called JYTHONPATH just to see what
> > would happen, but it didn't work either. How am I supposed to tell
> > Jython where to search for imported modules? Thanks.
>
> Maybe Jython expert has the perfect answer but til then.
>
> Did you try:
>
> sys.path.append('path to search')
>
> Usually this works if nothing else does.
>
> -Larry

Thanks. That's a good workaround, but I would like to know the
"correct" way to do it too if anyone out there knows.

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

Re: jython import search path

[Russ]

Diez B. Roggisch wrote:

> >> Maybe Jython expert has the perfect answer but til then.
> >>
> >> Did you try:
> >>
> >> sys.path.append('path to search')
> >>
> >> Usually this works if nothing else does.
> >>
> >> -Larry
> >
> > Thanks. That's a good workaround, but I would like to know the
> > "correct" way to do it too if anyone out there knows.
>
> That is pretty much an accepted strategy. Another one is to alter the
> registry file, which has a property python.path. It might even be possible
> to use

Accepted strategy? It doesn't seem very portable. It assumes that
everyone puts their library
modules in the exact same place. Or do they just figure that changing
the sys.path.append
line is easy enough?

> java -Dpython.path=

I'm not using Java at all. I just want to generate Java bytecode for
purposes of code analysis
by existing tools.

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

Re: Google App Engine Code Challenge - write a tetris playing algorithm

[russ]

that's the first feature i'll add..  once the popularity gets over zero! :)

On Tue, Dec 2, 2008 at 2:19 PM, Casey McGinty <[EMAIL PROTECTED]>wrote:

> On Sun, Nov 30, 2008 at 2:41 PM, russ.au <[EMAIL PROTECTED]> wrote:
>
>> I've got more features to add, depending on how
>> popular it is.. 
>>
>
> Are you going to create a leader board to track the high scores?
>
--
http://mail.python.org/mailman/listinfo/python-list

Re: Google App Engine Code Challenge - write a tetris playing algorithm

[russ]

>
> what if you wanted to move a piece to the left or right after its past some
> vertical obstruction?
>

Not _presently_ supporting moving the piece left or right.  I've thought
about it, and would make things a bit more complicated - just wanted to get
something simple "out there", and see how much interest it gets.  I've
intentionally made the response format so I that I could add this in the
future without breaking backward compatibility.

On Tue, Dec 2, 2008 at 3:21 PM, Casey McGinty <[EMAIL PROTECTED]>wrote:

> Well, I think its a cool idea. I might try it out if I can find some free
> cycles.
>
> And does the game logic assume the pieces come straight down? For example,
> what if you wanted to move a piece to the left or right after its past some
> vertical obstruction? For example If you place and upside down 'j' or 'l',
> is there any way to fill in the two blocked squares, without removing the
> top portion first?
>
> - Casey
>
--
http://mail.python.org/mailman/listinfo/python-list

implementation of "complex" type

[Russ]

I tried the following:

>>> x = complex(4)
>>> y = x
>>> y *= 2
>>> print x, y
(4+0j) (8+0j)

But when I tried the same thing with my own class in place of
"complex" above, I found that both x and y were doubled. I'd like to
make my class behave like the "complex" class. Can someone tell me the
trick? Also, where can I find the code for for the "complex" class? I
hope it's written in Python! Thanks.

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

Re: implementation of "complex" type

[Russ]

"Why don't you show us your complex class?"

Because I don't have a complex class. I merely used the complex class
as an example to test the referencing behavior. Please read more
carefully next time.

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

Re: implementation of "complex" type

[Russ]

"When you are the one seeking help, you may find it helpful to be
polite  I have found that comp.lang.python has some of the most
friendly and helpful people around.  They will undoubtably help you (as
they helped me many times), if you provide answers to the questions
they ask in trying to help you... "

Asking sarcastically why I am "reinventing the wheel" is a funny way of
being friendly. I said absolutely nothing to indicate that I had
re-implemented my own version of complex. And, by the way, even if I
had, so what? Why is it even worth commenting on?

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

Re: implementation of "complex" type

[Russ]

"Better still, let's not bother ... I'm sorry you don't like the
support
around here, I guess you get what you ask for. "

Boy, some people are very sensitive around here. And some of them also
have a bad habit of misrepresenting my views.

For the record, I am very happy with the support here. In fact, I
solved the problem thanks to a couple of helpful replies to my query,
and I certainly appreciate that help.

What I don't appreciate is having people leap to unwarranted
assumptions and falsely claim that I don't appreciate the help I get. I
can do without that, thanks.

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

Re: implementation of "complex" type

[Russ]

Thanks for the links, especially for the pure Python implementation.
That provides a good model for similar classes.

I am just wondering why your implementation of complex numbers does not
have "assignment operators" such as "__iadd", etc.

By the way, I suppose my original post (where I wrote,  "I'd like to
make my class behave like the "complex" class.") could be construed to
mean that I was implementing my own version of the complex class. But I
only meant that I want it to "behave" like the built-in complex class
with regard to referencing and copying (as my code example showed). My
apologies for any misunderstanding that occurred.

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

output formatting for classes

[Russ]

I'd like to get output formatting for my own classes that mimics the
built-in output formatting. For example,

>>> x = 4.54
>>> print "%4.2f" % x
4.54

In other words, if I substitute a class instance for "x" above, I'd
like to make the format string apply to an element or elements of the
instance. Can I somehow overload the "%" operator for that? Thanks.

On an unrelated matter, I think the complex class in Python is too
complex, so I plan to clean it up and implement it right. (just
kidding, folks!)

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

"pow" (power) function

[Russ]

I have a couple of questions for the number crunchers out there:

Does "pow(x,2)" simply square x, or does it first compute logarithms
(as would be necessary if the exponent were not an integer)?

Does "x**0.5" use the same algorithm as "sqrt(x)", or does it use some
other (perhaps less efficient) algorithm based on logarithms?

Thanks,
Russ

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

Re: "pow" (power) function

[Russ]

Ben Cartwright wrote:
> Russ wrote:

> > Does "pow(x,2)" simply square x, or does it first compute logarithms
> > (as would be necessary if the exponent were not an integer)?
>
>
> The former, using binary exponentiation (quite fast), assuming x is an
> int or long.
>
> If x is a float, Python coerces the 2 to 2.0, and CPython's float_pow()
> function is called.  This function calls libm's pow(), which in turn
> uses logarithms.

I just did a little time test (which I should have done *before* my
original post!), and 2.0**2 seems to be about twice as fast as
pow(2.0,2). That seems consistent with your claim above.

I'm a bit surprised that pow() would use logarithms even if the
exponent is an integer. I suppose that just checking for an integer
exponent could blow away the gain that would be achieved by avoiding
logarithms. On the other hand, I would think that using logarithms
could introduce a tiny error (e.g., pow(2.0,2) = 3.96 <- made
up result) that wouldn't occur with multiplication.

>
> > Does "x**0.5" use the same algorithm as "sqrt(x)", or does it use some
> > other (perhaps less efficient) algorithm based on logarithms?
>
> The latter, and that algorithm is libm's pow().  Except for a few
> special cases that Python handles, all floating point exponentation is
> left to libm.  Checking to see if the exponent is 0.5 is not one of
> those special cases.

I just did another little time test comparing 2.0**0.5 with sqrt(2.0).
Surprisingly, 2.0**0.5 seems to take around a third less time.

None of these differences are really significant unless one is doing
super-heavy-duty number crunching, of course, but I was just curious.
Thanks for the information.

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

output formatting for user-defined types

[Russ]

I'd like to get output formatting for my own classes that mimics the
built-in output formatting. For example,

>>> x = 4.54
>>> print "%4.2f" % x

4.54

In other words, if I substitute a class instance for "x" above, I'd
like to make the format string apply to an element or elements of the
instance. Is that possible? If so, how? Thanks.

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

Re: output formatting for user-defined types

[Russ]

Thanks, but that is not acceptable for my application. Any other ideas?

I thought I might be able to overload __rmod__, but apparently python
applies the % operator before __rmod__ is even invoked if the left-hand
argument is a string.

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

Re: output formatting for user-defined types

[Russ]

>Yeah, how about we read your mind or make wild guesses about why it's
>not acceptable, and about what your requirements really are.

>Really, your response seems a little bizarre to me, given that __float__
>is the defined way in which float() gets a value from an instance, and
>float() is what the % operator calls when it encounters a '%f' in the
>format string.

My class represents physical scalars with units. If I allow arbitrary
conversion to float, then the user can pass any units to trig
functions. But trig functions expect radians, so passing any other unit
(e.g., degrees or meters) is an error. To prevent such errors, I allow
conversion to float only when the units are actually radians (or
dimensionless). That is just one of several reasons for preventing
arbitrary conversion to float, but I won't go into the others here.

By the way, I realize that several other classes have been developed
for representing physical scalars, but I think mine is unique in that
it allows the user to easily disable the units for more efficient
"production runs" after testing is complete. This can increase
efficiency by two orders of magnitude.

I announced my application a week or two ago on comp.lang.announce.
Anyone who is interested can download the code and user guide at
http://RussP.us/scalar.htm

Check it out. I bet you'll like it.

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

Re: output formatting for user-defined types

[Russ]

>I'm sorry, your system of units doesn't allow trig functions to operate on
>degrees? I presume you don't allow grads either. What about steradians or
>other arbitrary measures of angle or solid angle?

I should have stated that more clearly. You can enter the value in
degrees, but it will automatically get converted to radians for
internal use. When you pass it to a trig function, it will
automatically be in radians. For example:

>>> angle = 30 * deg
>>> print sin(angle)
0.5

You could force it to maintain degrees internally if you wanted to, but
then you couldn't pass it to a trig function. That little feature
prevents perhaps the most common unit error, passing degrees when
radians are expected.

I once heard about a simulation that was run for six months before the
researchers realized that their results were corrupted by such an
error. Yes, that's an extreme case, and maybe they were nitwits (with
Ph.Ds), but these errors are very commonplace and often costly in terms
of corrupted results or debugging time. And who knows how many times
such errors subtly corrupted results but were never even detected?

If you want to print it out in degrees, you must explicitly specify
degrees, then it will get converted to degrees for output. For example:

>>> angle = 30 * deg
>>> print >> format ( angle, "deg", "%4.2f" )
30.00 deg

That may seem inconvenient, but it actually helps when the units are
turned off for efficiency, because then the units are still known and
can be printed out explicity.

>(3) You're not my mother. If I want to shoot myself in the foot by
>extracting the scalar part of one of your precious units and then doing
>inappropriate things to it, that's absolutely none of your business.

I am developing a way to guard against common errors in scientific and
engineering software. If you want to use it, then don't. I work in air
traffic control, so I am very concerned about such errors. [No, we
don't use Python for actual operational ATC, but I use it for
prototyping and data analysis. Nevertheless, I believe in avoiding
errors anyway.]

>I suggest another approach: play nice with the rest of Python by allowing
>people to convert your units into strings and floats. Once they have
>explicitly done so, it isn't your problem if they want to add 35 metres to
>18 kilograms and convert the answer into minutes.

Converting to a float is a trivial matter of dividing by the units of
the scalar. For example:

>>> dist = 4 * ft
>>> print >> out, dist/ft
4

Note, however, that this requires the user to explicity ask for the
conversion. What is unwise is to allow the conversion to happen
automatically without the user's awareness. That's where bugs creep in.

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

Re: output formatting for user-defined types

[Russ]

> dist = 4 * ft
> print >> out, dist/ft
>> 4

>> Note, however, that this requires the user to explicity ask for the
>> conversion.

>How is this any more explicit and any less safe than:

>dist = 4 * ft
>print float(dist)

Because the former specifies the actual units and the latter does not.
If the base units were not feet, then the latter would not return the
value in feet (which happens to be 4 here). It would return the value
in whatever the base unit for length happened to be. So the former
works even if the base unit is changed, but the latter does not.

Secondly, allowing unconditional conversion to float allows any unit to
be passed to trig functions. But any unit other than (dimensionless)
radians passed to a trig function is an error. I explaned that already,
but apparently you missed it.

>But in any case, I suspect you do automatically convert units. What do you
>do in this case:

>x = 45*ft
>y = 16*m
>z = x+y

>Do you raise an error?

Nope. Works just fine. You obviously didn't look at the user guide.
What happens is that any length unit is automatically converted to the
chosen base unit for length, so everything is consistent.

>All you are doing is making a rod for your own back, to no advantage.

Wrong again.

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

Re: output formatting for user-defined types

[Russ]

Let me just revise earlier my reply slightly.

>But in any case, I suspect you do automatically convert units. What do you
>do in this case:

Yes, I do automatically convert units, but I only do correct
conversions. Conversion from any unit other than radian to a
dimensionless float is incorrect, so I don't do it automatically.

>x = 45*ft
>y = 16*m
>z = x+y

>Do you raise an error?

I said in the previous reply that this works fine. Actually, I don't
think that is true with the current version, but that is only because I
did not include a meter/feet conversion in the two sample configuration
files that are provided. It is trivial matter of two lines.

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

Re: output formatting for user-defined types

[Russ]

>So what you are saying is, if I enter a unit in feet, you automatically
>change that unit to some base unit (say, metres if you use SI) behind my
>back. So, assuming SI units as the base, if I say:

>print 2*ft + 1*ft

>you're going to give me an answer of 0.9144 metres, instead of the
>expected 3ft. Surely if I'm entering my values in a particular unit, I
>would like to see the answers in that same unit, unless I explicitly ask
>for it to be converted?

Actually, that was my initial thinking exactly, and it is exactly what
my first version actually did. I learned through experience, however,
that that approach makes adding differrent units of the same type
(e.g., feet and meters) substantially more complicated than it is using
my current approach,  so I abandoned it.

The disadvantage is that, as you point out, you can add feet to feet
and get meters. There are two answers to this problem. First, if you
expect to use feet consistently, you can easily make it your base unit.
Secondly, you can always convert the output to feet:

x = 2 * m
print format(x,ft)

That may seem inconvenient, but there are actually a couple of
significant advantages here that makes this form preferable to simply
"print x". One advantage is that if you "disable" units for efficiency,
your output can (and will) still show the units of feet. Otherwise you
lose the unit information completely. The other advantage is that you
can change your base unit and your program will still produce the same
result.

>sin(45*ft)

>is still an error.

>sin(45)

>shouldn't be, even if that 45 came from float(45*ft). What do you care
>where the value comes from? I'm sure you allow sin(float('45')) without
>complaining that trig functions don't operate on strings.

Either you don't understand how the "__float__" function works or you
don't understand basic physics. If the float function converts 45 * ft
to simply 45, then sin(45*ft) will be automatically converted to
sin(45). That is most definitely *not* what you want.

>So, despite your going on about the evils of automatic conversions behind
>the user's back, you do go ahead and do automatic conversions behind the
>user's back.

>Slight inconsistency, don't you think?

Let's try this one more time. Automatic conversion is fine as long as
the conversion is dimensionally correct. Automatically converting from
feet to a dimensionless number is *not* dimensionally correct. This
isn't rocket science.

>Hey, it isn't *me* battling to find a way to easily print my instance
>objects.

Actually, I have already developed an excellent workaround for that
problem.

By the way, I doubt you are impressing anyone here. Are you sure you
want to continue with this?

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

[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"]

[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"]

[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"]

[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"]

[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"]

[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: Reply to post 'Tryign to add a valkue to a set'

[russ . pobox]

for key, value in sorted(months.items(), key=lambda x:x[1]):
print("""'\t%s'\n""" % (value, key))


Explanation:
- - - - - - 
dict.items is a method associated with dicts just like dict.keys or 
dict.values, and returns a list of (key, value) pairs.

sorted and some other builtin functions have an optional key argument, which 
tells the function what exactly to look at when sorting the sequence. (I say 
sequence because you can sort a string or tuple or dict and get a list back in 
return). In this case we use a simple lambda function to tell it to look at the 
value not the key (i.e. (key, value)[1] returns value)

Alternatively you could do this.

def get_value(item):
return item[1]

for key, value in sorted(months.items(), key=get_value):
...etc...

You might also wonder what this would do

for key, value in sorted(months.items()):
...etc...

Which becomes a question of what would something like this do

sorted([(1,3), (2,2), (3,1)])

Well sorted is a function that expects to get some iterable (sequence of some 
kinda items) to sort. If those items happens to be sequences themselves, like 
(key, value) which is a sequence of two items, then it's only going to care 
about the first item and ignore the rest (i.e ignore value).

So the above will return
[(1,3), (2,2), (3,1)] which as far as sorted() is concerned, is already sorted.


About the string being printed:
- - - - - - - - - - - - - - - - 
I'm not sure why or if you want a single quotation around the entire element to 
be printed as well but if so then that's how I'd do it. The \t is for a tab. 
You also don't have to worry about adding newlines because print will print 
each statement on a newline anyways by default unless you tell it otherwise by 
specifying the sep argument.

Sorry my first post, I said allot didn't I.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reply to post 'Tryign to add a valkue to a set'

[russ . pobox]

Just try this in the interpreter and see.

for key, value in sorted(months.items(), key=lambda x:x[1]):
print "%s %s" % (value, key)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Simple program question.

[russ . pobox]

input() is a function which returns a string. You can assign this return value 
to a variable. That's what variables are for.

option = input()

Now you can use the variable named option in place of all those calls to 
input().

i.e:

...instead of..

if input() == 'parry':
# etc

...do this...

option = input()
if option == 'parry':
# etc
elif option == 'whatever':
# etc
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: My son wants me to teach him Python

[russ . pobox]

I couldn't read every post here so don't know if this has been suggested, or if 
there is perhaps a better suggestion which I haven't read in this thread, but 
in as far as I've read I feel the need to recommend:
learnpythonthehardway.org

Knowing a little JavaScript and even allot of HTML doesn't take him out of the 
total noob category when it comes to programming (did someone say game 
programming? Hold your horses!). I took a visual basic course (which I dropped 
out of admittedly after 3 months) and still knew absolutely nothing, which 
isn't necessarily just because I'm dumb.

After eventually learning Python in incremental and sporadic episodes of free 
time, I did come across a few resources and by virtue of the frustration of 
having taken so long to learn to code in the easiest damn programming language 
to learn, I found myself scrutinizing allot of the tutorials I'd been passing 
by.

I noticed developers.google.com somewhere up there. That's just a no no. Sorry. 
Maybe some of the people here are more than "pretty smart" but there's a good 
chance it'll be over his head at first, and at first is a bad place to be in 
over your head when you're learning the fundamentals.

I also notice Invent with python. I personally would go for 2.x rather than 3 
but that aside, for reasons I'm too tired to word, I didn't find it a good fit 
for me. I takes a "dive right in" approach and well, I never did learn to swim.

Udacity was the third suggestion I noticed. This is also a no no. I completed 
the cs101 udacity course which I'm sure is the course in question here, and I 
loved it! Really I learn crap load from it, but at every step I asked myself, 
would this had helped if it was the first place I went to to learn to code? No. 
There were allot of gaps I noticed when looking from a complete beginners 
perspective and even though the course claims to has no prerequisites, I would 
have hated if I started with that. However that was last year and I think it 
was only a few months old, so it may be allot different now, I haven't checked.

I read How to think like a computer scientist, A byte of python, and even the 
official docs. The only one I came across that made me say "&*#! why didn't I 
google that?" was learnpythonthehardway.

I do think it depends a great deal on the individual, and for me personally, 
that style of learning was just it. For one you learn from the bottom up. It's 
a compulsion for some to know that that know a thing before they're brave 
enough to move forward. In cases where a "leap" is the only way forward, the 
tutor pulls you across that divide by your ankles. You feel a sense of 
obligation to take to his instruction. And above all, it greatly emphasizes the 
"learn by doing" approach, in small steps, not big projects that you end up 
completing just to get through it but don't learn much from.

So that's my recommendation. But all that aside, my biggest point would be, 
just pick one do it. As you can see if you read that, my biggest flaw was 
simply the lack of devotion to one path.

Game programming if he still wants to do that is another question entirely I 
feel. Fundamentals are fundamentals. The only variable is how long it might 
take him to get passed it. Even with Python, some people just never get it.
-- 
http://mail.python.org/mailman/listinfo/python-list