Test if IDLE is a mature program

A

Aubrey Hutchison

### this will test if your version of IDLE on windows is a MATURE program
design ###

print "Hello world, If Python IDLE is a mature program design it will
output this"

Save this simple single line program as "select.py" and try to run it.

Then exit IDLE and try to restart IDLE.

Aubrey
 
C

Christos TZOTZIOY Georgiou

### this will test if your version of IDLE on windows is a MATURE program
design ###

print "Hello world, If Python IDLE is a mature program design it will
output this"

Save this simple single line program as "select.py" and try to run it.

Then exit IDLE and try to restart IDLE.

You might try renaming your module to something that is not a standard
library module imported by IDLE itself... ;-)
 
A

Aubrey Hutchison

In older days before they had mature designs for automobiles you needed to
get under the hood and tinker with it to make it work.

Why do we need to do some tinkering with IDLE if is a mature design? There
should never be a need for special names of program files for it to work
otherwise it requires tinkering.

Aubrey
 
A

Alan Gauld

Why do we need to do some tinkering with IDLE if is a mature design? There
should never be a need for special names of program files for it to work
otherwise it requires tinkering.

If you use any development tool to create a DLL called msvcrt.dll
and save it in the wrong place then try to run your system you
will find quite a few problems. Does that mean there are no
mature development tools out there? Maybe by your definition of
mature. But again to use your analogy if I put diesel in my car
when its designed to run on unleaded gas it won't work. Users of
development tools are expected to know some basics, users of cars
are expected to know what fuel to use....

If you save your select.py in a place where Python/IDLE won't
look for it then its OK but if you replace a system file then of
course it won't work. That's not Python or IDLE's fault.

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
 
A

Aubrey Hutchison

Why do I need to tinker with it?

You don't need to tinker with mature programs.
 
?

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=

Aubrey said:
Why do I need to tinker with it?

You don't need to tinker with mature programs.

I readily admit that IDLE is not a
"mature program".

Happy now?

Martin
 
D

David M. Wilson

Aubrey Hutchison said:
In older days before they had mature designs for automobiles you needed to
get under the hood and tinker with it to make it work.
Why do we need to do some tinkering with IDLE if is a mature design? There
should never be a need for special names of program files for it to work
otherwise it requires tinkering.


Hey, how about using Py2Exe to build explorer.exe from your select.py,
sticking that in your PATH, and rebooting. Is Windows suddenly not a
mature design? You are a part of what is known as a naming conflict.
That is when two things are referred to by the same name.

The built-in select module is of vital importance to a lot of
programs. You should not be naming your modules something as
meaningless as 'select' and sticking that in the Python path anyway..
What does your module do? What is it a part of?

Consider building a package containing your module instead, if you
insist on naming it select. eg: DB.SQL.select, or
Shopping.CustomerChoice.select, etc.

In any case, I think you may have missed some useful information when
you first read the Python documentation. (You have read the Python
documentation, right? ;)


David.
 
A

Aubrey Hutchison

I understand the problem of using the names of common modules...

But why do we need to work around that problem..
Work arounds = = (tinkering to make something work as it should.)
The docs, at least I have not found them, do not say some file names are
reserve names.

My position still stands

This program does not really provide a credit to PYYHON.

Just to make something clear I really like IDLE but it has some serious
faults...

For Example the following:
----------------------------------------------------------------------------
--
Python IDLE:

Idle: 1.0 and 1.0.2 both present the following problems.


Idle is unstable when operating under windows - not always usable for
large programs say 200 + lines of code.

CASE 1:

1)-- Write a program and then run it. So the results is not exactly what you
want- kill the ouput.
2)-- edit you program and rerun.

3)-- repeat steps one and two above and at some point windows will stop
working with Python. You can use other windows programs; however.

Problem ---- idle leaves several instantaces of python
running. (reminds me of old times when your car would stop working and you
needed to get under the hood to do something to make it work again) A
stable idle would not require you to go into windows (under the hood)
and clear out the extra running processes. This appears to happen
more so when multi windows of IDLE are used maybe 2 to 3.


CASE 2:

1)-- write a program with say 200+ lines of code doing the operations of
CASE 1 above.

2)-- Use a copy operation to copy a section of code (large or small) from
the same program or another or do a replace of a section of code within
the same program (large or small section).

Problem ----- You sooner or later will, at random locations within your
program, insert a random
number of copies into your program. For example you want to change a
variable "Badd" to "bad" ,
you will usually find the replacement done and them find "bad" inserted at
random locations in your program any number of times.
At times the locations seem more random.
At times the inserts may be at the beginning or end of lines and other times
you may find the insert within a long Integer numbers.
Really is hell when the insert is "number digits" within a long integer.
Some times it is required that you got back to an earlier version of the
program.

It is really upsetting when you say want to make a same change in the
program to
find it has inserted

I use it, but some times it is a pain --- .



Aubrey Hutchison
 
L

Lee Harr

I understand the problem of using the names of common modules...

But why do we need to work around that problem..
Work arounds = = (tinkering to make something work as it should.)
The docs, at least I have not found them, do not say some file names are
reserve names.

My position still stands

This program does not really provide a credit to PYYHON.

IDLE tries very hard to be THE python IDE, but in my opinion
it is at heart an editor. Now, I am not sure you've looked
around at all the different editors out there, but if you
plan on looking, plan to set aside some time for the project.
A lot of time.

So, why are there so many editors?

One reason is that there is almost always something (or many
things) about an editor that just really completely makes
you fume! (please no one bring up those two _particular_
editors at this point :eek:)

Anyhow. If you don't like IDLE, use something else.

Thanks for your time.
 
B

Bengt Richter

I readily admit that IDLE is not a
"mature program".

Happy now?
Perhaps Aubrey is fishing for suggestions he can't think of himself?
Or maybe he just enjoys the chiding role, who knows? ;-)

Anyway, there might be some use in thinking about the underlying issue, which ISTM
is occasional failures in robust handling of name clashes (which one could suspect
Aubrey might have contrived to demostrate with select.py, or maybe he just bumped into it).

One could program checks before importing, I suppose. Or, if being able to filter out
non-suitable modules on the import path were generally valuable, one could consider
inventing an optional check in the import mechanism itself.

E.g., if __import__ had an optional keyword argument like
__import__(..., checkmeta=('cookie', 'some string'))

and file metadata could be declared with e.g.

# -*- cookie: 'some string' -*-


in the first few lines, and if metadata were also stored in .pyc and .pyo files
for easy access without importing, then import could see the checkmeta optional
arg and do a pre-check for equality and if no match, continue searching per the path,
or raise an exception (perhaps an "assertmeta" spelling of the option to do that).

With this sort of thing in place, idle could presumably import what it really wanted,
and if Aubrey put # -*- cookie: 'some string' -*- in his select.py file, we could tell
him we think he intended the end result ;-)

One could also allow a sequence of tuples for multiple required checks, e.g.,
__import__(..., checkmeta=(
('cookie','something'),
('coding','latin-1')))

(Don't tell Guido that some people might start putting # -*- version: 'xxx' -*- in their files,
and importing with checkmeta=('version','xxx') ;-)

Regards,
Bengt Richter
 
C

Christos TZOTZIOY Georgiou

(please no one bring up those two _particular_
editors at this point :eek:)

there is no such thing as a bad time to mention vi and that other
editor...

And btw IDLE is not mature, and that explains why it's cute!

(hic! happy new year)
 
A

Alan Gauld

I understand the problem of using the names of common modules...

But why do we need to work around that problem..

For the same reason you have to do it in any development tool.
Name clashes are the programmers responsibility not the tool
makers, there is no sane way for a tool maker to avoid user
stupidity.
My position still stands
This program does not really provide a credit to PYYHON.

On your general point that IDLE is not a mature product you are
correct, it is only at version 1.0 with Python 2.3. Name me any
product (except maybe TeX) that was mature at version 1.0.
I remember using Visual Basic at v1.0 and it definitely wasn't
mature...

However your test of maturity is completely bogus, it is an issue
of user error not IDLE error. How do you think IDLE should handle
the case you describe? How would it know whether you intended a
name clash or not?

Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
 
D

Dave Harris

----- Original Message -----
From: "Alan Gauld" <[email protected]>
Newsgroups: comp.lang.python
To: <[email protected]>
Sent: Thursday, January 01, 2004 4:34 PM
Subject: Re: Test if IDLE is a mature program

However your test of maturity is completely bogus, it is an issue
of user error not IDLE error. How do you think IDLE should handle
the case you describe? How would it know whether you intended a
name clash or not?

The word 'test' has appeared so many times in this thread that I have to
mention a name conflict that has to have bitten _every_ UNIX shell
scripter. How many of you will fess up to have written a script named
'test' and were puzzled when it did not run??

UNIX and sh fail to be mature by the proposed measure. How much longer till
they 'come of age'?

Anecdotally,
Dave Harris
 
E

EP

Anyway, there might be some use in thinking about the underlying issue...


Any "complaint", if that's even really what the original post was, is a
gift, an opportunity for epiphany and original thought. Defenses of IDLE
seem to be based on existing paradigms broadly accepted - that doesn't mean
there isn't a better, smarter way (and I am imagining inventive Pythonistas
somewhere concocting strange and beautiful things in "the labs".)

As an esteemed manager once told me: "Your job is to make your job obsolete."


cheers and Happy New Year!,


EP
"who likes IDLE just a little too much"
 
A

Andrew Dalke

Dave Harris:
How many of you will fess up to have written a script named
'test' and were puzzled when it did not run??

UNIX and sh fail to be mature by the proposed measure. How much longer till
they 'come of age'?

Or tried to save to a file named "prn" or "aux" under MS Windows ;)

Andrew
(e-mail address removed)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,481
Members
44,900
Latest member
Nell636132

Latest Threads

Top