Re: list index out of range Error , need to fix it or ignore it

[Ganesh Pal]

>>
> what is run(...)
>
The run (_ is a wrapper it uses suprocess.Popen and returns  stdout
,error and extitcod e

> not a good idea to have catchall exception
how to fix this ?

>
>> > return False
>> > if __name__ == '__main__':
>> >   main()
>> >
>> --
>>
> copy and paste your traceback
>

I get  " ERROR:root:list index out of range" error  if the file  is
not found in any of the machine , I dont have a trackback back


def check_file():
"""
 

   Run the command parallel on all the machines , if there is a
file named /tmp/file2.txt  extract file2.txt

"""
global filename
file = ''
cmd = ("run_al_paral 'ls -al %s'" % (filename))
print(cmd)
stdout, stderr, exitcode = run(cmd)
print(stdout)
lines = stdout.strip().split('\n')
print(lines)
for line in lines:
if 'exited' in lines:
continue

file = lines[0].split()[9][6:]
break
print file
return file

def main():
functions = [check_file]
for func in functions:
try:
func()
except Exception as e:
return False
if __name__ == '__main__':
  main()














1. But if the file is not present we get index out of range error , do
we need to fix this or its expected ? or its ok.

machine-4# python c_4.py
isi_for_array 'ls -al /tmp2/2.txt'
machine-2 exited with status 1
machine-1 exited with status 1
machine-4 exited with status 1
machine-5 exited with status 1
machine-3 exited with status 1

['machine-2 exited with status 1', 'machine-1 exited with status 1',
'machine-4 exited with status 1', 'machine-5 exited with status 1',
'machine-3 exited with status 1']
ERROR:root:list index out of range

3. Any other tips to improve the program
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Sun, Feb 28, 2016 at 5:34 PM, Steven D'Aprano  wrote:
> On Sat, 27 Feb 2016 11:07 pm, Chris Angelico wrote:
>
>>> Isn't there any good GUI IDE like Visual Basic? I hope there are some
>>> less well known GUI IDEs which I did not come across. Thanks.
>>
>> Sounds like the advantage lies with Python here...
>>
>> Don't make a UI by dragging and dropping that many widgets.
>
>
> And later, in another post:
>
>> the best way to build a cross-platform GUI is code, not drag-and-drop.
>
>
> I think that's out-and-out wrong, and harmful to the developer community. I
> think that we're stuck in the equivalent of the pre-WYSIWYG days of word
> processing: you can format documents as nicely as you like, but you have to
> use a separate mode to see it.
>
> Drag-and-drop GUI builders have the same advantages over code as Python has
> over languages with distinct compile/execute steps: rapid development,
> prototyping, exploration and discovery. Of course, any decent modern
> builder won't limit you to literally drag-and-drop, but will offer
> functionality like duplicating elements, aligning them, magnetic guides,
> etc.

Alright, but how do you go about doing, with a drag-and-drop builder,
all those things we're used to with code - composing new named actions
out of primitives, observing the changes to a program through source
control, unit testing (maybe), and code review? The only way I know of
to build a "function" in a DnD builder is to create a composite widget
(eg "horizontal box containing label and entry field"), which is
extremely useful, but limited - it's like saying that the only way to
reuse code is single-inheritance. How would you create a higher-order
operation in a DnD builder? How would you write something that does
some sort of sweep over a set of widgets and does the same thing to
them?

All these sorts of things are possible... but we're getting right back
to code again. People have tried to create graphical code builders for
decades; they've never been sufficient. Code - textual commands to
manipulate a system - is still the most powerful and flexible way to
do things.

By the way, you'll notice that I said "dragging and dropping **that
many** widgets" (emphasis added). GUI builders can be great for simple
jobs, and a really awesome one can work well for more complex jobs
too, but the asymptotic complexity of using drag and drop is worse
than that of code.

> GUI elements are by definition graphical in nature, and like other graphical
> elements, manipulation by hand is superior to command-based manipulation.
> Graphical interfaces for manipulating graphics have won the UI war so
> effectively that some people have forgotten there ever was a war. Can you
> imagine using Photoshop without drag and drop?

No, I can't. But I also can't imagine git-managing Photoshop files,
and IMO, that is a serious loss. Would you accept a programming
language that forced all files to be edited by a single person?
Collaboration is pretty important these days. How would you review
edits to approve/deny them if you can't see what was edited?

> And yet programming those graphical interfaces is an exception. There, with
> very few exceptions, we still *require* a command interface. Not just a
> command interface, but an *off-line* command interface, where you batch up
> all your commands then run them at once, as if we were Neanderthals living
> in a cave.

I think there's room to improve the textual interface without throwing
it away. Certainly several of the Python toolkits are quite primitive
in their style; everything has to be executed imperatively, with no
room to build a layout declaratively. But thanks to the flexibility of
code, this is a very real possibility. Nobody can usefully *extend*
the VB UI builder except its owner; anybody can write a function that
simplifies one small part of code generation.

Python's existing APIs definitely need some work, but I've used some
other systems that were closer. Imagine something like this:

win = gtk.Window(
title="Demo Window",
transient_for=mainwindow,
child=gtk.labelled(["User name", "Email", "Password", "Confirm",
gtk.okbtn()]),
)

For more complicated work, build up new primitives and keep right on
going. Do it right, and you should be able to have live editing with a
preview window, and *maybe* even some kind of manipulation tool,
although I'm not sure how best to do that.

This doesn't have to be a dichotomy.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Sun, Feb 28, 2016 at 6:39 PM, Rustom Mody  wrote:
> A sensible view
> And more helpful than pretending that neanderthal == civilized
>
> Chris: Is it easier to work out the best-lookkng colors with a color picker or
> with hacking through a million #rrggbb combos?

Given that "best-looking" is a vague thing that requires a human eye,
the easiest way is to try it, in real-time. Whether you see the
#rrggbb or drag something with the mouse doesn't matter. But this is
an example (single color selection) that is dead simple; whether you
use a picker or explicit RGB, you're still picking up 24 bits of
information that can be comfortably represented in six characters
(seven if you count the hash as part of it). If you mess something up,
you hit Ctrl-Z and go back to the previous color. When it's more
complicated (say, when you're overlaying multiple brushes in multiple
colors), the cost of having a non-textual representation becomes more
serious.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Bug in Python?

[Sven R. Kunze]

On 26.02.2016 23:37, Ian Kelly wrote:

On Fri, Feb 26, 2016 at 3:08 PM, Sven R. Kunze  wrote:

Python sometimes seems not to hop back and forth between C and Python code.

C code as a rule tends to ignore dunder methods. Those are used to
implement Python operations, not C operations.


Ah, good to know.


 _siftup(heap, 0)# that's C

Your comment here appears to be incorrect.

[snip]

So I would guess that the difference here is because one
implementation is entirely C, and the other implementation is entirely
Python.


You are damn right. While implementing xheap and looking at the C 
implementation, I just assumed that all Python functions would be 
replaced by when the C module is imported. Furthermore, the C module 
exports some internal functions (leading _ ) such as _heappop_max. Thus, 
I assumed this is true for _siftup without verifying it by looking too 
closely at the PyMethodDef and PyModuleDef structs. Sorry for that.


Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: Bug in Python?

[Sven R. Kunze]

On 27.02.2016 00:07, eryk sun wrote:

  On Fri, Feb 26, 2016 at 4:08 PM, Sven R. Kunze  wrote:

Python sometimes seems not to hop back and forth between C and Python code.
Can somebody explain this?

Normally a C extension would call PySequence_SetItem, which would call
the type's sq_ass_item, which for MyList is slot_sq_ass_item. The
latter function bridges the CPython and Python sides by binding and
calling the overridden __setitem__ method.  However, the _heapq
extension module uses `PyList_SET_ITEM(heap, 0, lastelt)`. This macro
expands to `((PyListObject *)(heap))->ob_item[0] = lastelt`. This
directly modifies the internal ob_item array of the list, so the
overridden __setitem__ method is never called. I presume it was
implemented like this with performance in mind, but I don't know
whether or not that justifies the loss of generality.


I think this is true and it explains the huge performance penalty of the 
current RemovalHeap and XHeap implementation as it basically uses Python 
only (results here: http://bit.ly/1KU7CyW).


Shoot! I could have seen this earlier. I thought the performance penalty 
was due to calling __setitem__ and dict operations. But having all heap 
operations carried out in Python slows things down considerably of course.


Let's see if I can manage to create a more efficient mark-and-sweep 
approach which uses the C module.


Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: Bug in Python?

[Sven R. Kunze]

On 27.02.2016 12:48, Terry Reedy wrote:

On 2/27/2016 4:44 AM, Steven D'Aprano wrote:

On Sat, 27 Feb 2016 07:55 pm, Terry Reedy wrote:


In other words, when that doc says *list*, it means a *list*.

"To create a heap, use a list initialized to [], or you can transform a
populated list into a heap via function heapify()."

[...]

"A heap must be an instance of *list* (and not a subclass thereof).  To
create a heap, start with [] or transform an existing list into a heap
via function heapify()."


I think that's a sad decision. heapq ought to be able to handle any list
subclass, not just actual lists. Preferably it ought to handle 
duck-typed
lists too, anything with a list-like interface. It is okay if the 
optimized
C version only works with actual lists, and falls back to a slower 
Python

version for anything else.




I agree that it would increase comprehensibility. I took me a fair 
amount of time to see why things are not working as intended (and as you 
see I wasn't even close to the real explanation).


However, heapq might work well the way it is as long as you have the 
chance to get your hands on one of the other heap implementations out there.



Propose that on the tracker, after checking previous issues.


:)

Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 2:15:10 PM UTC+5:30, Chris Angelico wrote:
> On Sun, Feb 28, 2016 at 5:34 PM, Steven D'Aprano wrote:
> > On Sat, 27 Feb 2016 11:07 pm, Chris Angelico wrote:
> >
> >>> Isn't there any good GUI IDE like Visual Basic? I hope there are some
> >>> less well known GUI IDEs which I did not come across. Thanks.
> >>
> >> Sounds like the advantage lies with Python here...
> >>
> >> Don't make a UI by dragging and dropping that many widgets.
> >
> >
> > And later, in another post:
> >
> >> the best way to build a cross-platform GUI is code, not drag-and-drop.
> >
> >
> > I think that's out-and-out wrong, and harmful to the developer community. I
> > think that we're stuck in the equivalent of the pre-WYSIWYG days of word
> > processing: you can format documents as nicely as you like, but you have to
> > use a separate mode to see it.
> >
> > Drag-and-drop GUI builders have the same advantages over code as Python has
> > over languages with distinct compile/execute steps: rapid development,
> > prototyping, exploration and discovery. Of course, any decent modern
> > builder won't limit you to literally drag-and-drop, but will offer
> > functionality like duplicating elements, aligning them, magnetic guides,
> > etc.
> 
> Alright, but how do you go about doing, with a drag-and-drop builder,
> all those things we're used to with code - composing new named actions
> out of primitives, observing the changes to a program through source
> control, unit testing (maybe), and code review? The only way I know of
> to build a "function" in a DnD builder is to create a composite widget
> (eg "horizontal box containing label and entry field"), which is
> extremely useful, but limited - it's like saying that the only way to
> reuse code is single-inheritance. How would you create a higher-order
> operation in a DnD builder? How would you write something that does
> some sort of sweep over a set of widgets and does the same thing to
> them?


Alright...
I can handcraft better assembly than gcc generates. Shall I ditch gcc for 
assembly?
And I can work out more sophisticated memory mgmt and other algos with C than 
with python (vide Steven's recent thread on delimiter-reading),
Shall we prefer C over python?

Moore's law dictates that "penny-wise, pound-foolish" gets multiplied by an
exponential curve and the 'really-wise' puts up with a low(er) level mess for
a higher level good.

Sure the well handcrafted gui code will be smaller, neater, faster, what-have-u
than builder=generated code. So what?
The only reasonable answer is the corollary to Moore's law:
The (differential) cost of programmer-time increases exponentially

> 
> All these sorts of things are possible... but we're getting right back
> to code again. People have tried to create graphical code builders for
> decades; they've never been sufficient. Code - textual commands to
> manipulate a system - is still the most powerful and flexible way to
> do things.
> 
> By the way, you'll notice that I said "dragging and dropping **that
> many** widgets" (emphasis added). GUI builders can be great for simple
> jobs, and a really awesome one can work well for more complex jobs
> too, but the asymptotic complexity of using drag and drop is worse
> than that of code.

Code is always the last resort for arbitrary complexity
Lets keep it the last resort.

If the bottom-line is that python's GUI-builders are so deep into suxland
that they are best avoided in place of hand-written code, thats fine (by me).

Lets please not make a virtue of a lack
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Sun, Feb 28, 2016 at 9:25 PM, Rustom Mody  wrote:
> Code is always the last resort for arbitrary complexity
> Lets keep it the last resort.
>
> If the bottom-line is that python's GUI-builders are so deep into suxland
> that they are best avoided in place of hand-written code, thats fine (by me).
>
> Lets please not make a virtue of a lack

Once someone figures out a way to usefully merge independent changes
(you know, the way source control tools do every single day for code),
maybe I'll consider that. Until then, the last resort is also my first
response.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Sibylle Koczian]

Am 27.02.2016 um 19:13 schrieb wrong.addres...@gmail.com:

On Saturday, 27 February 2016 18:08:36 UTC+2, Dietmar Schwertberger  wrote:

On 27.02.2016 12:18, wrong.addres...@gmail.com wrote:

Isn't there any good GUI IDE like Visual Basic? I hope there are some less well 
known GUI IDEs which I did not come across. Thanks.


As of today, there's no Python GUI builder comparable to VB 6.



Thanks for stating this clearly. Everyone here has been trying to show me 
various ways to do the kind of things I will want to, but nobody clearly admits 
the limitations I will have to accept if I start with Python.

I am starting to wonder if VB.net would be a better solution for the time 
being. I have learnt enough VB.net to manage my work but it is bloated and 
Microsoft dependent.



Might be quite a good idea. As much as I love Python myself, the WPF GUI 
builder is very nice. Layout done declaratively, xaml really well 
documented, and I can work directly with the xaml text and see what it 
does at the same time. Code completion works, which is quite important 
with those overlong .NET names. The xaml file only contains the 
properties of controls I've set myself, not all the default values. If I 
really want to, I can drag and drop.


And the WPF has a reasonable geometry management, like PyQt, tkinter and 
PyGtk.


But then it comes to writing the code and things start getting tedious. 
So, is there a GUI library for Python that lets me _write_ declarative 
GUI descriptions, separate from the Python code, but easily connected 
with it?


Sibylle


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

Re: Everything good about Python except GUI IDE?

[Virgil Stokes]

On 2016-Feb-27 19:13, wrong.addres...@gmail.com wrote:

On Saturday, 27 February 2016 18:08:36 UTC+2, Dietmar Schwertberger  wrote:

On 27.02.2016 12:18, wrong.addres...@gmail.com wrote:

Isn't there any good GUI IDE like Visual Basic? I hope there are some less well 
known GUI IDEs which I did not come across. Thanks.

As of today, there's no Python GUI builder comparable to VB 6.


Thanks for stating this clearly. Everyone here has been trying to show me 
various ways to do the kind of things I will want to, but nobody clearly admits 
the limitations I will have to accept if I start with Python.

I am starting to wonder if VB.net would be a better solution for the time 
being. I have learnt enough VB.net to manage my work but it is bloated and 
Microsoft dependent.


There are some like QtDesigner or wxGlade, but they either don't
generate Python code directly or they can only be used if you know the
underlying toolkit good enough to create the GUI yourself. You may try
out some, but I can almost guarantee you that you will come to the same
result.
If you want a GUI, create it yourself using either wxPython or PyQt.

I will check it. I got the impression that you can create a GUI but that has to 
be converted to Python, and then you need a wrapper to put these forms in, and 
then they can be compiled or converted to *.exe with py2exe. Not a good way for 
development/debugging.


For engineering applications that's probably the weakest point that
Python has.
It's holding back a lot of people...

Well, for most measurement or control software a GUI is not really
needed, but still people want it.


In the 1980s everyone was happy with inputs from the command line on a line 
editor, but today people expect GUIs with graphics and often even animations.

It is surprising that a language which seems very popular does not have GUI 
development infrastructure in place these many years after it got into common 
use.


Regards,

Dietmar
I agree (at least largely) with the author of this email, in response to 
Dietmar. I have been working with Python for several years and often a GUI is 
needed, not by me; but, for users of my software where my target is usually 
numerical and image processing with a "don't make me think too much" GUI. I have 
mainly used wxPython (which is rather good, with good support); but, I find it 
rather awkward in practice and making an *.exe for users that includes wxPython 
is often a tedious process (at least from my own experiences). Perhaps my skills 
with wxPython and its API are lacking :-( .


After re-reading some of the postings that are connected to GUI problems in the 
python-list, wxPython-users, and PyQT, it seems to me that an "improved IDLE" 
for Python might have helped to solve some of their problems. I am quite sure 
such a development would be well received by Python beginners and those 
migrating to Python from other languages (e.g. VB).


While working on my first wxPython GUI project, I actually switched to VB to 
test my GUI design and to create an *.exe for the project --- this went rather 
fast, considering that I had no previous experience with VB. Only afterwards, 
did I return to wxPython, for implementation in Python 2.7, which took much 
longer with extensive refactoring.


And Dietmar, please don't take this the wrong way, I also agree with some of the 
points that you have made. And I do like wxPython :-)


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

Re: Everything good about Python except GUI IDE?

[Sven R. Kunze]

On 28.02.2016 07:34, Steven D'Aprano wrote:

I think that's out-and-out wrong, and harmful to the developer community. I
think that we're stuck in the equivalent of the pre-WYSIWYG days of word
processing: you can format documents as nicely as you like, but you have to
use a separate mode to see it.


Good point.


Drag-and-drop GUI builders have the same advantages over code as Python has
over languages with distinct compile/execute steps: rapid development,
prototyping, exploration and discovery. Of course, any decent modern
builder won't limit you to literally drag-and-drop, but will offer
functionality like duplicating elements, aligning them, magnetic guides,
etc.


Another good point. I will get to this later.


GUI elements are by definition graphical in nature, and like other graphical
elements, manipulation by hand is superior to command-based manipulation.
Graphical interfaces for manipulating graphics have won the UI war so
effectively that some people have forgotten there ever was a war. Can you
imagine using Photoshop without drag and drop?
(you can measure this by counting the numbers of replies to a thread)


That's whole different topic. What is Photoshop manipulating? Layers of 
pixels. That's an extremely simplified model. There is no dynamic 
behavior as there is with GUIs.



And yet programming those graphical interfaces is an exception. There, with
very few exceptions, we still *require* a command interface. Not just a
command interface, but an *off-line* command interface, where you batch up
all your commands then run them at once, as if we were Neanderthals living
in a cave.


Not sure if I agree with you here.

Let's ask ourselves, what is so different about, say, a complex 
mathematical function and a complex GUI? In other words: why do you can 
live with a text representation of that function whereas you cannot live 
with a text representation of a GUI?


One difference is the number of interactions you can do with a function 
and a GUI. A function takes some numbers whereas a GUI takes some 
complex text/mouse/finger/voice interactions.
So, I've never heard of any complains when it comes to mathematical 
functions represented in some source code. But, I've heard a lot of 
complains regarding GUI design and interaction tests (even when they are 
done graphically) -- also in WPF.


Both text representations are abstract descriptions of the real thing 
(function and GUI). You need some imagination to get them right, to 
debug them, to maintain them, to change them. We could blame Python here 
but it's due to the problem realm and to the people working there:


Functions -> mathematicians/computer scientists, work regularly with 
highly abstract objects
GUI -> designers, never really got the same education for 
programming/abstraction as the former group has


So, (and I know that from where I am involved with) GUI research 
(development, evaluation etc.) is not a topic considered closed. No 
serious computer scientist really knows the "right" way. But, hey, 
people are working on it at least.


Usually, you start out simple. As the time flies, you put in more and 
more features and things become more and more complex (we all know that 
all non-toy projects will). And so does a GUI. At a certain point, there 
is no other way than going into the code and do something nasty by 
utilizing the Turing-completeness of the underlying language. Generated 
code always looks creepy, bloaty with a lot of boilerplate. If you 
really really need to dig deeper, you will have a hard time finding out 
what of the boilerplate is really needed and what was added by the 
code-generator. In the end, you might even break the 
"drag-n-drop"ability. :-(


That is the reason, why traditional CASE tools never really got started, 
why we still need programmers, why we still have text. From my point of 
view (highly subjective), start by using general building blocks (text, 
functions, classes, ...) is better long-term; not by starting with a 
cage (the GUI) and subsequently adding more and more holes not fitting 
the original concept. History so far as agreed with this; professional 
software development always uses text tools for which LATER somebody 
built a GUI. I cannot remember it being the other way round.


Furthermore, I agree with Chris about the version control problem.

Last but not least, GUIs are a place for bike shedding because almost 
everybody is able to see them and can start having an opinion about them:

Who loves the new Windows modern UI? Either you like it or you hate it.
What about the Riemann zeta function? Anybody?


Best,
Sven

PS: another thought.

I recently introduced LaTeX to my girlfriend. LaTeX is quite ugly and it 
has this "distinct compile/execute step", so initially I hesitated to 
show it to her. But her MS Word experience got worse and worse the more 
complex (and especially larger) her workload became. Word became less 
responsive and results became even less reproduc

Re: Everything good about Python except GUI IDE?

[Dietmar Schwertberger]

On 28.02.2016 13:23, Sven R. Kunze wrote:
I recently introduced LaTeX to my girlfriend. LaTeX is quite ugly and 
it has this "distinct compile/execute step", so initially I hesitated 
to show it to her. But her MS Word experience got worse and worse the 
more complex (and especially larger) her workload became. Word became 
less responsive and results became even less reproducible (footnote 
numbering, styling, literature, etc.).
Well, MS Word is a bad example, as it's lacking even some very basic 
features like a good user interface for styles. (This is the reason why 
most people are using Word just like a typwriter instead of creating 
structured documents.)
There were and probably still are better word processors, especially for 
scientific use.


The discussion here is not about "any GUI builder", but about a "good 
and easy to use GUI builder".


Regards,

Dietmar

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

Re: Everything good about Python except GUI IDE?

[BartC]

On 28/02/2016 06:34, Steven D'Aprano wrote:


GUI elements are by definition graphical in nature, and like other graphical
elements, manipulation by hand is superior to command-based manipulation.
Graphical interfaces for manipulating graphics have won the UI war so
effectively that some people have forgotten there ever was a war. Can you
imagine using Photoshop without drag and drop?

And yet programming those graphical interfaces is an exception. There, with
very few exceptions, we still *require* a command interface. Not just a
command interface, but an *off-line* command interface, where you batch up
all your commands then run them at once, as if we were Neanderthals living
in a cave.


You've got that back to front.

It's the GUI users who are the Neanderthals, having to effectively point 
at things with sticks. Or have to physically move that rock themselves 
(ie. drag a file to a wastebasket).


More advanced uses have the power of language, with all its 
sophistications (ie. commands lines and scripting). And they don't need 
to move that rock, they can tell someone else to do it! But with far 
more control: all rocks of a certain size and colour, and at sunrise 
tomorrow.


Some things are just more easily described with a script or formula or 
algorithm which is then 'rendered' to produce the result. Not quite 
right? Change one parameter to re-render to instantly produce a new 
version, that would have taken minutes or hours to do manually.



An effective and modern GUI builder UI should be programmable without
requiring programming. About thirty years ago Apple came up with the ideal
mix of graphical and programmatic development for its Hypercard product.
You built applications by dragging and dropping widgets on the screen, or
by copying and pasting them from a library of pre-made widgets.


You have to give someone some shopping to do. What's quicker, jotting 
down a list of milk, bread, eggs and so on, or invoking some GUI program 
where you have to first look for each category, then have to choose the 
exact subcategory, size, quantity...



--
Bartc


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

Re: Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 6:08:44 PM UTC+5:30, BartC wrote:
> On 28/02/2016 06:34, Steven D'Aprano wrote:
> 
> > GUI elements are by definition graphical in nature, and like other graphical
> > elements, manipulation by hand is superior to command-based manipulation.
> > Graphical interfaces for manipulating graphics have won the UI war so
> > effectively that some people have forgotten there ever was a war. Can you
> > imagine using Photoshop without drag and drop?
> >
> > And yet programming those graphical interfaces is an exception. There, with
> > very few exceptions, we still *require* a command interface. Not just a
> > command interface, but an *off-line* command interface, where you batch up
> > all your commands then run them at once, as if we were Neanderthals living
> > in a cave.
> 
> You've got that back to front.
> 
> It's the GUI users who are the Neanderthals, having to effectively point 
> at things with sticks. Or have to physically move that rock themselves 
> (ie. drag a file to a wastebasket).

Creature A: Plays with a toy -- usually called 'child'
Creature B: Makes toys, possibly designs new ones... Can be child

Are these same?
Steven is talking of GUI *programmers*
You are talking of GUI *users*

> 
> More advanced uses have the power of language, with all its 
> sophistications (ie. commands lines and scripting). And they don't need 
> to move that rock, they can tell someone else to do it! But with far 
> more control: all rocks of a certain size and colour, and at sunrise 
> tomorrow.

You seem to have a rather limited view of language.
Math is a language
Music is a language -- and sophisticated music analysis can slot music
according to genre etc
So also GUIs


> 
> Some things are just more easily described with a script or formula or 
> algorithm which is then 'rendered' to produce the result. Not quite 
> right? Change one parameter to re-render to instantly produce a new 
> version, that would have taken minutes or hours to do manually.
> 
> > An effective and modern GUI builder UI should be programmable without
> > requiring programming. About thirty years ago Apple came up with the ideal
> > mix of graphical and programmatic development for its Hypercard product.
> > You built applications by dragging and dropping widgets on the screen, or
> > by copying and pasting them from a library of pre-made widgets.
> 
> You have to give someone some shopping to do. What's quicker, jotting 
> down a list of milk, bread, eggs and so on, or invoking some GUI program 
> where you have to first look for each category, then have to choose the 
> exact subcategory, size, quantity...

Dunno what that has to do with GUI
It seems to be to do with 'coding-up'
The string "milk" codes up milk more efficiently than category navigation
and manipulation

That programmers are 50 years behind laypersons in terms of computer USAGE:
http://blog.languager.org/2013/09/poorest-computer-users-are-programmers.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Sun, 28 Feb 2016 07:44 pm, Chris Angelico wrote:

> On Sun, Feb 28, 2016 at 5:34 PM, Steven D'Aprano 
> wrote:
[...]
>> Drag-and-drop GUI builders have the same advantages over code as Python
>> has over languages with distinct compile/execute steps: rapid
>> development, prototyping, exploration and discovery. Of course, any
>> decent modern builder won't limit you to literally drag-and-drop, but
>> will offer functionality like duplicating elements, aligning them,
>> magnetic guides, etc.
> 
> Alright, but how do you go about doing, with a drag-and-drop builder,
> all those things we're used to with code - composing new named actions
> out of primitives, observing the changes to a program through source
> control, unit testing (maybe), and code review? 

These are all good questions. Let's see if I can give good answers:

(1) "composing new named actions" -- I'm not entirely sure what you mean. Do
you mean new named *widgets*? A good builder app should give you the
ability to Group widgets into a single element, this is functionality which
has existed in vector-drawing programs since at least MacDraw in 1984 so it
shouldn't be hard. This is composition, a fundamental, powerful and rich
design pattern for making new widgets (classes) out of simpler parts. If
objects have a name, now you can refer to CompositeMenuDateColourPicker by
name. You can copy it, paste it, replicate it 30 times, whatever you like.

Possibly the GUI builder will even add it to the "Insert Widget" menu, or
put it on the toolbar. Surely the builder app will use a plug-in
architecture to control what widgets are available. How easy is it to
create new plug-ins from within the builder? This is a "quality of
implementation" issue.

Presumably a modern GUI builder will have the ability to export to source
code, so you can export your CompositeMenuDateColourPicker to a file, then
re-use it over and over again in project after project.


(2) "source control" -- the world is full of document types that aren't
plain text source code, and people have found ways to manage collaborative
editing and change management for them. Why don't we ask game developers
how they manage changes to the non-code elements in their applications?
Textures, icons, player avatars, sound effects, maps, etc. Surely you don't
suggest that game developers edit their background images in a hex editor?

(3) "unit testing" -- I'm not sure that unit testing is what is needed for
the GUI elements of your application. It's more like integration testing,
to ensure that the entire application works together as a seamless whole.
I'm not sure what the state of the art in GUI application integration
testing is like. I suspect crap, judging by the state of the art in GUI
applications.

But whatever it is, it will surely operate the same regardless of whether
you have built the application using code or a graphical builder.

(The GUI framework itself may have some analogue to unit testing for the
individual widgets, but that's not your responsibility as the user of the
framework. It's not up to you to test that menus drop down when clicked,
but it is your responsibility to check that the right menus exist and that
they do what they are supposed to.)

(4) "code review" -- the usual way to review the graphical elements of a GUI
app is to call somebody over, sit them down at the running application, and
say "What do you think of this?". They will usually answer "that icon needs
to be a bit more to the left, and can you make that button blue instead of
green?".



> The only way I know of 
> to build a "function" in a DnD builder is to create a composite widget
> (eg "horizontal box containing label and entry field"), which is
> extremely useful, but limited - it's like saying that the only way to
> reuse code is single-inheritance.

A poor analogy. Composition is equivalent to multiple inheritance, except
without any of the weaknesses of MI.


> How would you create a higher-order 
> operation in a DnD builder? How would you write something that does
> some sort of sweep over a set of widgets and does the same thing to
> them?

In Hypercard, if it was a once-off processing task, I would create a button,
edit the button's script:

on mouseUp:
  -- my memory of HC syntax and functions is a bit rusty
  -- this may not be correct
  for btnNum in 1 to the number of buttons:
if btnNum is the number of me:
  continue
end if
set the textsize of button btnNum to 9
set the textstyle of button btnNum to bold,italic
if the name of button btnNum starts with "Spam":
  set the icon of button btnNum to SpamIcon
end if
  end for
end mouseUp

then I would click on that button and run the script. Then, once I have
satisfied myself that it has done what was needed, I'd delete the button.

If this was something that needed to run each time the application ran, I
would put the script in some other layer of the application, say, in the
card layer, in a named handler:

on 

Re: Everything good about Python except GUI IDE?

[cl]

Dietmar Schwertberger  wrote:
> On 28.02.2016 13:23, Sven R. Kunze wrote:
> > I recently introduced LaTeX to my girlfriend. LaTeX is quite ugly and 
> > it has this "distinct compile/execute step", so initially I hesitated 
> > to show it to her. But her MS Word experience got worse and worse the 
> > more complex (and especially larger) her workload became. Word became 
> > less responsive and results became even less reproducible (footnote 
> > numbering, styling, literature, etc.).
> Well, MS Word is a bad example, as it's lacking even some very basic 
> features like a good user interface for styles. (This is the reason why 
> most people are using Word just like a typwriter instead of creating 
> structured documents.)
> There were and probably still are better word processors, especially for 
> scientific use.
> 
E.g. Latex or reStructuredText, not GUI.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: list index out of range Error , need to fix it or ignore it

[Steven D'Aprano]

On Sun, 28 Feb 2016 03:50 am, Ganesh Pal wrote:

> Iam on python 2.6 and Linux , I need  input on the below program ,
> here is the spinet of my program
> 
> 
> filename='/tmp2/2.txt'
> 
> def check_file():
> """
>  Run the command parallel on all the machines , if there is a
> file named /tmp/file2.txt  extract file2.txt
> 
> """
> global filename

Since filename is never assigned to inside the function, you don't need to
declare it global.

But better is to make the filename an argument of the function. That will
allow you to check for different files, not always the same one.


> baddr = ''

Not used. Get rid of it.


> cmd = ("run_al_paral 'ls -al %s'" % (filename))
> print(cmd)
> stdout, stderr, exitcode = run(cmd)

run is not defined.


> print(stdout)
> lines = stdout.strip().split('\n')
> print(lines)
> for line in lines:
> if 'exited' in lines:
> continue
> file = lines[0].split()[9][6:]
> break
> print file
> return file
> 
> def main():
> functions = [check_file]
> for func in functions:
> try:
> func()
> except Exception as e:
> return False

Why do you bother to return False? Nothing checks the return value of
main().

As far as the try...except block, please read this:

https://realpython.com/blog/python/the-most-diabolical-python-antipattern/



> if __name__ == '__main__':
>   main()
> 
> 
> 
> 1.If the file is present in any one of the machine the program works
> fine , example if the file is in machine4 it works fine,
> 
> 
> machine-4# touch /tmp2/2.txt
> machine-4# python c_4.py
> run_al_parall 'ls -al /tmp2/2.txt'
> machine-4: -rw-r--r-- 1 root  wheel  0 Feb 27 08:15 /tmp2/2.txt
> gpal-machine-2 exited with status 1
> gpal-machine-5 exited with status 1
> gpal-machine-3 exited with status 1
> gpal-machine-1 exited with status 1

You really should get out of the bad habit of running code as root. Once day
you will accidentally have a bug in your code that will do something it
shouldn't do (like delete the root file system) and leave your machine
unusable.

You should create a user with the minimum privileges needed to get the work
done. At the very least, you should TEST your code while running as an
unprivileged user. It is very dangerous to run buggy code as root. Who
knows what it will do?


> 2. But if the file is not present we get index out of range error , do
> we need to fix this or its expected ? or its ok.

Of course you need to fix it.

There's no way of telling where that error occurs or why it is being
printed.




-- 
Steven

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

Re: Everything good about Python except GUI IDE?

[Gordon Levi]

Chris Angelico  wrote:

>On Sun, Feb 28, 2016 at 9:25 PM, Rustom Mody  wrote:
>> Code is always the last resort for arbitrary complexity
>> Lets keep it the last resort.
>>
>> If the bottom-line is that python's GUI-builders are so deep into suxland
>> that they are best avoided in place of hand-written code, thats fine (by me).
>>
>> Lets please not make a virtue of a lack
>
>Once someone figures out a way to usefully merge independent changes
>(you know, the way source control tools do every single day for code),
>maybe I'll consider that. Until then, the last resort is also my first
>response.

Why can't whatever is generated by a GUI form designer be stored in
source control along with all the other project files? The only
restriction would be that everyone who wants to change the UI would
have to use the same form designer.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[BartC]

On 28/02/2016 12:54, Rustom Mody wrote:

On Sunday, February 28, 2016 at 6:08:44 PM UTC+5:30, BartC wrote:



You have to give someone some shopping to do. What's quicker, jotting
down a list of milk, bread, eggs and so on, or invoking some GUI program
where you have to first look for each category, then have to choose the
exact subcategory, size, quantity...


Dunno what that has to do with GUI
It seems to be to do with 'coding-up'



It's comparing a drag-and-drop approach with just writing a list or 
script using text. And in a situation where there can be thousands of 
possibilities.


To extend it further, imagine having to write a document using a mouse 
rather than a keyboard. And doing so by having to bring up the right 
word each time and drag it into place. It would take forever.


Going back to GUI for creating dialogs, it just doesn't work for me 
(admittedly I've never tried it except for some tinkering decades ago). 
The first dialog I create will be bound to have a conditional layout 
which depends on parameters now known until runtime. Or when one element 
has a dependency on another.



--
Bartc


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

Re: Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 6:38:40 PM UTC+5:30, Gordon Levi wrote:
> Chris Angelico  wrote:
> 
> >On Sun, Feb 28, 2016 at 9:25 PM, Rustom Mody wrote:
> >> Code is always the last resort for arbitrary complexity
> >> Lets keep it the last resort.
> >>
> >> If the bottom-line is that python's GUI-builders are so deep into suxland
> >> that they are best avoided in place of hand-written code, thats fine (by 
> >> me).
> >>
> >> Lets please not make a virtue of a lack
> >
> >Once someone figures out a way to usefully merge independent changes
> >(you know, the way source control tools do every single day for code),
> >maybe I'll consider that. Until then, the last resort is also my first
> >response.
> 
> Why can't whatever is generated by a GUI form designer be stored in
> source control along with all the other project files? The only
> restriction would be that everyone who wants to change the UI would
> have to use the same form designer.

Glade generates XML (last I saw)
XML is text... kinda... but not quite
eg XML is sometimes/somewhere space sensitive, sometimes not
This can generate messy diffs

Best I can see, these are not exactly trivial nor quite impossible to solve 
problems
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Dietmar Schwertberger]

On 28.02.2016 13:52, c...@isbd.net wrote:

Dietmar Schwertberger  wrote:

There were and probably still are better word processors, especially for
scientific use.

E.g. Latex or reStructuredText, not GUI.


I was more thinking of TechWriter on RISC OS. For Windows there are 
probably similar offerings.


Try selling LaTex as standard word processor to a corporate environment. 
I guarantee you that you will fail.



Regards,

Dietmar

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

Re: Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 6:37:49 PM UTC+5:30, BartC wrote:
> On 28/02/2016 12:54, Rustom Mody wrote:
> > On Sunday, February 28, 2016 at 6:08:44 PM UTC+5:30, BartC wrote:
> 
> >> You have to give someone some shopping to do. What's quicker, jotting
> >> down a list of milk, bread, eggs and so on, or invoking some GUI program
> >> where you have to first look for each category, then have to choose the
> >> exact subcategory, size, quantity...
> >
> > Dunno what that has to do with GUI
> > It seems to be to do with 'coding-up'
> 
> 
> It's comparing a drag-and-drop approach with just writing a list or 
> script using text. And in a situation where there can be thousands of 
> possibilities.
> 
> To extend it further, imagine having to write a document using a mouse 
> rather than a keyboard. And doing so by having to bring up the right 
> word each time and drag it into place. It would take forever.
> 
> Going back to GUI for creating dialogs, it just doesn't work for me 
> (admittedly I've never tried it except for some tinkering decades ago). 
> The first dialog I create will be bound to have a conditional layout 
> which depends on parameters now known until runtime. Or when one element 
> has a dependency on another.

Your argument assumes
GUI = not Text Interface

whereas in fact every significant GUI embeds text (possibly recursively)

eg TI inside GUI -- think of text inside gimp
GUI inside TI -- think of Word embedding other doc types including pictures
Which can be recursive -- WOrd embeds a picture embeds text
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Gordon Levi]

Rustom Mody  wrote:

>On Sunday, February 28, 2016 at 6:38:40 PM UTC+5:30, Gordon Levi wrote:
>> Chris Angelico  wrote:
>> 
>> >On Sun, Feb 28, 2016 at 9:25 PM, Rustom Mody wrote:
>> >> Code is always the last resort for arbitrary complexity
>> >> Lets keep it the last resort.
>> >>
>> >> If the bottom-line is that python's GUI-builders are so deep into suxland
>> >> that they are best avoided in place of hand-written code, thats fine (by 
>> >> me).
>> >>
>> >> Lets please not make a virtue of a lack
>> >
>> >Once someone figures out a way to usefully merge independent changes
>> >(you know, the way source control tools do every single day for code),
>> >maybe I'll consider that. Until then, the last resort is also my first
>> >response.
>> 
>> Why can't whatever is generated by a GUI form designer be stored in
>> source control along with all the other project files? The only
>> restriction would be that everyone who wants to change the UI would
>> have to use the same form designer.
>
>Glade generates XML (last I saw)
>XML is text... kinda... but not quite
>eg XML is sometimes/somewhere space sensitive, sometimes not
>This can generate messy diffs

That is also true of Python code but does not preclude effective
source control.
>
>Best I can see, these are not exactly trivial nor quite impossible to solve 
>problems
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote:
> Rustom Mody  wrote:
> >Glade generates XML (last I saw)
> >XML is text... kinda... but not quite
> >eg XML is sometimes/somewhere space sensitive, sometimes not
> >This can generate messy diffs
> 
> That is also true of Python code but does not preclude effective
> source control.

Yes as I said its not satisfactory but not impossible to manage

Heck Current state of art VCSes cannot even manage mismatching EOL conventions
cleanly.
And as usual they make a virtue out of the lack: 
"git stores binary data not text"

which means that opening a file created on windows on linux and saving it in 
WITHOUT a SINGLE CHANGE
can give you a 10,000 line diff!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Rustom Mody :

> whereas in fact every significant GUI embeds text (possibly recursively)
>
> eg TI inside GUI -- think of text inside gimp
> GUI inside TI -- think of Word embedding other doc types including pictures
> Which can be recursive -- WOrd embeds a picture embeds text

Sigh, still nobody has mentioned an exemplary GUI application.

An anecdote: Some weeks back my son and I were struggling to get the
right kind of graph out of Excel. After four hours of Google, Youtube,
trial and error, we gave up, took out a pad of millimeter paper and some
colored pencils. The whole job took my son an hour and the end result
looked great. He snapped a picture and sent it to the teacher by email.

A 2nd anecdote. I occasionally need to make technical presentations to
an audience. Do I use PowerPoint or Impress? No, I use emacs, M-x
picture-mode and raw HTML (without styles). I get to concentrate on
producing effective communication, and nobody has complained about the
lack of imagery or funny animation.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Chris Warrick]

On 28 February 2016 at 14:49, Rustom Mody  wrote:
> On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote:
>> Rustom Mody  wrote:
>> >Glade generates XML (last I saw)
>> >XML is text... kinda... but not quite
>> >eg XML is sometimes/somewhere space sensitive, sometimes not
>> >This can generate messy diffs
>>
>> That is also true of Python code but does not preclude effective
>> source control.
>
> Yes as I said its not satisfactory but not impossible to manage
>
> Heck Current state of art VCSes cannot even manage mismatching EOL conventions
> cleanly.
> And as usual they make a virtue out of the lack:
> "git stores binary data not text"
>
> which means that opening a file created on windows on linux and saving it in
> WITHOUT a SINGLE CHANGE
> can give you a 10,000 line diff!!

You clearly haven’t ever done that.

1. git can manage EOL changing if you want to enforce a newline style that way.
2. A good editor can read and write any newline style. It should also
not convert without asking the user.

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 7:22:08 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
> 
> > whereas in fact every significant GUI embeds text (possibly recursively)
> >
> > eg TI inside GUI -- think of text inside gimp
> > GUI inside TI -- think of Word embedding other doc types including pictures
> > Which can be recursive -- WOrd embeds a picture embeds text
> 
> Sigh, still nobody has mentioned an exemplary GUI application.
> 
> An anecdote: Some weeks back my son and I were struggling to get the
> right kind of graph out of Excel. After four hours of Google, Youtube,
> trial and error, we gave up, took out a pad of millimeter paper and some
> colored pencils. The whole job took my son an hour and the end result
> looked great. He snapped a picture and sent it to the teacher by email.

Point being??
If I tried to speak Finnish I'd look a fool.
Makes me a fool?

Best I can see you dont know excel [Nor do I]
Lets guess that you've spent 10 hours struggling with excel
Now compare with how much with programming and 'classical' CS
Would a couple of thousand hours be an overestimate?
Is the inherent difficulty of excel to programming consistent with that ratio?

> 
> A 2nd anecdote. I occasionally need to make technical presentations to
> an audience. Do I use PowerPoint or Impress? No, I use emacs, M-x
> picture-mode and raw HTML (without styles). I get to concentrate on
> producing effective communication, and nobody has complained about the
> lack of imagery or funny animation.

Yeah so do I
emacs → org mode → export html

Works but not ideal
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 7:30:57 PM UTC+5:30, Chris Warrick wrote:
> On 28 February 2016 at 14:49, Rustom Mody  wrote:
> > On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote:
> >> Rustom Mody  wrote:
> >> >Glade generates XML (last I saw)
> >> >XML is text... kinda... but not quite
> >> >eg XML is sometimes/somewhere space sensitive, sometimes not
> >> >This can generate messy diffs
> >>
> >> That is also true of Python code but does not preclude effective
> >> source control.
> >
> > Yes as I said its not satisfactory but not impossible to manage
> >
> > Heck Current state of art VCSes cannot even manage mismatching EOL 
> > conventions
> > cleanly.
> > And as usual they make a virtue out of the lack:
> > "git stores binary data not text"
> >
> > which means that opening a file created on windows on linux and saving it in
> > WITHOUT a SINGLE CHANGE
> > can give you a 10,000 line diff!!
> 

> 
> 2. A good editor can read and write any newline style. It should also
> not convert without asking the user.

git is a *collaborative* tool and should work when the other party is using
notepad.

> 1. git can manage EOL changing if you want to enforce a newline style that 
> way.
Only out-of-band
You store autocrlf etc in your config not in the repo
[And pray that the other (semi-literate) collaborator does likewise]

> You clearly haven't ever done that.
You specialize in crystal balls?

Here's my report about CRLF issues in CPython
https://mail.python.org/pipermail/python-dev/2015-June/140563.html

Bug report: http://bugs.python.org/issue24507
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Chris Warrick]

On 28 February 2016 at 15:11, Rustom Mody  wrote:
> On Sunday, February 28, 2016 at 7:30:57 PM UTC+5:30, Chris Warrick wrote:
>> On 28 February 2016 at 14:49, Rustom Mody  wrote:
>> > On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote:
>> >> Rustom Mody  wrote:
>> >> >Glade generates XML (last I saw)
>> >> >XML is text... kinda... but not quite
>> >> >eg XML is sometimes/somewhere space sensitive, sometimes not
>> >> >This can generate messy diffs
>> >>
>> >> That is also true of Python code but does not preclude effective
>> >> source control.
>> >
>> > Yes as I said its not satisfactory but not impossible to manage
>> >
>> > Heck Current state of art VCSes cannot even manage mismatching EOL 
>> > conventions
>> > cleanly.
>> > And as usual they make a virtue out of the lack:
>> > "git stores binary data not text"
>> >
>> > which means that opening a file created on windows on linux and saving it 
>> > in
>> > WITHOUT a SINGLE CHANGE
>> > can give you a 10,000 line diff!!
>>
>
>>
>> 2. A good editor can read and write any newline style. It should also
>> not convert without asking the user.
>
> git is a *collaborative* tool and should work when the other party is using
> notepad.

What should git do if someone saves, say, Ruby code as a .py file?
Should it rename it? Or should it figure out an equivalent snippet of
Python?

You probably have some rules in your project such as “Code must be
written in Python” or “Use 4-space soft tabs”. Your rulebook should
also include “Use an editor that understands LF line endings”. Notepad
is a joke that you should not tolerate. Problem solved.

(Notepad does not understand LF line endings and replaces them with
boxes. I also don’t think a Notepad user is likely to provide good
contributions, but that’s another thing)

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[BartC]

On 28/02/2016 14:03, Rustom Mody wrote:

On Sunday, February 28, 2016 at 7:22:08 PM UTC+5:30, Marko Rauhamaa wrote:

Rustom Mody :


whereas in fact every significant GUI embeds text (possibly recursively)

eg TI inside GUI -- think of text inside gimp
GUI inside TI -- think of Word embedding other doc types including pictures
Which can be recursive -- WOrd embeds a picture embeds text


Sigh, still nobody has mentioned an exemplary GUI application.

An anecdote: Some weeks back my son and I were struggling to get the
right kind of graph out of Excel. After four hours of Google, Youtube,
trial and error, we gave up, took out a pad of millimeter paper and some
colored pencils. The whole job took my son an hour and the end result
looked great. He snapped a picture and sent it to the teacher by email.


Point being??
If I tried to speak Finnish I'd look a fool.
Makes me a fool?

Best I can see you dont know excel [Nor do I]
Lets guess that you've spent 10 hours struggling with excel
Now compare with how much with programming and 'classical' CS
Would a couple of thousand hours be an overestimate?
Is the inherent difficulty of excel to programming consistent with that ratio?


Some programs are just difficult to use. Yes maybe you can achieve 
something with enough knowledge and training, but then you're getting 
the result despite the obstacles put in your way rather than because the 
software is so helpful.


20 years ago, when these things were simpler, MS Word had a mind of its 
own even then. I had to produce a manual of few hundred pages, with 
diagrams and images, and it just wasn't going to happen. Not without 
spending a year on it. And employing someone to do it cost thousands.


In the end I spent a week or two throwing together some simple mark-up 
language, written in my own editor, which was then processed by my own 
script language and ending up (via my own graphics software along the 
way) as Postscript. The results were perfect.


(Have you ever had a situation where you have to edit a bit of text 
where a word is in italic or has some particular style. You delete the 
word, and try and add some more text, but it persists in using the style 
of the deleted text rather than the current style. You move further 
away; still the same. You end up deleting everything including every 
trace of that word and its style. Yet start typing on a now blank 
document, and it's still the wrong style!


That's what I mean by these applications having minds of their own. And 
with a 300-page document you can't just start all over, you need 
something reliable, and not so smart.)


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Rustom Mody :

> On Sunday, February 28, 2016 at 7:22:08 PM UTC+5:30, Marko Rauhamaa wrote:
>> Rustom Mody :
>> 
>> > whereas in fact every significant GUI embeds text (possibly
>> > recursively)
>> >
>> > eg TI inside GUI -- think of text inside gimp GUI inside TI --
>> > think of Word embedding other doc types including pictures Which
>> > can be recursive -- WOrd embeds a picture embeds text
>> 
>> Sigh, still nobody has mentioned an exemplary GUI application.
>> 
>> An anecdote: Some weeks back my son and I were struggling to get the
>> right kind of graph out of Excel. After four hours of Google,
>> Youtube, trial and error, we gave up, took out a pad of millimeter
>> paper and some colored pencils. The whole job took my son an hour and
>> the end result looked great. He snapped a picture and sent it to the
>> teacher by email.
>
> Point being??

I'm awaiting for an opposite anecdote, a GUI app you absolutely love and
recommend as a model for GUI developers.

We are talking about GUI tools to produce what? Crap?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 8:38:49 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
> 
> > On Sunday, February 28, 2016 at 7:22:08 PM UTC+5:30, Marko Rauhamaa wrote:
> >> Rustom Mody :
> >> 
> >> > whereas in fact every significant GUI embeds text (possibly
> >> > recursively)
> >> >
> >> > eg TI inside GUI -- think of text inside gimp GUI inside TI --
> >> > think of Word embedding other doc types including pictures Which
> >> > can be recursive -- WOrd embeds a picture embeds text
> >> 
> >> Sigh, still nobody has mentioned an exemplary GUI application.
> >> 
> >> An anecdote: Some weeks back my son and I were struggling to get the
> >> right kind of graph out of Excel. After four hours of Google,
> >> Youtube, trial and error, we gave up, took out a pad of millimeter
> >> paper and some colored pencils. The whole job took my son an hour and
> >> the end result looked great. He snapped a picture and sent it to the
> >> teacher by email.
> >
> > Point being??
> 
> I'm awaiting for an opposite anecdote, a GUI app you absolutely love and
> recommend as a model for GUI developers.

GUI app I absolutely love... um hard
But what does it prove?
Best I can see it proves I am an old (Unix) geezer brought up on text files :-)

Still as an approximation...
I edit audio with audacity
And type music with musescore

Both could be better (And Ive heard people swear by ardour... No experience 
myself)

The alternative -- stay with lilypond workflow -- is too primitive
In particular if musescore could input and output to lilypond or some such
it would have been optimal

...for me; ie clickety clicking 100s of notes is painful compared to typing 
them in say emacs

For a much more professional pianist friend: 
He connects a small 2 octave keyboard to his mac
Plays out what he needs to enter
And then cleans it up... in Sibelius
> 
> We are talking about GUI tools to produce what? Crap?

You (seem to) be saying that excel is crap.
Do you know it well enough to make that judgement?
Do you have equivalent functionality in some other tool?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Rustom Mody]

On Sunday, February 28, 2016 at 7:57:17 PM UTC+5:30, Chris Warrick wrote:
> (Notepad does not understand LF line endings and replaces them with
> boxes. I also don't think a Notepad user is likely to provide good
> contributions, but that's another thing)

You seem to have not worked in a web dev team wherein the frontend guys only 
know 3 tools

- dreamweaver
- photoshop
- notepad
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Mark Lawrence]

On 28/02/2016 14:00, Chris Warrick wrote:

On 28 February 2016 at 14:49, Rustom Mody  wrote:

On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote:

Rustom Mody  wrote:

Glade generates XML (last I saw)
XML is text... kinda... but not quite
eg XML is sometimes/somewhere space sensitive, sometimes not
This can generate messy diffs


That is also true of Python code but does not preclude effective
source control.


Yes as I said its not satisfactory but not impossible to manage

Heck Current state of art VCSes cannot even manage mismatching EOL conventions
cleanly.
And as usual they make a virtue out of the lack:
"git stores binary data not text"

which means that opening a file created on windows on linux and saving it in
WITHOUT a SINGLE CHANGE
can give you a 10,000 line diff!!


You clearly haven’t ever done that.

1. git can manage EOL changing if you want to enforce a newline style that way.
2. A good editor can read and write any newline style. It should also
not convert without asking the user.



Those who can, do, those who can't, teach?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

Re: Everything good about Python except GUI IDE?

[Dietmar Schwertberger]

On 28.02.2016 18:03, Dennis Lee Bieber wrote:

Office 2002 (or was it 2003... Whatever I had on my WinXP box) was, I
thought, rather easy to work styles in... Automatically shifting from
header to body text style on ; Having first body paragraph after a
header use block format while subsequent paragraphs used indented format...
The style editor was always crappy. Most people won't notice due to the 
lack of comparison.
Word processors like Fireworkz and TechWriter got it right to handle 
layered styles and effects. Easy to edit and easy to apply. And also 
easy to get rid of them again with a region editor which made it easy to 
select all modifications that were applied to a text and to delete or 
modify them.

In comparison, MS Word is a mechanical typewriter.

Regards,

Dietmar

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

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Sun, Feb 28, 2016 at 11:50 PM, Steven D'Aprano  wrote:
> On Sun, 28 Feb 2016 07:44 pm, Chris Angelico wrote:
>
>> On Sun, Feb 28, 2016 at 5:34 PM, Steven D'Aprano 
>> wrote:
> [...]
>>> Drag-and-drop GUI builders have the same advantages over code as Python
>>> has over languages with distinct compile/execute steps: rapid
>>> development, prototyping, exploration and discovery. Of course, any
>>> decent modern builder won't limit you to literally drag-and-drop, but
>>> will offer functionality like duplicating elements, aligning them,
>>> magnetic guides, etc.
>>
>> Alright, but how do you go about doing, with a drag-and-drop builder,
>> all those things we're used to with code - composing new named actions
>> out of primitives, observing the changes to a program through source
>> control, unit testing (maybe), and code review?
>
> These are all good questions. Let's see if I can give good answers:
>
> (1) "composing new named actions" -- I'm not entirely sure what you mean. Do
> you mean new named *widgets*? A good builder app should give you the
> ability to Group widgets into a single element, this is functionality which
> has existed in vector-drawing programs since at least MacDraw in 1984 so it
> shouldn't be hard. This is composition, a fundamental, powerful and rich
> design pattern for making new widgets (classes) out of simpler parts. If
> objects have a name, now you can refer to CompositeMenuDateColourPicker by
> name. You can copy it, paste it, replicate it 30 times, whatever you like.

A good number of GUI builders do offer this functionality -
composition. (Even some of what we would call primitives are actually
composed of multiple widgets; a drop-down combo box is an entry field,
a button, and a possibly-hidden list box.) But there are other actions
than "put this widget here". For example, you could go and adjust some
widget's size or style, or reposition it according to some new rules
(hopefully most of your positioning rules can be codified, eg "use a
grid layout, put this in this cell", but a lot of the people who ask
for drag-and-drop GUI building are thinking in terms of "place this
right here", rather than using layout managers; and sometimes there
are rules that don't really fit the layout manager per se, or are
layered on top of the layout manager's rules). These kinds of actions
can be represented as functions and then applied everywhere, such that
you can change the precise appearance by editing that one function.
For example, I have a Dungeons & Dragons character sheet display, in
which there are large numbers of entry fields (editable), labels
(non-editable display, usually calculated from other fields), and less
commonly, drop-down lists and multi-line text fields. Call that four
primitives. Now, some of the fields need to be highlighted for the
human's attention ("this is the actual value you want to be reading,
most of the time"). Currently, I do this with a blue border around it
and its label. Okay, so I can no doubt create a "readme display"
widget that has the border (a GTK2 Frame) and two labels; and then a
"readme editable" with the border, one label, and one entry field.
That's already split it out into two options, where a parameterized
function could simply generate a border, a label, and *whatever object
it was given*. And what if I want to change the look of those readme
objects? What if, instead of surrounding them with a Frame, I want to
put a little icon to the right of them? With code, all I have to do is
change the definition of the function; it still takes a widget and
returns a widget, but now it returns (say) a horizontal box containing
a label, the provided widget, and the icon. With a GUI builder, how do
you redefine a function that isn't just simple composition?

This additional meta-level is one that is absent from a *lot* of
modern graphical environments. Look at spreadsheets - the classic
Lotus 1-2-3 model has stayed with us all through, with MS Excel, OO/LO
Calc, etc, etc generally following it. And that's fine; spreadsheets
do a lot of very good work for a lot of people. Now, suppose in cell
C2 you have this formula: "=A2+B2*.05". You can copy that down the
rest of the column, and C9 will say "=A9+B9*.05", and so on; that's
what spreadsheets do well. But once you've done that copy operation,
those cells lose all track of the fact that they got their formula
from C2. If you edit C2, you have to re-copy-down. That's not too hard
for a lot of people to remember, but what happens when that's
forgotten? In a spreadsheet with huge numbers of calculated cells, how
are you going to debug the "oops I forgot to re-copy that" problem?
There is nothing in the document itself that helps you; if you see
that C2 has "=A2+B2*.051" and that this pattern continues down as far
as C10 but no further, do you assume that someone was tinkering and
didn't edit all down the column (which is tedious), or do you assume
that it's intentional? (Of course, the tendency for s

Re: Everything good about Python except GUI IDE?

[mm0fmf]

On 27/02/2016 18:13, wrong.addres...@gmail.com wrote:

On Saturday, 27 February 2016 18:08:36 UTC+2, Dietmar Schwertberger  wrote:

On 27.02.2016 12:18, wrong.addres...@gmail.com wrote:

Isn't there any good GUI IDE like Visual Basic? I hope there are some less well 
known GUI IDEs which I did not come across. Thanks.


As of today, there's no Python GUI builder comparable to VB 6.



Thanks for stating this clearly. Everyone here has been trying to show me 
various ways to do the kind of things I will want to, but nobody clearly admits 
the limitations I will have to accept if I start with Python.

I am starting to wonder if VB.net would be a better solution for the time 
being. I have learnt enough VB.net to manage my work but it is bloated and 
Microsoft dependent.


There are some like QtDesigner or wxGlade, but they either don't
generate Python code directly or they can only be used if you know the
underlying toolkit good enough to create the GUI yourself. You may try
out some, but I can almost guarantee you that you will come to the same
result.
If you want a GUI, create it yourself using either wxPython or PyQt.


I will check it. I got the impression that you can create a GUI but that has to 
be converted to Python, and then you need a wrapper to put these forms in, and 
then they can be compiled or converted to *.exe with py2exe. Not a good way for 
development/debugging.



For engineering applications that's probably the weakest point that
Python has.
It's holding back a lot of people...

Well, for most measurement or control software a GUI is not really
needed, but still people want it.



In the 1980s everyone was happy with inputs from the command line on a line 
editor, but today people expect GUIs with graphics and often even animations.

It is surprising that a language which seems very popular does not have GUI 
development infrastructure in place these many years after it got into common 
use.



Regards,

Dietmar




I'm no C# expert but I inherited the support of some C# projects. One 
uses a form to hold the UI objects. When the program is loaded in VS, 
you see the form and you can drag and drop objects to the form and edit 
the object properties (text, font, colours etc.). The result of your 
visual work is rendered in the C# source with some code folding options. 
If you don't click the folds in the editor you don't get to see that the 
form editor generates the C# code you need to call to generate the 
objects. There are suitable comments through the generated code warning 
you not to edit it as it is regenerated etc.


The result is you use a visual tool to generate the boiler plate code. 
Knowing MS tools I'd be very suprised if the same idea is not used in 
VB. Somewhere there will be a text file with the VB boilerplate code to 
generate the form.


You need to locate that and use it to drive your VB to Python conversion 
process. I'd write myself a script that takes the autogenerated source 
and converts it to Python. You may need to polish the output but if you 
have hundreds of objects this sounds to be simpler and quicker than 
starting from scratch.


This is from my experience using C# with ASP.NET and .Net 4.0+ and 
VS2010 Professional. I think I've played with VS2013 Pro and it's the same.


YMMV.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Dietmar Schwertberger]

On 28.02.2016 19:47, mm0fmf wrote:
I'm no C# expert but I inherited the support of some C# projects. One 
uses a form to hold the UI objects. When the program is loaded in VS, 
you see the form and you can drag and drop objects to the form and 
edit the object properties (text, font, colours etc.). The result of 
your visual work is rendered in the C# source with some code folding 
options. If you don't click the folds in the editor you don't get to 
see that the form editor generates the C# code you need to call to 
generate the objects. There are suitable comments through the 
generated code warning you not to edit it as it is regenerated etc.


The result is you use a visual tool to generate the boiler plate code. 
Knowing MS tools I'd be very suprised if the same idea is not used in 
VB. Somewhere there will be a text file with the VB boilerplate code 
to generate the form. 
The VB 6 setup was different. GUI editor, IDE and runtime were tightly 
integrated.
In VB 6, you don't see such boiler plate code. You only see the form, 
the textual representation of the form and the code that you enter into 
the event handlers etc. The form is then rendered by the VB runtime.
But what you outlined for C# is probably the way that the ideal Python 
GUI editor would go. When you think about how a RAD tool could look like 
and how to integrate with IDEs, you automatically come to such a setup 
with comments as markers/separators for the automatically generated code.


Regards,

Dietmar
--
https://mail.python.org/mailman/listinfo/python-list

Re: list index out of range Error , need to fix it or ignore it

[Oscar Benjamin]

On 27 February 2016 at 16:50, Ganesh Pal  wrote:
> Iam on python 2.6 and Linux , I need  input on the below program ,
> here is the spinet of my program

It would be much better if you presented a complete program here.
Otherwise the missing parts will confuse people. See:
http://sscce.org/

> filename='/tmp2/2.txt'
>
> def check_file():
> """
>  Run the command parallel on all the machines , if there is a
> file named /tmp/file2.txt  extract file2.txt
>
> """
> global filename
> baddr = ''
> cmd = ("run_al_paral 'ls -al %s'" % (filename))
> print(cmd)
> stdout, stderr, exitcode = run(cmd)
> print(stdout)
> lines = stdout.strip().split('\n')

.splitlines() is more portable than .split('\n') as it handles '\r' as well.

> print(lines)

There are a few problems with the code below:

> for line in lines:
> if 'exited' in lines:
> continue
>
> file = lines[0].split()[9][6:]

Okay so you're skipping lines that contain the text "exited" in order
to find the line you want. That's fine except that you then try to
access the line you've found as lines[0] rather than line (singular).
This means that although your loop continues when the line contains
"exited" you're still accessing the first element of lines (which may
be one of the ones that contains "exited") in any case. I think that
you meant line rather than lines[0] here.

You're assuming that lines has at least one element. Otherwise
lines[0] would give IndexError. This won't raise IndexError since the
line of code "file = ..." is only executed inside the body of the for
loop which means that if lines is empty then execution doesn't reach
this point. I don't think that that was your intention though as
really it should be line rather than lines[0].

You're then assuming that lines[0].split() (which should really be
line.split())) has at least 10 elements since you ask for
lines[0].split()[9]. This will raise IndexError if .split() returnd
fewer than 10 substrings. This is most likely the IndexError that you
get. Your incorrect use of line rather than lines[0] means you're
reading one of the lines that contains "exited" and so when you call
.split() on that it gives fewer than 10 elements and so the last index
in lines[0].split()[9] raises IndexError.

> break
> print file

Here you're assuming that lines contains at least one string that does
not contain the substring "exited". Otherwise this line will leas to a
NameError since the name file is not bound to anything unless the
"file=" line is executed.

> return file
>
> def main():
> functions = [check_file]
> for func in functions:
> try:
> func()
> except Exception as e:
> return False

Here you've crippled Python's ability to give quite useful error
messages. Replace the above with:

def main():
check_file()

and then Python will print a helpful error message. More than that if
you learn to use a debugger you can hook into the exact moment where
an *uncaught* error is raised. Since you catch the error that won't be
possible. The traceback that Python prints *if you don't catch the
error* contains useful information about the problem. Even if you
don't understand that information other people do so if you post it
here then you can get much better help. It shows the line at which the
error occurred and has more description than simply IndexError.

If you remove the try/except you can then use pdb. Just rerun your code as

$ python -m pdb myscript.py

Type "c" (and hit enter) to "continue". This will run your script
right up to the point of the uncaught exception and then hook you into
a debugger at the moment the exception was raised. You can then use
"l" to show the surrounding code. Use "p file" to show the value of
for example the file variable if that seems to be the problem.

--
Oscar
-- 
https://mail.python.org/mailman/listinfo/python-list

Help

[tomwilliamson115]

I need to write a program that allows the user to enter a sentence then asks 
them which word they wish to find- and then tell them the position that word 
was within the sentence. 

E.g. Please help with this code 
Then they enter help it would return that it appears in the 2nd position in the 
sentence. 

>From what I gather it appears to be a list function but I am struggling to 
>come up with a solution. 

Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to read from a file to an arbitrary delimiter efficiently?

[Oscar Benjamin]

On 25 February 2016 at 06:50, Steven D'Aprano
 wrote:
>
> I have a need to read to an arbitrary delimiter, which might be any of a
> (small) set of characters. For the sake of the exercise, lets say it is
> either ! or ? (for example).
>
> I want to read from files reasonably efficiently. I don't mind if there is a
> little overhead, but my first attempt is 100 times slower than the built-in
> "read to the end of the line" method.

You can get something much faster using mmap and searching for a
single delimiter:

def readuntil(m, delim):
start = m.tell()
index = m.find(delim, start)
if index == -1:
return m.read()
else:
return m.read(index - start)

def readmmap(f):
m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
f.seek(0)
while True:
chunk = readuntil(m, b'!') # Note byte-string
if not chunk:
return
# Do stuff with chunk
pass

My timing makes that ~7x slower than iterating over the lines of the
file but still around 100x faster than reading individual characters.
I'm not sure how to generalise it to looking for multiple delimiters
without dropping back to reading individual characters though.

--
Oscar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help

[jacob Kruger]

On 2016-02-28 9:58 PM, tomwilliamson...@gmail.com wrote:

I need to write a program that allows the user to enter a sentence then asks 
them which word they wish to find- and then tell them the position that word 
was within the sentence.

E.g. Please help with this code
Then they enter help it would return that it appears in the 2nd position in the 
sentence.


From what I gather it appears to be a list function but I am struggling to come 
up with a solution.


Thanks.

Something along lines of loading the sentence into a string, using the 
str.split() function to split it into a list object, then cycling 
through to strip all the spaces and/or punctuation out of the 
elements/items, and then the list.index() function can return the index 
of a word in the list, which is the zero-based position of the item in 
that list.


#something along lines of
s = input("enter sentence")
s.replace(",", "") #do this for all common punctuation characters
l = s.split(" ") #space is actually default
s2 = input("enter word")
i = l.index(s2)
print("Your word is at position " + str(i+1) + " in the sentence")
#end code

That's just typed here in message - HTH

HTH

Jacob Kruger
Blind Biker
Skype: BlindZA
"Roger Wilco wants to welcome you...to the space janitor's closet..."
--
https://mail.python.org/mailman/listinfo/python-list

Re: How to read from a file to an arbitrary delimiter efficiently?

[Tim Delaney]

On 29 February 2016 at 07:28, Oscar Benjamin 
wrote:

> On 25 February 2016 at 06:50, Steven D'Aprano
>  wrote:
> >
> > I have a need to read to an arbitrary delimiter, which might be any of a
> > (small) set of characters. For the sake of the exercise, lets say it is
> > either ! or ? (for example).
> >
> > I want to read from files reasonably efficiently. I don't mind if there
> is a
> > little overhead, but my first attempt is 100 times slower than the
> built-in
> > "read to the end of the line" method.
>
> You can get something much faster using mmap and searching for a
> single delimiter:
>
> My timing makes that ~7x slower than iterating over the lines of the
> file but still around 100x faster than reading individual characters.
> I'm not sure how to generalise it to looking for multiple delimiters
> without dropping back to reading individual characters though.
>

You can use an mmapped file as the input for regular expressions. May or
may not be particularly efficient.

Otherwise, if reading from a file I think read a chunk, and seek() back to
the delimiter is probably going to be most efficient whilst leaving the
file position just after the delimiter.

If reading from a stream, I think Chris' read a chunk and maintain an
internal buffer, and don't give access to the underlying stream.

Tim Delaney
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Rustom Mody :

> On Sunday, February 28, 2016 at 8:38:49 PM UTC+5:30, Marko Rauhamaa wrote:
>> We are talking about GUI tools to produce what? Crap?
>
> You (seem to) be saying that excel is crap.
> Do you know it well enough to make that judgement?
> Do you have equivalent functionality in some other tool?

Well, now you mention it, I have a third anecdote. For years I was the
treasurer of a soccer team. My predecessors had used Excel for the
purpose, with varying success. The accounting software I chose for the
job was -- Python.

I entered the transactions in Python and had the main program output all
the needed reports: Excel, HTML, email. I believe it would have been a
nightmare to do it any other way.

As for Excel being crap, I have seen admirable, heroic, colossal efforts
put in a lot of GUI apps (web or otherwise) but the results still coming
short: Excel, Atlassian, Eclipse. Thing is, I wonder if the whole GUI
paradigm is only suitable for very simple, naive things.

An exception to that comment would be games. They really are often
awe-inspiring achievements.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Mon, 29 Feb 2016 12:51 am, Marko Rauhamaa wrote:

> Rustom Mody :
> 
>> whereas in fact every significant GUI embeds text (possibly recursively)
>>
>> eg TI inside GUI -- think of text inside gimp
>> GUI inside TI -- think of Word embedding other doc types including
>> pictures Which can be recursive -- WOrd embeds a picture embeds text
> 
> Sigh, still nobody has mentioned an exemplary GUI application.

Possibly because of the poor state of GUI application development, I don't
think there are many. There are many which are *acceptable*, to some lesser
or greater degree, but none that come to mind which make me go "wow, that's
amazing!".

Or perhaps I'm just jaded after 30+ years of using GUI apps and can only see
the bugs and not the features any more.


> An anecdote: Some weeks back my son and I were struggling to get the
> right kind of graph out of Excel. After four hours of Google, Youtube,
> trial and error, we gave up, took out a pad of millimeter paper and some
> colored pencils. The whole job took my son an hour and the end result
> looked great. He snapped a picture and sent it to the teacher by email.

I feel that the state of the art of graphing tools is horrid. It's
acceptable for business-style graphs (e.g. barcharts and pie charts) with
just a handful of items but rapidly goes downhill from there. There is too
much emphasis on making the graph look "fancy" at the expense of
communicating information (3D pie charts, really?). But for graphing
mathematical functions, it's just horrible. A good graphing application
should:

- by default show the zero point on the Y-axis;
- by default scale the Y-axis so as to fit the entire graph;
- label the axes in such a way that they are readable;
- be as easy as saying "graph f(x) for x between a and b" 
  and have the graphing application pick sensible defaults;
- allow easy discovery of features (which usually means a graphical
  interface -- e.g. click on the axis and be presented with options
  to modify that axis).


> A 2nd anecdote. I occasionally need to make technical presentations to
> an audience. Do I use PowerPoint or Impress? No, I use emacs, M-x
> picture-mode and raw HTML (without styles). I get to concentrate on
> producing effective communication, and nobody has complained about the
> lack of imagery or funny animation.

You don't know if they haven't complained because they don't miss them, or
haven't complained because they fell asleep and are too embarrassed to
complain "your presentation put me to sleep due to the lack of dancing
cows".

:-)



-- 
Steven

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

Re: Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Mon, 29 Feb 2016 01:26 am, Chris Warrick wrote:

>> git is a *collaborative* tool and should work when the other party is
>> using notepad.
> 
> What should git do if someone saves, say, Ruby code as a .py file?
> Should it rename it? Or should it figure out an equivalent snippet of
> Python?

Don't be ridiculous. That's completely over the top.

It isn't asking too much for version control systems to *not care* about
line ending changes. Who cares if the file changes from \n to \r \r\n? It
shouldn't matter, or at least, it shouldn't matter much.

> You probably have some rules in your project such as “Code must be
> written in Python” 

In one of my Python projects, I have (as well as various .py files) an R
script and a Gnumeric spreadsheet. In another Python project, I have a
couple of bash scripts. In nearly every one of my repos, I have plain text
files that don't contain Python code. Should the VCS refuse to track them
because they don't contain Python code? Of course not.

If I open a Python file in my editor, accidentally or deliberately change
the content to Ruby code, save and commit, then the VCS obviously should
track the changes because they are actual changes.

But if I open a Python file in my editor, accidentally or deliberately
change the line endings from \n to \r, save and commit, then it is a
weakness and limitation of the current generation of VCSs that they will
treat this as "every line has changed". Or worse, "10,000 lines have
collapsed to a single line containing \r characters".

Changing line endings is neither a structural nor a semantic change to the
content of the file. It's effectively metadata, not data. The Python
interpreter doesn't care which line ending you use. Neither will decent
text editors. If some tools, like git, do, then that's a weakness of git,
not a feature. Changing the permissions on a 10,000 line file doesn't give
you a 10,000 line diff, and neither should changing the line ending.

Your VCS absolutely should track line ending changes. In a perfect world, we
should never care about the line ending, but so long as there are users and
tools that cannot transparently deal with one line ending or another, there
may be times were we do care about line endings, and therefore want to
run "git blame" to find out which idiot changed the line ending of my file
to \r. But that should be treated as a metadata change, not a change to the
content. I know it isn't "really" metadata, it's "actually" content, but
regardless, it should be *treated* as metadata.

Who is the boss here? The user of the tool, or the tool?



-- 
Steven

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

Re: Everything good about Python except GUI IDE?

[Terry Reedy]

On 2/28/2016 9:29 AM, BartC wrote:


(Have you ever had a situation where you have to edit a bit of text
where a word is in italic or has some particular style. You delete the
word, and try and add some more text, but it persists in using the style
of the deleted text rather than the current style. You move further
away; still the same. You end up deleting everything including every
trace of that word and its style. Yet start typing on a now blank
document, and it's still the wrong style!


Wordperfect had a Reveal Codes option that made it easy to exactly fix 
such mixups.  I think it a tragedy that MS Word wiped it out.



That's what I mean by these applications having minds of their own. And
with a 300-page document you can't just start all over, you need
something reliable, and not so smart.)


I did a 200 page book with WP.


--
Terry Jan Reedy

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

Re: Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Mon, 29 Feb 2016 01:29 am, BartC wrote:

> 20 years ago, when these things were simpler, MS Word had a mind of its
> own even then. I had to produce a manual of few hundred pages, with
> diagrams and images, and it just wasn't going to happen. Not without
> spending a year on it. And employing someone to do it cost thousands.

So you're saying that somebody else knew how to do it, but you didn't, so it
would take you a year?

I find it hard to believe that Word 20 years ago couldn't deal with
something as small as a couple of hundred pages with diagrams. I find it
much easier to believe that you're the sort of guy who would rather spend
three days inventing your solution from scratch (involving your own custom
programming language no less) than three hours reading the manual of the
existing solution.


> In the end I spent a week or two throwing together some simple mark-up 
> language, written in my own editor, which was then processed by my own 
> script language and ending up (via my own graphics software along the 
> way) as Postscript. The results were perfect.

/s/three days/two weeks/


> (Have you ever had a situation where you have to edit a bit of text 
> where a word is in italic or has some particular style. You delete the 
> word, and try and add some more text, but it persists in using the style 
> of the deleted text rather than the current style. You move further 
> away; still the same. You end up deleting everything including every 
> trace of that word and its style. Yet start typing on a now blank 
> document, and it's still the wrong style!

You know that Word lets you reset the style to plain (Roman) text? There's
no need to delete the entire line, let alone the entire document. Text
styles are toggled: just hit Ctrl-I (or is it Ctrl-Shift-I, it's been a
while since I've used Word) to toggle italic on and off. Even if the
current paragraph defaults to italic, you can still toggle it off that way.




-- 
Steven

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

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Mon, Feb 29, 2016 at 11:39 AM, Steven D'Aprano  wrote:
> If I open a Python file in my editor, accidentally or deliberately change
> the content to Ruby code, save and commit, then the VCS obviously should
> track the changes because they are actual changes.

"Oops, I accidentally pressed Esc-Meta-Alt-R-Q and translated my code
into Ruby. Now what?"

> Changing line endings is neither a structural nor a semantic change to the
> content of the file. It's effectively metadata, not data. The Python
> interpreter doesn't care which line ending you use. Neither will decent
> text editors. If some tools, like git, do, then that's a weakness of git,
> not a feature. Changing the permissions on a 10,000 line file doesn't give
> you a 10,000 line diff, and neither should changing the line ending.
>
> Your VCS absolutely should track line ending changes. In a perfect world, we
> should never care about the line ending, but so long as there are users and
> tools that cannot transparently deal with one line ending or another, there
> may be times were we do care about line endings, and therefore want to
> run "git blame" to find out which idiot changed the line ending of my file
> to \r. But that should be treated as a metadata change, not a change to the
> content. I know it isn't "really" metadata, it's "actually" content, but
> regardless, it should be *treated* as metadata.
>
> Who is the boss here? The user of the tool, or the tool?

This is a tricky question, and there's a slight difference between
perms and line endings in that it's perfectly possible to have mixed
line endings. The normal way to resolve this is to tell git to convert
line endings *for text files* such that source control always uses \n,
and then individual users get to choose whether to check out with \n
or convert to \r\n for their working copies. This destroys any
information that had been represented in mixed line endings - but
that's information that no project I've ever worked with uses.
However, since this is not something that git dares do on its own,
it's not the default action - though the Git Windows installer does
prompt you to pick those options on installation.

Once you tell git to treat line endings the same way ("git config
--global core.autocrlf true", if memory serves me), it's not even
metadata, it's just non-information.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Ben Finney]

Steven D'Aprano  writes:

> Changing line endings is neither a structural nor a semantic change to
> the content of the file. It's effectively metadata, not data.

Hmm. Unlike other examples you give (like filesystem permissions on the
file) the line endings *are* content in the file. You may say they're
metadata, and maybe there's a case for that; I think that doesn't stop
line endings in the file from being content — and changes to those are
changes to content.

I'd say “what line ending style is in use” is closer to the information
about text encoding. Yes, it is metadata; it is *also* content, because
a change to the text encoding must be reflected as a change to the
file's content. The same is not true for (e.g.) filesystem permissions.

I would say that a change to the text encoding in the file should be
reflected as a change to the file content, and presented as such by the
VCS. Do you agree?

Whatever your answer to that, I would be interested to know whether you
think the answer should be different for line ending changes.

> Who is the boss here? The user of the tool, or the tool?

We are unfortunately a slave to decisions made long in the past, to
record some metadata – line endings, text encoding – as in-band content
rather than out-of-band pure metadata. The VCS must, IMO, be at least
aware that the content has changed when those in-band data change.

-- 
 \“Visitors are expected to complain at the office between the |
  `\ hours of 9 and 11 a.m. daily.” —hotel, Athens |
_o__)  |
Ben Finney

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

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Mon, Feb 29, 2016 at 12:05 PM, Ben Finney  wrote:
>> Who is the boss here? The user of the tool, or the tool?
>
> We are unfortunately a slave to decisions made long in the past, to
> record some metadata – line endings, text encoding – as in-band content
> rather than out-of-band pure metadata. The VCS must, IMO, be at least
> aware that the content has changed when those in-band data change.

Not sure what you mean here. It's metadata that lets you properly
interpret the content; by definition, that has to be out of band
information with in-band consequences. It's like using a shebang to
interpret an executable file - you can't just casually change the
first line from "#!/usr/bin/python2" to "#!/usr/bin/python3" and deem
that your code has now been ported to Py3.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Michael Torrie]

On 02/27/2016 11:13 AM, wrong.addres...@gmail.com wrote:
> On Saturday, 27 February 2016 18:08:36 UTC+2, Dietmar Schwertberger
>> As of today, there's no Python GUI builder comparable to VB 6.

> Thanks for stating this clearly. Everyone here has been trying to
> show me various ways to do the kind of things I will want to, but
> nobody clearly admits the limitations I will have to accept if I
> start with Python.

Every language and environment has limitations and tradeoffs, including
the venerable VB6 model.  In my opinion, no one including Microsoft has
ever duplicated the functionality of VB6.

> I am starting to wonder if VB.net would be a better solution for the
> time being. I have learnt enough VB.net to manage my work but it is
> bloated and Microsoft dependent.

Maybe you should post a small VB6 project on github (something that
isn't very secret and could be licensed in an open way perhaps) and then
see if we can come together here on the forum to convert it to Python
using one of the various GUI toolkits.  Could be a fun challenge and
would be instructive to you.

>> There are some like QtDesigner or wxGlade, but they either don't 
>> generate Python code directly or they can only be used if you know
>> the underlying toolkit good enough to create the GUI yourself. You
>> may try out some, but I can almost guarantee you that you will come
>> to the same result. If you want a GUI, create it yourself using
>> either wxPython or PyQt.
> 
> I will check it. I got the impression that you can create a GUI but
> that has to be converted to Python, and then you need a wrapper to
> put these forms in, and then they can be compiled or converted to
> *.exe with py2exe. Not a good way for development/debugging.

You are laboring under some misconceptions in general I think.  All the
GUI designers talked about here work with XML definition files (each has
its own flavor) and then either generate Python code from it, or you can
load the XML file at runtime and the GUI is created under the hood from
that (similar to .nib files on OS X).  Compiling to .exe is an entirely
different matter.  If you think Python will help you easily create .exes
you might be barking up the wrong tree.

Python is an interpreted language (soon to be JIT'ed with PyPy).  It's
not a compiler.  You can edit and run the python files directly for
debugging.  You can use py2exe to create a final executable if you want,
but this is not compiling and it won't keep your code secret.

> In the 1980s everyone was happy with inputs from the command line on
> a line editor, but today people expect GUIs with graphics and often
> even animations.

Qt does this very well with less and less programming all the time.
QtQuick and QML can define pretty nice transitions and animations that
can then be combined with Python programming.

But there's more than one way to do things.  I use a program called
Glade3 for doing GTK+ apps in Python (I only use Linux).  In PyQt I use
the amazing QtDesigner.

> It is surprising that a language which seems very popular does not
> have GUI development infrastructure in place these many years after
> it got into common use.

Well it's just that the infrastructure is very different than you're
used to.  There are lots of different choices.  I think it turns out
that a VB6-style IDE just has never been necessarily for the vast
majority of Python programmers.  And there are very fancy, complicated
GUI apps written in Python.  For example, the calibre ebook management
program is a nice GUI with animations like coverflow, and it's entirely
in Python and PyQt. I'm sure the author uses Qt Designer to do GUI layout.
-- 
https://mail.python.org/mailman/listinfo/python-list

Lineendings (was Everything good about Python except GUI IDE?)

[Rustom Mody]

On Monday, February 29, 2016 at 6:09:33 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 29 Feb 2016 01:26 am, Chris Warrick wrote:
> 
> >> git is a *collaborative* tool and should work when the other party is
> >> using notepad.
> > 
> > What should git do if someone saves, say, Ruby code as a .py file?
> > Should it rename it? Or should it figure out an equivalent snippet of
> > Python?
> 
> Don't be ridiculous. That's completely over the top.
> 
> It isn't asking too much for version control systems to *not care* about
> line ending changes. Who cares if the file changes from \n to \r \r\n? It
> shouldn't matter, or at least, it shouldn't matter much.

Unfortunately that's the outlook all major VCSes (not just git) have started 
with and its wrong.
Speaking somewhat simplistically:
On windows one should see CRLF
On *nix LF
And this SHOULD NOT be a diff!
[Assuming the VCS is serious about collaboration]

Analogy:
I stick my flash drive into linux and get /media/rusi/Transcend
On windows (I guess) its H:\Transcend
The SAME files and filesystem should be thus different right?

.gitattributes does make these (declarations) possible
... in a half-assed afterthought sort of way
with safecrlf and autocrlf as earlier poor bug-ridden bugfixes
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lineendings (was Everything good about Python except GUI IDE?)

[Chris Angelico]

On Mon, Feb 29, 2016 at 12:39 PM, Rustom Mody  wrote:
> Unfortunately that's the outlook all major VCSes (not just git) have started
> with and its wrong.
> Speaking somewhat simplistically:
> On windows one should see CRLF
> On *nix LF
> And this SHOULD NOT be a diff!
> [Assuming the VCS is serious about collaboration]
>

If you want this, simply run this on your Windows computer:

git config --global core.autocrlf true

Job done. The repo will record LF, but you'll get CRLF on the Windows
box. Alternatively, if you're happy with LF on Windows, but want
protection against accidentally checking in a CRLF:

git config --global core.autocrlf input

Either way, this means that line endings get folded to LF for consistency.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lineendings (was Everything good about Python except GUI IDE?)

[Rustom Mody]

On Monday, February 29, 2016 at 7:20:19 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Feb 29, 2016 at 12:39 PM, Rustom Mody  wrote:
> > Unfortunately that's the outlook all major VCSes (not just git) have started
> > with and its wrong.
> > Speaking somewhat simplistically:
> > On windows one should see CRLF
> > On *nix LF
> > And this SHOULD NOT be a diff!
> > [Assuming the VCS is serious about collaboration]
> >
> 
> If you want this, simply run this on your Windows computer:
> 
> git config --global core.autocrlf true
> 
> Job done. The repo will record LF, but you'll get CRLF on the Windows
> box. Alternatively, if you're happy with LF on Windows, but want
> protection against accidentally checking in a CRLF:
> 
> git config --global core.autocrlf input
> 
> Either way, this means that line endings get folded to LF for consistency.
> 
> ChrisA

Just check stackoverflow for how often this FAILS to work
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lineendings (was Everything good about Python except GUI IDE?)

[Chris Angelico]

On Mon, Feb 29, 2016 at 12:55 PM, Rustom Mody  wrote:
> On Monday, February 29, 2016 at 7:20:19 AM UTC+5:30, Chris Angelico wrote:
>> On Mon, Feb 29, 2016 at 12:39 PM, Rustom Mody  wrote:
>> > Unfortunately that's the outlook all major VCSes (not just git) have 
>> > started
>> > with and its wrong.
>> > Speaking somewhat simplistically:
>> > On windows one should see CRLF
>> > On *nix LF
>> > And this SHOULD NOT be a diff!
>> > [Assuming the VCS is serious about collaboration]
>> >
>>
>> If you want this, simply run this on your Windows computer:
>>
>> git config --global core.autocrlf true
>>
>> Job done. The repo will record LF, but you'll get CRLF on the Windows
>> box. Alternatively, if you're happy with LF on Windows, but want
>> protection against accidentally checking in a CRLF:
>>
>> git config --global core.autocrlf input
>>
>> Either way, this means that line endings get folded to LF for consistency.
>>
>> ChrisA
>
> Just check stackoverflow for how often this FAILS to work

Never has for any of my projects. Examples please? Actual real
problems? I've been using git for years, on mixed platforms for a lot
of that, and not had a single problem.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lineendings (was Everything good about Python except GUI IDE?)

[Rustom Mody]

On Monday, February 29, 2016 at 7:33:18 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Feb 29, 2016 at 12:55 PM, Rustom Mody  wrote:
> > On Monday, February 29, 2016 at 7:20:19 AM UTC+5:30, Chris Angelico wrote:
> >> On Mon, Feb 29, 2016 at 12:39 PM, Rustom Mody  wrote:
> >> > Unfortunately that's the outlook all major VCSes (not just git) have 
> >> > started
> >> > with and its wrong.
> >> > Speaking somewhat simplistically:
> >> > On windows one should see CRLF
> >> > On *nix LF
> >> > And this SHOULD NOT be a diff!
> >> > [Assuming the VCS is serious about collaboration]
> >> >
> >>
> >> If you want this, simply run this on your Windows computer:
> >>
> >> git config --global core.autocrlf true
> >>
> >> Job done. The repo will record LF, but you'll get CRLF on the Windows
> >> box. Alternatively, if you're happy with LF on Windows, but want
> >> protection against accidentally checking in a CRLF:
> >>
> >> git config --global core.autocrlf input
> >>
> >> Either way, this means that line endings get folded to LF for consistency.
> >>
> >> ChrisA
> >
> > Just check stackoverflow for how often this FAILS to work
> 
> Never has for any of my projects. Examples please? Actual real
> problems? I've been using git for years, on mixed platforms for a lot
> of that, and not had a single problem.

Pragmatically: As I said just search stackoverflow for git:crlf
Theoretically: Its a borked (leaky) abstraction
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Mon, 29 Feb 2016 04:53 am, Chris Angelico wrote:

> For example, I have a Dungeons & Dragons character sheet display, in
> which there are large numbers of entry fields (editable), labels
> (non-editable display, usually calculated from other fields), and less
> commonly, drop-down lists and multi-line text fields. Call that four
> primitives. Now, some of the fields need to be highlighted for the
> human's attention 
[...] 
> With a GUI builder, how do 
> you redefine a function that isn't just simple composition?

I'm not entirely sure what your objection here is. You're still coding. Your
widgets will have callbacks, or have handlers (to use Hypercard
terminology). Just because you're placing the widget by point-and-click or
drag-and-drop doesn't mean that you don't have to write any code at all.

If the highlighting is done at runtime, there's probably a handler or
callback that handles it. So you edit that code, wherever it happens to be.


> This additional meta-level is one that is absent from a *lot* of
> modern graphical environments. 

That's exactly why I miss Hypercard so much. The builder and the runtime are
the same thing. (In practice, you could use a simple permissions-based
model to disable access to the builder at runtime, if desired.) I really
cannot stress enough how similar it is to Python's REPL. In Python, you can
choose at an extremely fine-grained level:

- open a file in an editor, write a function or class, save, import that
module into the REPL;

- or write the function directly in the REPL;

- what's that, I need to operate on that function as data? I can write a
decorator-type function in the REPL and apply it to the function as needed,
on the fly.

I can *build code* and *run code* in the same environment. I don't *have* to
use the REPL. I can write my code in a text editor, of course, and for many
purposes that is idea. But having the interpreter available at the same
time is a HUGE benefit. Languages without a REPL are comparatively crippled
by comparison, as far as rapid development, exploration, discovery and
testing are concerned.

Think of the GUI builder as the REPL for building GUIs. You shouldn't have
to do all your work in the REPL, but neither should you be limited without
one. If the GUI builder doesn't let you write and run code on the fly, it's
a crap builder.

Hypercard had one powerful feature that the default Python REPL lacks. When
you quit Python's interactive interpreter, all the functions, classes and
variables you have created disappear. When you quit Hypercard, all the
widgets and data and code you have created is saved in the current document
(the "stack") so that they are available next time you open that document.

I think that iPython workbooks (notebooks?) are the closest equivalent in
the Python world. Certainly they are a powerful and popular feature in the
sciences (iPython copied them from Mathematica).


> Look at spreadsheets - the classic 
> Lotus 1-2-3 model has stayed with us all through, with MS Excel, OO/LO
> Calc, etc, etc generally following it. And that's fine; spreadsheets
> do a lot of very good work for a lot of people. Now, suppose in cell
> C2 you have this formula: "=A2+B2*.05". You can copy that down the
> rest of the column, and C9 will say "=A9+B9*.05", and so on; that's
> what spreadsheets do well. But once you've done that copy operation,
> those cells lose all track of the fact that they got their formula
> from C2. If you edit C2, you have to re-copy-down. That's not too hard
> for a lot of people to remember, but what happens when that's
> forgotten? 

What you are describing is effectively a form of refactoring. What happens
when you decide to use a set instead of a tuple for some data structure?
You have to go through your entire code base looking for all references to
those tuples (it might not be just one!) and change them to a set, and
change the code that operates on them. Don't say "you should have hidden
the fact that this is a tuple behind some interface layer", because this is
the implementation layer. (There's always an implementation layer.)

Some editors have refactoring tools for this sort of thing, but most don't,
and refactoring tools are never perfect nor fully automated.


>> (2) "source control" -- the world is full of document types that aren't
>> plain text source code, and people have found ways to manage
>> collaborative editing and change management for them. Why don't we ask
>> game developers how they manage changes to the non-code elements in their
>> applications? Textures, icons, player avatars, sound effects, maps, etc.
>> Surely you don't suggest that game developers edit their background
>> images in a hex editor?
> 
> Yes, and while you're at it, ask the critical question: What happens
> when two people make edits to the same object? 

You mean, something like I change the File menu to say "New; Save; Quit" and
you change it to say "Create; Save; Exit"?

Then there's a conflict, same a

Re: Lineendings (was Everything good about Python except GUI IDE?)

[Ben Finney]

Rustom Mody  writes:

> On Monday, February 29, 2016 at 7:33:18 AM UTC+5:30, Chris Angelico wrote:
> > Never has for any of my projects. Examples please? Actual real
> > problems? I've been using git for years, on mixed platforms for a lot
> > of that, and not had a single problem.
>
> Pragmatically: As I said just search stackoverflow for git:crlf

Don't ask Chris to *guess* which search results are representative of
what you're asserting. Please provide concrete examples that demonstrate
specifically what you're describing.

-- 
 \“I'd take the awe of understanding over the awe of ignorance |
  `\  any day.” —Douglas Adams |
_o__)  |
Ben Finney

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

Re: Computational Chemistry Analysis

[Jason Swails]

On Wed, Feb 24, 2016 at 8:01 PM, Feagans, Mandy 
wrote:

> Dear Python,
>
>
> Hi! I am a student interested in conducting computational analysis of
> protein-ligand binding for drug development analysis. Recently, I read of
> an individual using a python program for their studies of protein-ligand
> binding. As I have been reading about Python programs, however, all I have
> been able to find are programs that use the python script (i.e. Autodock).
> I was hoping to see if there were any programs specifically run through the
> python programming that ran similar analysis to Autodock?
>

​Being trained as a computational chemist myself (and having learned Python
by writing a program for carrying out protein-ligand free energy
calculations: http://pubs.acs.org/doi/abs/10.1021/ct300418h), I had to
answer...

There are a number of programs out there that are aimed at computational
modeling of biomolecules, and many of them are written in Python or have
Python interfaces (pymol, chimera, MMPBSA.py, OpenMM to name a very small
few).  However, this is definitely not the right forum to ask such
questions as a very small number of people who frequent this list are
computational chemists (I check it only occasionally).

Looking for a program to do something because it's written in Python is the
wrong way to go about this.  You need to design your experiment (i.e., what
you want to test and what you hope to learn), then try to design a set of
calculations and analyses that will allow you to probe your underlying
hypothesis.  Then you should pick the software to perform these analyses
based on the best choice.  That choice is very frequently whatever others
in your lab are using.  A research group builds up experience (based
originally on the experience of the PI, typically) in a set of programs
they use for their computational experiments, and deviating from that set
of programs essentially discards potentially decades worth of experience.
So my suggestion -- ask other group members or the professor what softwares
they use, and consult Google if you wish to branch out a little.

You can also find more applicable mailing lists to ask questions about
computational chemistry, like the CCL or molecular dynamics news (the CCL
being the defacto "Computational Chemistry List").  That should help give
perhaps more helpful places to start.

FWIW, I did all my work with the AMBER and OpenMM software suites, (and
wrote a substantial amount of code for both projects).  But those are far
from the only options out there.

HTH,
Jason

-- 
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Gregory Ewing]

Steven D'Aprano wrote:

That's exactly why I miss Hypercard so much. The builder and the runtime are
the same thing.


Maybe someone would like to resurrect this project:

http://pythoncard.sourceforge.net/

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Gordon Levi]

Marko Rauhamaa  wrote:

>Rustom Mody :
>
>> On Sunday, February 28, 2016 at 7:22:08 PM UTC+5:30, Marko Rauhamaa wrote:
>>> Rustom Mody :
>>> 
>>> > whereas in fact every significant GUI embeds text (possibly
>>> > recursively)
>>> >
>>> > eg TI inside GUI -- think of text inside gimp GUI inside TI --
>>> > think of Word embedding other doc types including pictures Which
>>> > can be recursive -- WOrd embeds a picture embeds text
>>> 
>>> Sigh, still nobody has mentioned an exemplary GUI application.
>>> 
>>> An anecdote: Some weeks back my son and I were struggling to get the
>>> right kind of graph out of Excel. After four hours of Google,
>>> Youtube, trial and error, we gave up, took out a pad of millimeter
>>> paper and some colored pencils. The whole job took my son an hour and
>>> the end result looked great. He snapped a picture and sent it to the
>>> teacher by email.
>>
>> Point being??
>
>I'm awaiting for an opposite anecdote, a GUI app you absolutely love and
>recommend as a model for GUI developers.
>
>We are talking about GUI tools to produce what? Crap?

Nobody likes filling in forms but how do you suggest converting a form
based app into something loveable. What interface would make you love
adding a new contact to your address book?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lineendings (was Everything good about Python except GUI IDE?)

[Rustom Mody]

On Monday, February 29, 2016 at 8:05:33 AM UTC+5:30, Ben Finney wrote:
> Rustom Mody  writes:
> 
> > On Monday, February 29, 2016 at 7:33:18 AM UTC+5:30, Chris Angelico wrote:
> > > Never has for any of my projects. Examples please? Actual real
> > > problems? I've been using git for years, on mixed platforms for a lot
> > > of that, and not had a single problem.
> >
> > Pragmatically: As I said just search stackoverflow for git:crlf
> 
> Don't ask Chris to *guess* which search results are representative of
> what you're asserting. Please provide concrete examples that demonstrate
> specifically what you're describing.

I was answering Chris' specific "Never has for any of my projects"
by saying there are dozens of questions about this (FAQ) on stackoverflow

1st one it gives:
http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git

Also some discussions by git devs:
https://groups.google.com/forum/#!topic/msysgit/Gb5tlbfEyPk

There are more acrimonious dev-exchanges that can be hunted down

Nevertheless my basic point is somehow a bit different:
A text file (content) is a list of lines
A line is a list of char
A char is... wont open that can of worms!

If git says it stores EOL as LF and can convert to LF or CRLF on demand
there itself is the leaked abstraction.
Knowing that git uses LF internally should be as relevant as say
machine endianness is to how python stores the tuple (1,2)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Alan Bawden]

Cameron Simpson  writes:
> On 22Feb2016 12:34, Alan Bawden  wrote:

I have deleted the part of discussion where it seems that we must simply
agree to disagree.  You think mktemp() is _way_ more dangerous that I
do.

>>> In fact your use case isn't safe, because _another_ task using mktemp
>>> in conflict as a plain old temporary file may grab your fifo.
>>
>>But here in very last sentence I really must disagree.  If the code I
>>wrote above is "unsafe" because some _other_ process might be using
>>mktemp() badly and stumble over the same path, then the current
>>implementation of tempfile.mkdtemp() is also "unsafe" for exactly the
>>same reason: some other process using mktemp() badly to create its own
>>directory might accidentally grab the same directory.
>
> When the other taks goes mkdir with the generated name it will fail, so no.

Quite right.  I sabotaged my own argument by picking mkdtemp() instead
of mkstemp().  I was trying to shorten my text by taking advantage of
the fact that I had _already_ mentioned that mkdtemp() performs exactly
the same generate-and-open loop than the code I had written.  I
apologize for the confusion.

In fact, mkstemp() also performs that same generate-and-open loop, and of
course it is careful to use os.O_EXCL along with os.O_CREAT when it
opens the file.  So let me re-state my argument using mkstemp() instead:

If the code I wrote in my original message is "unsafe" because some
_other_ process might be using mktemp() badly and stumble over the same
path, then the current implementation of tempfile.mkstemp() is also
"unsafe" for exactly the same reason: some other process badly using
mktemp() to create its own file might accidentally grab the same file.

In other words, if that other process does:

  path = mktemp()
  tmpfp = open(path, "w")

Then yes indeed, it might accidentally grab my fifo when I used my
original code for making a temporary fifo.  But it might _also_ succeed
in grabbing any temporary files I make using tempfile.mkstemp()!  So if
you think what I wrote is "unsafe", it seems that you must conclude that
the standard tempfile.mkstemp() is exactly as "unsafe".  So is that what
you think?

-- 
Alan Bawden
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Gordon Levi :

> Nobody likes filling in forms but how do you suggest converting a form
> based app into something loveable.

Straight HTML does forms just fine without CSS or JavaScript, yet few
can resist.

> What interface would make you love adding a new contact to your
> address book?

In my case, the address book is a ~/.mailrc file, which I edit using
emacs.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Make a unique filesystem path, without creating the file

[Cameron Simpson]

On 29Feb2016 00:47, Alan Bawden  wrote:

Cameron Simpson  writes:

On 22Feb2016 12:34, Alan Bawden  wrote:


I have deleted the part of discussion where it seems that we must simply
agree to disagree.  You think mktemp() is _way_ more dangerous that I
do.


I certainly think the habit of using it is. And thus we're off into the realm 
of risk assessment I suppose, where one's value sets greatly affect the 
outcome. But there are concrete arguments to be made about risks.


To your other question...

[...]

In fact, mkstemp() also performs that same generate-and-open loop, and of
course it is careful to use os.O_EXCL along with os.O_CREAT when it
opens the file.  So let me re-state my argument using mkstemp() instead:

If the code I wrote in my original message is "unsafe" because some
_other_ process might be using mktemp() badly and stumble over the same
path, then the current implementation of tempfile.mkstemp() is also
"unsafe" for exactly the same reason: some other process badly using
mktemp() to create its own file might accidentally grab the same file.

In other words, if that other process does:

 path = mktemp()
 tmpfp = open(path, "w")

Then yes indeed, it might accidentally grab my fifo when I used my
original code for making a temporary fifo.  But it might _also_ succeed
in grabbing any temporary files I make using tempfile.mkstemp()!  So if
you think what I wrote is "unsafe", it seems that you must conclude that
the standard tempfile.mkstemp() is exactly as "unsafe".

So is that what you think?


Yes and no?

You're quite right that a task using mkstemp is not safe against a task 
misusing mktemp.


_However_:

In a space where everyone uses mktemp, everyone is unsafe from collision.

In a space where everyone uses mkstemp, everyone is safe from collision.

So provided everyone "upgrades", safety is reliable without any added burden in 
program complexity.


Of course, that sidesteps the scenario where someone is using mktemp to obtain 
a pathname for a non-file, but I am of the opinion that in almost all such 
cases the programmer is better off using mkdtemp and making their non-file 
inside the temporary directory. Again, provided everyone "upgrades" to such a 
practice, safety is arranged.


Because of this, I think that _any_ use of mktemp invites risk of collision, 
and needs to be justified with a robust argument establishing that the problem 
cannot be solved with mkstemp or mkdtemp.


Your example was not such a case. Ben's is, in that (a) he needs a "valid" name 
and (b) he isn't going to make an actual filesystem object using the name 
obtained. As it happens it looks like the uuid generation functions from the 
stdlib may meet his needs, addressing his desire to do it simply with the 
stdlib instead of making his own wheel.


So I remain against mktemp without an outsandingly special use case.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Reason for not allowing import twice but allowing reload()

[alien2utoo]

Hello list,

We can not import a module twice in a session of Python (subsequent attempts to 
import same module don't result in any error though, but it is not-effective).

However after making change to module, we can reload() it (if not reload(), we 
could possibly have reimport statement) to get the updates in module.

I am a newbie in Python (learning via IDLE) and trying to understand

- what is extra (special) that import does, that reload() doesn't?
- if both do the same internally and externally, why subsequent imports of same 
module are ineffective?
- if subsequent imports of same module in a session are not effective, why not 
simply flag those attempts as an error, rather than letting them go effect-less.

Kindly help me understand the reasons behind.

Regards
Sandeep
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reason for not allowing import twice but allowing reload()

[Chris Angelico]

On Mon, Feb 29, 2016 at 5:40 PM,   wrote:
> We can not import a module twice in a session of Python (subsequent attempts 
> to import same module don't result in any error though, but it is 
> not-effective).
>
> However after making change to module, we can reload() it (if not reload(), 
> we could possibly have reimport statement) to get the updates in module.
>
> I am a newbie in Python (learning via IDLE) and trying to understand
>
> - what is extra (special) that import does, that reload() doesn't?
> - if both do the same internally and externally, why subsequent imports of 
> same module are ineffective?
> - if subsequent imports of same module in a session are not effective, why 
> not simply flag those attempts as an error, rather than letting them go 
> effect-less.
>
> Kindly help me understand the reasons behind.

Normally, you import a module because you want its features. For
instance, you can "import re" to get access to the Regular Expression
parser, or "import pandas" to load up the rather hefty third-party
numerical computation/analysis library of that name. Sometimes, this
can take a lot of work - importing pandas loads several hundred
modules in total, and can take a second or two, if it's not already in
the OS's disk cache. (Even if it is in cache, it takes a visible pause
- maybe 100-300 ms.) If two parts of your project need the same
module, it's way more efficient to make use of the already-loaded
module.

Additionally, sometimes it makes a lot of difference, and you _want_
to use the same module. When you "import sys", you absolutely must
access the same sys module that everyone else does; otherwise,
changing sys.stdout or sys.path wouldn't have any effect. And
depending on how it's implemented, sys.intern could create very subtle
bugs if you had two versions of it around.

So here's what happens (massively oversimplified) when you "import modulename":

1) Is modulename in sys.modules? If so, return that.
2) Step through sys.path, looking for the module. Can't find it? ImportError.
3) Run that program and create a module object. Put it into
sys.modules, and return it.

You can test that first step fairly easily:

>>> sys.modules["asdf"]="Haha"
>>> import asdf
>>> asdf
'Haha'

As a general rule, this is what you want (apart from sticking strings
into sys.modules, which is a VERY strange thing to do!). In fact, I
would recommend never using reload() unless you're absolutely sure of
what it does and how it's important. I've never used reload() in any
production code, ever. Ever.

The reason that repeating the import isn't flagged as an error is that
it's simply an assignment. If you write this code, Python won't warn
you:

>>> os = sys.modules["os"]
>>> os = sys.modules["os"]
>>> os = sys.modules["os"]
>>> os = sys.modules["os"]

Yet this is effectively what "import os" does. It's assignment, just
like any other assignment operation.

I believe it is theoretically possible to ask Python to give you a
warning (using an import hook), but generally, you should think about
imports simply as assignment.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reason for not allowing import twice but allowing reload()

[Ian Kelly]

On Sun, Feb 28, 2016 at 11:40 PM,   wrote:
> Hello list,
>
> We can not import a module twice in a session of Python (subsequent attempts 
> to import same module don't result in any error though, but it is 
> not-effective).
>
> However after making change to module, we can reload() it (if not reload(), 
> we could possibly have reimport statement) to get the updates in module.
>
> I am a newbie in Python (learning via IDLE) and trying to understand
>
> - what is extra (special) that import does, that reload() doesn't?

When you import a module, it's cached in the sys.modules dict.
Subsequent imports of the same module find the cached module rather
than reimport it. However, reload() ignores the cache and always
reloads the module.

> - if subsequent imports of same module in a session are not effective, why 
> not simply flag those attempts as an error, rather than letting them go 
> effect-less.

Because there are legitimate reasons for importing the same module
multiple times. For example, I have a script that imports the sys
module. It also imports the os module, which imports the sys module.
Both the main module of my script and the os module have need of the
sys module, so they both import it. If subsequent imports of the
module raised an exception, this wouldn't be possible.

However, they shouldn't get two separate copies of the sys module,
because that would be wasteful and potentially error-prone if the
module is stateful In the case of the sys module, there is state --
the sys.modules cache that I mentioned earlier. Imagine the confusion
if two separate imports of the sys module resulted in two separate
instances with two separate caches of imported modules that were in
disagreement.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reason for not allowing import twice but allowing reload()

[Chris Angelico]

On Mon, Feb 29, 2016 at 6:02 PM, Ian Kelly  wrote:
>> - if subsequent imports of same module in a session are not effective, why 
>> not simply flag those attempts as an error, rather than letting them go 
>> effect-less.
>
> Because there are legitimate reasons for importing the same module
> multiple times. For example, I have a script that imports the sys
> module. It also imports the os module, which imports the sys module.
> Both the main module of my script and the os module have need of the
> sys module, so they both import it. If subsequent imports of the
> module raised an exception, this wouldn't be possible.

I think the OP's talking more about the situation of having an active
session (IDLE was mentioned), importing a local module (a .py file
from the current directory), then editing the file and re-importing,
which has no effect. While I am sympathetic to the problem, I don't
believe the language should be changed here; what might be useful is
something that notices that an already-loaded module is now out of
date, but really, the best solution is a change of workflow that no
longer has long-running modules loading live-updated code. I would,
instead, run a short-lived module and simply restart it after any edit
(possibly dropping to interactive mode at the end). Save, restart.
Save, restart. Python isn't optimized for the "keep running but change
code" execution model (for that, use Pike, and pay the complexity
overhead).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Rustom Mody]

On Monday, February 29, 2016 at 11:48:25 AM UTC+5:30, Marko Rauhamaa wrote:
> Gordon Levi :
> 
> > Nobody likes filling in forms but how do you suggest converting a form
> > based app into something loveable.
> 
> Straight HTML does forms just fine without CSS or JavaScript, yet few
> can resist.

Abjure JS/CSS is a virtue? Why?
In any case with or without its still a form not plain (printf/scanf) text.
So what exactly are we talking of?

> 
> > What interface would make you love adding a new contact to your
> > address book?
> 
> In my case, the address book is a ~/.mailrc file, which I edit using
> emacs.

Even in the emacs world people find this painful enough that they use tools 
like bbdb and more modern ones like org-contacts
-- 
https://mail.python.org/mailman/listinfo/python-list