Re: Everything good about Python except GUI IDE?

[Lawrence D’Oliveiro]

On Sunday, February 28, 2016 at 12:19:21 AM UTC+13, wrong.a...@gmail.com wrote:
> I have some VB forms with more than a hundred objects. If I cannot drag and
> drop text boxes, list boxes, labels, etc., it will be too much work to create
> that with several lines of code for each object. 

You mean you had to drag and drop every single one of those objects? You 
couldn’t script their creation automatically? And you are asking for a Python 
equivalent that will make you work just as hard?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Michael Torrie]

On 06/05/2016 10:01 PM, Michael Torrie wrote:
> I've thought about this before and even tried my hand at creating a nice
> library for doing this sort of thing with Python.  Generators seem like
> a natural analog for the shell pipes. However there is one big problem
> with them and that is they can only deal with one stream at a time.
> Whereas in shell programming there are 2 streams that you can use and
> connect simultaneously.  For example I can simultaneously pipe standard
> out from a program to another command whilst piping standard error to
> another.  I never figured out a way to emulate this idea of piping
> multiple streams.

When I say that Python generators can only deal with one stream at a
time I mean within the context of generator syntax:

for x in gen(gen(gen(...)))

Obviously I could write a function that returns two generators.  It's
just that you can't nest them cleanly.  Not that bash's syntax is
particularly clean when you are messing with standard error as well as
standard out.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Michael Torrie]

On 03/02/2016 03:36 PM, Marko Rauhamaa wrote:
> Requirements for what I have in mind:
> 
>  1. It would have to be and feel like real Python.
> 
>  2. External commands should be available as callable Python functions.
> 
>  3. Functions/commands should return streams. (Generators, maybe?)
> 
>  4. Pipelines should have an intuitive syntax (but still be valid
> Python).
> 
> Requirements 3 and 4 apply to regular Python code as well.

I've thought about this before and even tried my hand at creating a nice
library for doing this sort of thing with Python.  Generators seem like
a natural analog for the shell pipes. However there is one big problem
with them and that is they can only deal with one stream at a time.
Whereas in shell programming there are 2 streams that you can use and
connect simultaneously.  For example I can simultaneously pipe standard
out from a program to another command whilst piping standard error to
another.  I never figured out a way to emulate this idea of piping
multiple streams.

In the end I decided that Python's superior text processing facilities
eliminated 90% of the reason to use pipes.  And for the other 10%,
generators worked extremely well and efficiently.

http://www.dabeaz.com/generators/Generators.pdf

When I was doing a lot of shell scripting in Python I wrote my own
wrapper routine to launch programs and obtain stdout and stderr, which I
could process with generator filters and that worked fairly elegantly
for many things.  Kind of a half-way approach but it worked well.
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[MRAB]

On 2016-06-05 08:34, Rustom Mody wrote:

Just came across this new data (for me) to this old question:

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.


A graphic description of the problem:
http://www.hanselman.com/blog/YoureJustAnotherCarriageReturnLineFeedInTheWall.aspx

Along with a solution that is not universally working
https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372

Years ago, I was making PPD (PostScript Printer Description) files for 
Mac and PC. The spec. stated that the line endings could be CR, LF or CR+LF.


All went well until one day someone reported that they wouldn't install 
on a Mac, which they had done previously.


It turned out that the Mac had a newer version of MacOS, which now 
insisted that the line endings be CR only...

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

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

[Rustom Mody]

Just came across this new data (for me) to this old question:

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.

A graphic description of the problem:
http://www.hanselman.com/blog/YoureJustAnotherCarriageReturnLineFeedInTheWall.aspx

Along with a solution that is not universally working
https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Mike S via Python-list]

On 2/27/2016 10:13 AM, 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


FWIW, I have a lot of VB6 experience, and while I was reluctant to do it 
I did write some VB.NET programs and I have to say, MS did a good job 
with the VS IDE, of course they spent a lot of money on it. I'm learning 
Python to see if I want to do AI/ML work with it because I don't want to 
use Azure, but I'm going to keep using VB6 and VB.NET for desktop 
programs where development time and a GUI is needed, just my preference 
based on my experience.


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

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Christian Gollwitzer :

> Have a look at PowerShell. It's not Python, and it is from MS - but it
> works along those lines, passing .NET objects through the pipe. Owing
> to that, instead of $2=="something" in the awk progra, you can address
> the field(attribute) $2 by the correct name instead of a positional
> argument.

Requirements for what I have in mind:

 1. It would have to be and feel like real Python.

 2. External commands should be available as callable Python functions.

 3. Functions/commands should return streams. (Generators, maybe?)

 4. Pipelines should have an intuitive syntax (but still be valid
Python).

Requirements 3 and 4 apply to regular Python code as well.


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

Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?]

[Jon Ribbens]

On 2016-03-02, Chris Angelico  wrote:
> On Thu, Mar 3, 2016 at 5:29 AM, Jon Ribbens
> wrote:
>> On 2016-03-02, Chris Angelico  wrote:
>>> You're no more vulnerable looking at one of those listings
>>> than you would be going to a web site entirely controlled by the
>>> attacker, save that (particularly on mobile devices) there are a lot
>>> of people out there who'll say "Oh, it'e eBay, I'm safe".
>>
>> This however I don't think is true at all. eBay already has a great
>> deal of data about its customers, if an attacker can hijack sessions
>> and steal this data just from a user visiting a listings page then
>> that isn't anything like visiting a random malicious site.
>
> Hmm, maybe. But the description of the exploit talks of getting people
> to click a button to install an app, which is something anyone could
> do with full control of a web site;

I think that's just a proof-of-concept sort of thing. There's much
more interesting things you can do than put up "download this exe
and run it" pop-ups if you can run arbitrary javascript in someone
else's domain.

> the value (to the attacker) of exploiting the eBay filter limitation
> is that it slips it into an otherwise-trusted web site (both from
> the human's point of view -"this is eBay, it's fine" - and from a
> machine filter's - "yes, this is the same site you thought you were
> on").

You can of course just register egay.com (or whatever) and hope for
the best (including putting an SSL cert on it).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Christian Gollwitzer]

Am 02.03.16 um 09:20 schrieb Marko Rauhamaa:

Chris Angelico :


On Wed, Mar 2, 2016 at 4:41 PM, Marko Rauhamaa  wrote:

I was talking about JSON for the standard I/O, not the command-line
arguments, as in:

ps -ef | awk '/httpd/ { print $2 }'

where "ps -ef" emits SPC-separated fields and LF-separated records, and
awk parses and processes them.


If you want to change that, you have to change the entire ecosystem,
not just the shell. You would have to teach every single program to
use a different structure.


Correct. There could be translation utilities in the interim.


A lot of programs already do support NUL-separation - usually with a
-z parameter or something. But you won't be able to magically get them
all to use JSON. And I doubt it would be advantageous anyway.


The advantages are obvious. Barely any programs do proper escaping, and
security problems abound.


Have a look at PowerShell. It's not Python, and it is from MS - but it 
works along those lines, passing .NET objects through the pipe. Owing to 
that, instead of $2=="something" in the awk progra, you can address the 
field(attribute) $2 by the correct name instead of a positional argument.


Christian

Caveat emptor: never used it myself

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

Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?]

[Chris Angelico]

On Thu, Mar 3, 2016 at 5:29 AM, Jon Ribbens
 wrote:
> On 2016-03-02, Chris Angelico  wrote:
>> To be fair, this isn't a JS exploit; it's a trusting-of-trust issue -
>> eBay has declared that you can trust them to sanitize their sellers'
>> listings, and so you trust eBay, but this exploit gets past the
>> filter.
>
> This is true. It sounds like their filter is frankly bizarre,
> I can't imagine why it works the way that has been described.

Agreed. I also don't understand why they can't simply say "no 

Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?]

[Jon Ribbens]

On 2016-03-02, Chris Angelico  wrote:
> To be fair, this isn't a JS exploit; it's a trusting-of-trust issue -
> eBay has declared that you can trust them to sanitize their sellers'
> listings, and so you trust eBay, but this exploit gets past the
> filter.

This is true. It sounds like their filter is frankly bizarre,
I can't imagine why it works the way that has been described.

> You're no more vulnerable looking at one of those listings
> than you would be going to a web site entirely controlled by the
> attacker, save that (particularly on mobile devices) there are a lot
> of people out there who'll say "Oh, it'e eBay, I'm safe".

This however I don't think is true at all. eBay already has a great
deal of data about its customers, if an attacker can hijack sessions
and steal this data just from a user visiting a listings page then
that isn't anything like visiting a random malicious site.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?]

[Chris Angelico]

On Thu, Mar 3, 2016 at 4:05 AM, Steven D'Aprano  wrote:
> Speaking of Javascript exploits:
>
> http://thedailywtf.com/articles/bidding-on-security
>
>
> This is a real exploit, and Ebay have refused to fix it. Yay them!
>
> More here:
>
> http://blog.checkpoint.com/2016/02/02/ebay-platform-exposed-to-severe-vulnerability/

To be fair, this isn't a JS exploit; it's a trusting-of-trust issue -
eBay has declared that you can trust them to sanitize their sellers'
listings, and so you trust eBay, but this exploit gets past the
filter. You're no more vulnerable looking at one of those listings
than you would be going to a web site entirely controlled by the
attacker, save that (particularly on mobile devices) there are a lot
of people out there who'll say "Oh, it'e eBay, I'm safe".

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

Speaking of Javascript [was Re: Everything good about Python except GUI IDE?]

[Steven D'Aprano]

Speaking of Javascript exploits:

http://thedailywtf.com/articles/bidding-on-security


This is a real exploit, and Ebay have refused to fix it. Yay them!

More here:

http://blog.checkpoint.com/2016/02/02/ebay-platform-exposed-to-severe-vulnerability/


-- 
Steven

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

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Gordon Levi :

> I find it difficult to believe that you _love_ updating your contacts
> using Emacs even if it gives you an excuse to get some therapy from
> Eliza. It seems equally unlikely that you can do without phone numbers
> and addresses for your contacts.

WP8 doesn't allow me to modify the contacts using emacs. And to my
knowledge, emacs still doesn't have a phone-call-mode.

I *love* using emacs for everything I can because the whole gamut of
emacs' typing machinery is at my disposal.

I readily admit that reading Wikipedia articles still works better with
Firefox than emacs.


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

Re: Everything good about Python except GUI IDE?

[Gordon Levi]

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.
>
>> 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.

I find it difficult to believe that you _love_ updating your contacts
using Emacs even if it gives you an excuse to get some therapy from
Eliza. It seems equally unlikely that you can do without phone numbers
and addresses for your contacts.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Chris Angelico :

> On Wed, Mar 2, 2016 at 4:41 PM, Marko Rauhamaa  wrote:
>> I was talking about JSON for the standard I/O, not the command-line
>> arguments, as in:
>>
>>ps -ef | awk '/httpd/ { print $2 }'
>>
>> where "ps -ef" emits SPC-separated fields and LF-separated records, and
>> awk parses and processes them.
>
> If you want to change that, you have to change the entire ecosystem,
> not just the shell. You would have to teach every single program to
> use a different structure.

Correct. There could be translation utilities in the interim.

> A lot of programs already do support NUL-separation - usually with a
> -z parameter or something. But you won't be able to magically get them
> all to use JSON. And I doubt it would be advantageous anyway.

The advantages are obvious. Barely any programs do proper escaping, and
security problems abound.

Maybe a starting point would be a Python Toybox (https://en.wikipedia.org/wiki/Toybox>).

Ecosystem intertia aside, key to the success of such an endeavor would
be to find a Python equivalent for

   ps -ef | awk '/httpd/ { print $2 }'

that would be at least as convenient for the fingers and the eye.


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

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Wed, Mar 2, 2016 at 4:41 PM, Marko Rauhamaa  wrote:
> Steven D'Aprano :
>
>> On Wed, 2 Mar 2016 05:06 am, Marko Rauhamaa wrote:
>>> A python shell would need a well-thought-out default import plus a
>>> way to string together external commands. Maybe JSON or similar could
>>> be the standard I/O framing format (instead of SPC-separated fields
>>> and LF-separated records).
>>
>> You really want to be typing JSON by hand instead of space-separated
>> fields/arguments?
>>
>> # Python using JSON
>> ls('["-l", "foo/bar", "spam/ham"]')
>>
>> # bash
>> ls -l foo/bar spam/ham
>>
>> Bugger that for a game of soldiers.
>
> I was talking about JSON for the standard I/O, not the command-line
> arguments, as in:
>
>ps -ef | awk '/httpd/ { print $2 }'
>
> where "ps -ef" emits SPC-separated fields and LF-separated records, and
> awk parses and processes them.

If you want to change that, you have to change the entire ecosystem,
not just the shell. You would have to teach every single program to
use a different structure.

A lot of programs already do support NUL-separation - usually with a
-z parameter or something. But you won't be able to magically get them
all to use JSON. And I doubt it would be advantageous anyway.

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

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Steven D'Aprano :

> On Wed, 2 Mar 2016 05:06 am, Marko Rauhamaa wrote:
>> A python shell would need a well-thought-out default import plus a
>> way to string together external commands. Maybe JSON or similar could
>> be the standard I/O framing format (instead of SPC-separated fields
>> and LF-separated records).
>
> You really want to be typing JSON by hand instead of space-separated
> fields/arguments?
>
> # Python using JSON
> ls('["-l", "foo/bar", "spam/ham"]')
>
> # bash
> ls -l foo/bar spam/ham
>
> Bugger that for a game of soldiers.

I was talking about JSON for the standard I/O, not the command-line
arguments, as in:

   ps -ef | awk '/httpd/ { print $2 }'

where "ps -ef" emits SPC-separated fields and LF-separated records, and
awk parses and processes them.


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

Re: Everything good about Python except GUI IDE?

[Mike]

On Saturday, February 27, 2016 at 6:19:21 AM UTC-5, wrong.a...@gmail.com wrote:
> I have some VB forms with more than a hundred objects. If I cannot drag and 
> drop text boxes, list boxes, labels, etc., it will be too much work to create 
> that with several lines of code for each object. 
> 
> 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.

I'd recommend PyQt/PySide and Eric as an IDE:

http://eric-ide.python-projects.org/index.html 

Eric has good integration with QtDesigner - you can create forms in designer
like in VB and it will automatically generate python code for it or you
can load *.ui files dynamically. The project management and VCS integration
is also very convenient.

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

Re: Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Wed, 2 Mar 2016 05:07 am, Chris Angelico wrote:

> On Wed, Mar 2, 2016 at 3:44 AM, Steven D'Aprano 
> wrote:

>> A better analogy is:
>>
>> When I add cocaine to my stew, the result is a appallingly bad for those
>> who eat it. Do you have any idea how rough cocaine is on the human body
>> and brain? My wife likes the analogy, being on cocaine is like pressing
>> the accelerator of your car all the way to the floor, ALL THE TIME,
>> regardless of whether you are moving forward or stopped at the lights.
>> And yet, for some reason, people seem to like the cocaine-riddled stew,
>> and often ask me to add more cocaine.
>>
>> People cannot get enough of Javascript, no matter what it does to the
>> security and stability of their browser, no matter how many pop-ups it
>> launches or how much spyware and malware it installs, or how many times
>> it kills their browser.
> 
> s/cocaine/sriracha/ and I would agree with you, because there are
> places where JS can majorly enhance a web site, and it isn't going to
> kill you if you use it correctly. 

If by "kill" you mean "compromise your system", then JS absolutely can kill.
Running somebody else's code on your machine could have *any* consequence,
such as installing spyware, a spam-bot, ransomware, a keylogger that
results in your bank account being emptied, or (if the spyware is being run
by people who consider you an enemy of the state) literal death via a
midnight visit from the secret police or a Hellfire missile fired through
your window.


https://community.rapid7.com/community/metasploit/blog/2014/01/23/firefox-privileged-payloads

http://er.educause.edu/blogs/2016/2/fast-forward-javascript-api-exploits

http://arstechnica.com/security/2013/08/attackers-wield-firefox-exploit-to-uncloak-anonymous-tor-users/

https://www.vidder.com/resources/attacks/javascript-device-exploit.html

https://www.usenix.org/legacy/event/woot08/tech/full_papers/daniel/daniel_html/

http://www.mcafee.com/threat-intelligence/malware/default.aspx?id=1487635#vtab-characteristics


(The last one typos the malware as "Java" code, but if you read on you'll
see they actually mean Javascript.)


As a web developer, if you host ads, your viewers at the mercy of malware:

https://en.wikipedia.org/wiki/Malvertising

Most malicious advertising is still written in Flash/ActionScript (a variant
of Javascript), but some use Javascript:

http://www.pcworld.com/article/3039816/security/malvertising-campaigns-are-becoming-harder-to-detect.html




-- 
Steven

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

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Wed, Mar 2, 2016 at 12:51 PM, Steven D'Aprano  wrote:
> On Wed, 2 Mar 2016 05:06 am, Marko Rauhamaa wrote:
>
>> Steven D'Aprano :
>>
>>> On Sun, 28 Feb 2016 11:38 pm, BartC wrote:
 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).
>>>
>>> I haven't physically moved an icon to the wastebasket for years. I
>>> point at the icon, right-click, and tell it "move yourself to the
>>> trash".
>>
>> Do you find that interface convenient? Do you often find yourself
>> clickety-clicking around to perform bulk file operations?
>
> Sometimes. Especially with media files which display a thumbnail, it is far
> more convenient to be able to look at the icon and recognise the file than
> to try to guess from the filename "x73nfh.jpg". And having recognised the
> file visually, its often easier to drag it into the folder of your choice
> than to type "mv x7 dir" in a separate window.
>
> But not always. It's much easier to do "mv foo* dir". Horses for
> courses.

Absolutely. Tab completion *ROCKS* when you know the file name -
point-and-click is *SUPERB* when you want to identify things by some
form of metadata that the GUI can pull out and display (image/video
file thumbnails being one example; executable files can include their
own icons, esp on Windows; etcetera). The downside of the GUI, here,
is that it sometimes is quite costly to generate those thumbnails; tab
completion is done by reading the directory, but thumbnailing a bunch
of JPGs requires reading the file contents (even if you were actually
planning on clicking on one of the text files in the same directory).
Like you say, horses for courses; but in many cases, I'd recommend
starting with the cheap option - the command line - and moving to the
costlier one only in the situations where you know it's of value.

>> What I'm thinking is, could Python turn into a serious competitor to
>> bash? The standard shell suffers greatly from sloppy quoting, and many
>> of the age-old list-processing idioms are more awkward than cute.
>
> No. Python's syntax is too wordy to make a good shell. You need brackets and
> quote marks for everything:
>
> # bash
> ls foo/bar
>
> # Python
> ls("foo/bar")
>
> iPython is usable, by adding non-standard syntax to its REPL. I don't think
> it's a serious contender as replacement for bash, but you could give it a
> try. But the standard Python REPL? No.

>> A python shell would need a well-thought-out default import plus a way
>> to string together external commands. Maybe JSON or similar could be the
>> standard I/O framing format (instead of SPC-separated fields and
>> LF-separated records).

I think the non-standard syntax plan is the way to do it. But the
thing is, you either have a code-like structure where you delimit
everything, or you have the messy rules involving quoting and
interpolation. The well-established basic shell syntax of
space-delimited parameters with optional quoting is a great balance
between verbosity and complexity.

Not sure what "LF-separated records" has to do with "SPC-separated
fields", though. The latter is all about how you type a command, and
the former is all about the way different commands interact via stdin
and stdout.

> You really want to be typing JSON by hand instead of space-separated
> fields/arguments?
>
> # Python using JSON
> ls('["-l", "foo/bar", "spam/ham"]')
>
> # bash
> ls -l foo/bar spam/ham
>
> Bugger that for a game of soldiers.

No kidding, but at least it's consistent. Maybe there's a
middle-ground, where it's still perfectly consistent, while not being
quite as verbose?

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

Re: Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Wed, 2 Mar 2016 05:06 am, Marko Rauhamaa wrote:

> Steven D'Aprano :
> 
>> On Sun, 28 Feb 2016 11:38 pm, BartC wrote:
>>> 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).
>>
>> I haven't physically moved an icon to the wastebasket for years. I
>> point at the icon, right-click, and tell it "move yourself to the
>> trash".
> 
> Do you find that interface convenient? Do you often find yourself
> clickety-clicking around to perform bulk file operations?

Sometimes. Especially with media files which display a thumbnail, it is far
more convenient to be able to look at the icon and recognise the file than
to try to guess from the filename "x73nfh.jpg". And having recognised the
file visually, its often easier to drag it into the folder of your choice
than to type "mv x7 dir" in a separate window.

But not always. It's much easier to do "mv foo* dir". Horses for
courses.


>> Language is pretty important. But when you need to drive a nail into a
>> piece of wood, would you rather hit the nail with a hammer, or explain
>> to the hammer the precise direction and magnitude of force you would
>> like it to apply when it impacts the nails?
> 
> I don't know. My everyday file manipulation needs are so diverse that I
> couldn't imagine how a GUI would make my life easier.

*shrug* 

Then perhaps they're not as diverse as you think.


> What I'm thinking is, could Python turn into a serious competitor to
> bash? The standard shell suffers greatly from sloppy quoting, and many
> of the age-old list-processing idioms are more awkward than cute.

No. Python's syntax is too wordy to make a good shell. You need brackets and
quote marks for everything:

# bash
ls foo/bar

# Python
ls("foo/bar")

iPython is usable, by adding non-standard syntax to its REPL. I don't think
it's a serious contender as replacement for bash, but you could give it a
try. But the standard Python REPL? No.


> A python shell would need a well-thought-out default import plus a way
> to string together external commands. Maybe JSON or similar could be the
> standard I/O framing format (instead of SPC-separated fields and
> LF-separated records).

You really want to be typing JSON by hand instead of space-separated
fields/arguments?

# Python using JSON
ls('["-l", "foo/bar", "spam/ham"]')

# bash
ls -l foo/bar spam/ham

Bugger that for a game of soldiers.




-- 
Steven

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

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Steven D'Aprano :

> On Sun, 28 Feb 2016 11:38 pm, BartC wrote:
>> 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).
>
> I haven't physically moved an icon to the wastebasket for years. I
> point at the icon, right-click, and tell it "move yourself to the
> trash".

Do you find that interface convenient? Do you often find yourself
clickety-clicking around to perform bulk file operations?

> Language is pretty important. But when you need to drive a nail into a
> piece of wood, would you rather hit the nail with a hammer, or explain
> to the hammer the precise direction and magnitude of force you would
> like it to apply when it impacts the nails?

I don't know. My everyday file manipulation needs are so diverse that I
couldn't imagine how a GUI would make my life easier.

What I'm thinking is, could Python turn into a serious competitor to
bash? The standard shell suffers greatly from sloppy quoting, and many
of the age-old list-processing idioms are more awkward than cute.

A python shell would need a well-thought-out default import plus a way
to string together external commands. Maybe JSON or similar could be the
standard I/O framing format (instead of SPC-separated fields and
LF-separated records).

Someone must have tried that before. (Tclsh did that years back but
suffered from analogous problems as bash.)


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

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Wed, Mar 2, 2016 at 3:44 AM, Steven D'Aprano  wrote:
> On Mon, 29 Feb 2016 07:33 pm, Chris Angelico wrote:
>
>> On Mon, Feb 29, 2016 at 7:25 PM, Marko Rauhamaa  wrote:
>>> As for why you should avoid JS/CSS, Web pages open very slowly, jump
>>> around wildly during rendering and have unexpected artifacts (not to
>>> mention the numerous data collection abuses) when they are encumbered
>>> with truckloads of state-of-the-art web dev gimmicks.
>>
>> And when I pick up a paintbrush, canvas, and oil paints, the result is
>> appallingly hard on the eyes. Clearly oil paints should not be used,
>> and we should just place the brush tastefully on the canvas, because
>> that is guaranteed to look good.
>>
>> Don't blame the tool for its poor users.
>
> A better analogy is:
>
> When I add cocaine to my stew, the result is a appallingly bad for those who
> eat it. Do you have any idea how rough cocaine is on the human body and
> brain? My wife likes the analogy, being on cocaine is like pressing the
> accelerator of your car all the way to the floor, ALL THE TIME, regardless
> of whether you are moving forward or stopped at the lights. And yet, for
> some reason, people seem to like the cocaine-riddled stew, and often ask me
> to add more cocaine.
>
> People cannot get enough of Javascript, no matter what it does to the
> security and stability of their browser, no matter how many pop-ups it
> launches or how much spyware and malware it installs, or how many times it
> kills their browser.

s/cocaine/sriracha/ and I would agree with you, because there are
places where JS can majorly enhance a web site, and it isn't going to
kill you if you use it correctly. But while we might disagree on the
precise boundary between "good JS" and "bad JS", it seems we're pretty
vehemently in agreement that there are a lot of sites out there that
serve up a stew that burns the paint off buildings in the next county.

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

Re: Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Mon, 29 Feb 2016 07:33 pm, Chris Angelico wrote:

> On Mon, Feb 29, 2016 at 7:25 PM, Marko Rauhamaa  wrote:
>> As for why you should avoid JS/CSS, Web pages open very slowly, jump
>> around wildly during rendering and have unexpected artifacts (not to
>> mention the numerous data collection abuses) when they are encumbered
>> with truckloads of state-of-the-art web dev gimmicks.
> 
> And when I pick up a paintbrush, canvas, and oil paints, the result is
> appallingly hard on the eyes. Clearly oil paints should not be used,
> and we should just place the brush tastefully on the canvas, because
> that is guaranteed to look good.
> 
> Don't blame the tool for its poor users.

A better analogy is:

When I add cocaine to my stew, the result is a appallingly bad for those who
eat it. Do you have any idea how rough cocaine is on the human body and
brain? My wife likes the analogy, being on cocaine is like pressing the
accelerator of your car all the way to the floor, ALL THE TIME, regardless
of whether you are moving forward or stopped at the lights. And yet, for
some reason, people seem to like the cocaine-riddled stew, and often ask me
to add more cocaine.

People cannot get enough of Javascript, no matter what it does to the
security and stability of their browser, no matter how many pop-ups it
launches or how much spyware and malware it installs, or how many times it
kills their browser.



-- 
Steven

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

Re: Everything good about Python except GUI IDE?

[Steven D'Aprano]

On Sun, 28 Feb 2016 11:38 pm, 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).

I haven't physically moved an icon to the wastebasket for years. I point at
the icon, right-click, and tell it "move yourself to the trash".


> More advanced uses have the power of language, with all its
> sophistications (ie. commands lines and scripting). 

Language is pretty important. But when you need to drive a nail into a piece
of wood, would you rather hit the nail with a hammer, or explain to the
hammer the precise direction and magnitude of force you would like it to
apply when it impacts the nails?



-- 
Steven

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

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Tue, Mar 1, 2016 at 1:33 PM, Terry Reedy  wrote:
> On 2/29/2016 3:20 AM, Chris Angelico wrote:
>
>> Incidentally, HTML+CSS is another excellent example of code being used
>> to create a visual effect. While there *are* WYSIWYG HTML editors, I'm
>> not familiar with any WYISWYG HTML+CSS editors, and I much more often
>> see a fast-turnaround code editing system such as codepen.io - you
>> change the HTML in one box, or the CSS in another, and the result down
>> below changes in real-time.
>
>
> Does it change with each key stroke (if the keystroke leaves the text in a
> coherent, non-error state) or only on some special input?

In the case of codepen, it's not quite either; when you finish typing
and leave it for half a second, it updates. Not quite instant, but
automiatic.

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

Re: Everything good about Python except GUI IDE?

[Terry Reedy]

On 2/29/2016 3:20 AM, Chris Angelico wrote:


Incidentally, HTML+CSS is another excellent example of code being used
to create a visual effect. While there *are* WYSIWYG HTML editors, I'm
not familiar with any WYISWYG HTML+CSS editors, and I much more often
see a fast-turnaround code editing system such as codepen.io - you
change the HTML in one box, or the CSS in another, and the result down
below changes in real-time.


Does it change with each key stroke (if the keystroke leaves the text in 
a coherent, non-error state) or only on some special input?



It wouldn't be too hard to create
something like this for a GUI, and it'd remove some of that feeling of
non-interactivity while still retaining all the benefits of code above
drag-and-drop.


Keystroke auto-updates hardly make sense.  On-demand updates for tkinter 
are already possible.  By default, tk root windows, Python interpreter, 
Idle Shell, and IDLE Editors windows appear in the upper left of a 
screen.  Move either the tk or the python window(s) to the right.



1. REPL (python or IDLE): Possible updates are signaled by \n.  Tkinter 
visibly responds, when appropriate, on a statement by statement basis.


>>> import tkinter as tk
>>> root = tk.Tk()  # root window appears
>>> b = tk.Button(root)  # text='', bg='white' are defaults
>>> b.grid()  # button appears in root window
>>> b['text'] = 'Hello World!'  # text appears in button
>>> b['bg'] = 'red'  # background color changes

(Non-default options can also be set when a widget is created.)
One can even, I just discovered, setup timer events interactively.

>>> root.after(500, lambda: b.config(bg='blue', text='done'))
# after 1/2 second (500 milliseconds), bg and text change

The disadvantage of this method is that the REPL record must be saved 
and processed to reuse it.



2. Editor (IDLE): Run with F5 to see the result of any changes.  The 
root window appears in a fraction of a second and population by widgets 
hardly takes much longer.  I think that this is close enough to 
interactive for most purposes.



3. Editor + REPL (IDLE): Since F5 simulates running the file with 
'python -i', this is automatic if the file in the editor does not run 
'root.mainloop()'.  If it does, the following in the file will allow one 
to end the blocking mainloop() call without also calling root.destroy 
and destroying the gui.


tk.Button(root, text='quit mainloop', command=root.quit).grid()


4. Integrated Editor and Display: your idea.  I think "It wouldn't be 
too hard" is wildly over-optimistic, as I will now explain>


The turtle demo (python -m turtledemo) has read-only text on the left, a 
turtle screen on the right, and a 'Start' button.  The text is read-only 
to avoid overwriting the supplied demo files.  People who want to edit 
them are supposed to copy and paste into an editor, such as IDLE's.)


The demo files must be and are (after failures) written in a special 
style to run properly within the demo framework, ... and to not disturb 
the buildbots when imported as part of test/test_all.  Top level code 
should only have definitions, including a 'def main' entry point, 
non-gui statements, and a '__main__'-guarded conditional statement for 
initiating gui actions.  They must also not bypass the turtle wrapping 
of tkinter to make direct tkinter calls that would disable the demo 
runner itself.  So even if turtledemo were turned into turtle-designer, 
by replacing the text pane with an editor, it could not be used for all 
legal turtle programs.


A GUI designer would replace the turtle screen also, with a gui frame. 
The special style would be something like the following template.


import tkinter as tk  # or "from tkinter import x, y, z, ..."
# define classes and functions

def main(parent):
# call classes, passing parent
# set up timers with parent.after
# anything else requiring that root exist

if __name__ == '__main__':
root = tk.Tk()
main(root)
root.mainloop()

The important point is that it must be possible to import the script 
without it creating a new root window or creating events. The app would 
run the user code with


user_gui = importlib.import_module(file_path)
user_gui.main(gui_frame)

Importing the code after saving, rather than using exec on the editor 
contents, isolates it somewhat from the app, but not enough.  Passing 
app's gui_frame into main and making that the parent of everything in 
the user gui ties the user gui into the app.  However, it also allows 
the app to inadvertently affect the app.  Non-interference between IDLE 
and user code, especially tkinter code, was the reason that IDLE was 
re-written, around a decade ago, to run user code in a separate process.


Another issue is handling user code errors.  Syntax errors can be marked 
in the editor, but tracebacks need a separate pane.  And it is also 
useful to be able to interact with the gui without altering the code in 
the editor.


Summary: if one starts with the idea of an 

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Tue, Mar 1, 2016 at 5:17 AM, Grant Edwards  wrote:
>> A lot of web sites these days load nothing but a script
>> that goes and loads everything else, while you gaze at a splash
>> screen. IMO that's unideal.
>
> :)
>
> "Unideal" is too kind -- I would described it as something more like
> "the evil spawn of brain-dead incompetents".  I often wonder what
> sequence of decisions/accidents get people to "solutions" like that.

I do understand where the thinking comes from, though.

1) Pages should be more responsive than the 1990s-style CGI model,
where every action is a link or button click that completely replaces
the current page.
2) Many actions therefore must be implemented using JavaScript, an
AJAX call (if necessary), and DOM manipulation to change just the
parts of the page that need to be changed.
3) This means that the entire content of the page must be under JS
control, and the entire "user-accessible" part of the back end should
be returning JSON, since that's what #2 requires.
4) If everything has to be under JS control, why not just send out a
stub to start with, and begin everything with an AJAX call? That way,
we don't need to maintain two of everything!

The logic is reasonable. Deduplication is valuable. But the result is
a web site that has a stubby splash screen until the back end
responds, and that's why I call it merely "unideal" rather than "evil
spawn ".

>> However, even that is probably a losing battle. :(
>
> At least the era of using giant tables full of fragements of a single
> large gif image to do page-layout seems to have died a long-overdue
> death...

Oh yes, I do not miss those days! And it was compounded by browsers
that, when they started receiving a  tag, drew nothing
whatsoever until they received the  and could lay the whole
thing out. Add to that slow internet connections, so it would likely
be some seconds or even a minute or more before the  arrives,
and you have a perfect recipe for frustration.

But no web site these days would ever make you wait for its contents.
'Course not.

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

Re: Everything good about Python except GUI IDE?

[Grant Edwards]

On 2016-02-29, Chris Angelico  wrote:
> On Tue, Mar 1, 2016 at 2:43 AM, Grant Edwards  wrote:
>> On 2016-02-29, Chris Angelico  wrote:
>>
>>> Abjuring JS may be a virtue (or at least, making it a non-critical
>>> part of your web site),
>>
>> Except the marketing people who decide on the requirements will never,
>> ever settle for what you can do with plain HTML/CSS.
>>
>> In my experience, HTML/CSS makes a pretty awful GUI for a non-trivial
>> application.  With some Javascript and sweat, you can almost make it
>> to mediocre.
>
> That's why I said "may be". A pure CGI web site is pretty annoying
> unless it's really brilliantly done. However, I prefer to see JS
> restricted to actual interaction, instead of making it critical to the
> basic layout.

Agreed. That's an excellent rule to follow.  The introduction of the
"flex" display type in CSS has (for me) completely eliminated the need
for JS to concern itself with display and layout (other than the basic
hide/show enable/disable of optional elements as part of an
application's interaction logic).

I don't know why it took so long for CSS to grok the basic idea that
you almost always want to specify that some blocks should
expand/contract to fill available space and some should remain at
their "natural" size.  GUI toolkits and markup languages like LaTeX
seem to have understood that this was a very basic need for many
decades, but there was never a clean, reliable way to do it CSS until
recently.

> A lot of web sites these days load nothing but a script
> that goes and loads everything else, while you gaze at a splash
> screen. IMO that's unideal.

:)

"Unideal" is too kind -- I would described it as something more like
"the evil spawn of brain-dead incompetents".  I often wonder what
sequence of decisions/accidents get people to "solutions" like that.

> However, even that is probably a losing battle. :(

At least the era of using giant tables full of fragements of a single
large gif image to do page-layout seems to have died a long-overdue
death...

-- 
Grant Edwards   grant.b.edwardsYow! does your DRESSING
  at   ROOM have enough ASPARAGUS?
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Tue, Mar 1, 2016 at 2:43 AM, Grant Edwards  wrote:
> On 2016-02-29, Chris Angelico  wrote:
>
>> Abjuring JS may be a virtue (or at least, making it a non-critical
>> part of your web site),
>
> Except the marketing people who decide on the requirements will never,
> ever settle for what you can do with plain HTML/CSS.
>
> In my experience, HTML/CSS makes a pretty awful GUI for a non-trivial
> application.  With some Javascript and sweat, you can almost make it
> to mediocre.

That's why I said "may be". A pure CGI web site is pretty annoying
unless it's really brilliantly done. However, I prefer to see JS
restricted to actual interaction, instead of making it critical to the
basic layout. A lot of web sites these days load nothing but a script
that goes and loads everything else, while you gaze at a splash
screen. IMO that's unideal.

However, even that is probably a losing battle. :(

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

Re: Everything good about Python except GUI IDE?

[Grant Edwards]

On 2016-02-29, Chris Angelico  wrote:

> Abjuring JS may be a virtue (or at least, making it a non-critical
> part of your web site),

Except the marketing people who decide on the requirements will never,
ever settle for what you can do with plain HTML/CSS.

In my experience, HTML/CSS makes a pretty awful GUI for a non-trivial
application.  With some Javascript and sweat, you can almost make it
to mediocre.

> but CSS is important to document structure and layout. The
> combination of HTML and CSS provides a logical structure with
> separate styling, which IMO is an excellent thing.

Indeed.  Separating the visual appearnce stuff from the "structure"
makes it a lot easier to deal with both, and the result is a lot more
robust as well.

-- 
Grant Edwards   grant.b.edwardsYow! The Korean War must
  at   have been fun.
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[BartC]

On 29/02/2016 00:49, Steven D'Aprano wrote:

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?


An outsider would be using their own methods, perhaps some more apt DTP 
solution; I wouldn't know.



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.


Possibly, but just because it could, maybe it does so in a complicated 
manner. Or maybe it's wasn't flexible. Or maybe some things I needed 
just weren't possible.


(How did it do contents, appendices, indices, references to labelled 
items in the rest of the text? One manual I did was for the very script 
language I was using: how could Word render code, and do so with 
automatic highlighting (eg boldening) of keywords for a language it knew 
nothing about?)


And my experience is that a lot of these things were incredibly fiddly 
anyway. I'm really the sort of guy who needs to have separate plain-text 
and rendered verions of a document.



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.


The language wasn't created just for this purpose. It was part of the 
application the manual was about. And in fact it had its own manual 
later on. The graphics application was also the one used to preview the 
rendered pages before sending them off to a Postscript printer.


(And actually some of the diagrams were in a 3D vector format belonging 
to the application, a projection of which could sent as vector graphics 
to PS; I would have needed to rasterise them for Word.


So in some ways, my solution was more sophisticated than using Word.)


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/


Actually I can't remember how long it took. I know I spent some time 
building font-data tables for the fonts which only existed inside the 
Postscript printer.



(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 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.


Yes but you have to keep doing it. It's not just Word; even Thunderbird 
(which I'm using right now) sometimes gets in a twist about quoted text 
(shown in blue) and new text shown in black. It wouldn't matter but 
quoted text doesn't wrap at the ends of lines.


It also keeps screwing up any copy and paste that happens to have 
indents. Here's one example:


One
Two
Three

And if I do a simple copy and paste:

One
Two
Three

And it's not always as simple as just stripping leading spaces; 
sometimes they are just munged. And I haven't even posted yet which 
often gives yet more unexpected results.


Now someone is going to tell me what I'm doing wrong. I need to set X in 
Y to Z; obviously! The point is that it should Just Work. Multiply these 
little things by dozens of examples and you will see how using Other 
People's Software can often be a complete pain.




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

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Chris Angelico :
> On Mon, Feb 29, 2016 at 7:25 PM, Marko Rauhamaa  wrote:
>> As for why you should avoid JS/CSS, Web pages open very slowly, jump
>> around wildly during rendering and have unexpected artifacts (not to
>> mention the numerous data collection abuses) when they are encumbered
>> with truckloads of state-of-the-art web dev gimmicks.
>
> And when I pick up a paintbrush, canvas, and oil paints, the result is
> appallingly hard on the eyes. Clearly oil paints should not be used,
> and we should just place the brush tastefully on the canvas, because
> that is guaranteed to look good.
>
> Don't blame the tool for its poor users.

In that vein...

   The men turned away and went toward Sodom, but Abraham remained
   standing before the Lord. Then Abraham approached him and said: “Will
   you sweep away the righteous with the wicked? What if there are fifty
   righteous people in the city? Will you really sweep it away and not
   spare the place for the sake of the fifty righteous people in it? Far
   be it from you to do such a thing—to kill the righteous with the
   wicked, treating the righteous and the wicked alike. Far be it from
   you! Will not the Judge of all the earth do right?”

   The Lord said, “If I find fifty righteous people in the city of
   Sodom, I will spare the whole place for their sake.”

   Then Abraham spoke up again: “Now that I have been so bold as to
   speak to the Lord, though I am nothing but dust and ashes, what if
   the number of the righteous is five less than fifty? Will you destroy
   the whole city for lack of five people?”

   “If I find forty-five there,” he said, “I will not destroy it.”

   Once again he spoke to him, “What if only forty are found there?”

   He said, “For the sake of forty, I will not do it.”

   Then he said, “May the Lord not be angry, but let me speak. What if
   only thirty can be found there?”

   He answered, “I will not do it if I find thirty there.”

   Abraham said, “Now that I have been so bold as to speak to the Lord,
   what if only twenty can be found there?”

   He said, “For the sake of twenty, I will not destroy it.”

   Then he said, “May the Lord not be angry, but let me speak just once
   more. What if only ten can be found there?”

   He answered, “For the sake of ten, I will not destroy it.”

   When the Lord had finished speaking with Abraham, he left, and
   Abraham returned home.

   https://www.biblegateway.com/passage/?search=Genesis%2018
   n=NIV>

   Early the next morning Abraham got up and returned to the place where
   he had stood before the Lord. He looked down toward Sodom and
   Gomorrah, toward all the land of the plain, and he saw dense smoke
   rising from the land, like smoke from a furnace.

   https://www.biblegateway.com/passage/?search=Genesis%2019
   n=NIV>


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

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

Chris Angelico :

> CSS is important to document structure and layout.

Most Web pages had better not concern themselves with layout but with
info content only. Unfortunately, HTML is a dirt-poor language for
markup (no extensibility or programmability) so I can understand the
temptation to side-step it with CSS.

CSS has tons of esoterics but seems to lack some very basic facilities
so I can understand the temptation to side-step it with JavaScript.

> Incidentally, HTML+CSS is another excellent example of code being used
> to create a visual effect. While there *are* WYSIWYG HTML editors, I'm
> not familiar with any WYISWYG HTML+CSS editors, and I much more often
> see a fast-turnaround code editing system such as codepen.io - you
> change the HTML in one box, or the CSS in another, and the result down
> below changes in real-time. It wouldn't be too hard to create
> something like this for a GUI, and it'd remove some of that feeling of
> non-interactivity while still retaining all the benefits of code above
> drag-and-drop.

Yes, WYSIWYG is a doomed approach. There's a difference between input
and output.


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

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Mon, Feb 29, 2016 at 7:25 PM, Marko Rauhamaa  wrote:
> As for why you should avoid JS/CSS, Web pages open very slowly, jump
> around wildly during rendering and have unexpected artifacts (not to
> mention the numerous data collection abuses) when they are encumbered
> with truckloads of state-of-the-art web dev gimmicks.

And when I pick up a paintbrush, canvas, and oil paints, the result is
appallingly hard on the eyes. Clearly oil paints should not be used,
and we should just place the brush tastefully on the canvas, because
that is guaranteed to look good.

Don't blame the tool for its poor users.

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

Re: Everything good about Python except GUI IDE?

[Marko Rauhamaa]

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?

I have used some minute amounts of CSS when I have wanted to pay
attention to the aesthetics (http://pacujo.net/esperanto/literaturo/juho/>).

However, then the point is conveying/exchanging info, straight HTML is
all that is needed: http://pacujo.net/esperanto/course/>.

As for why you should avoid JS/CSS, Web pages open very slowly, jump
around wildly during rendering and have unexpected artifacts (not to
mention the numerous data collection abuses) when they are encumbered
with truckloads of state-of-the-art web dev gimmicks.


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

Re: Everything good about Python except GUI IDE?

[Chris Angelico]

On Mon, Feb 29, 2016 at 6:20 PM, Rustom Mody  wrote:
> 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?

Abjuring JS may be a virtue (or at least, making it a non-critical
part of your web site), but CSS is important to document structure and
layout. The combination of HTML and CSS provides a logical structure
with separate styling, which IMO is an excellent thing. It's possible
to accomplish the same goal in other ways (for instance, Markdown
source code for the structure and HTML for the layout), but CSS
provides enough flexibility to do this just fine on its own.

Incidentally, HTML+CSS is another excellent example of code being used
to create a visual effect. While there *are* WYSIWYG HTML editors, I'm
not familiar with any WYISWYG HTML+CSS editors, and I much more often
see a fast-turnaround code editing system such as codepen.io - you
change the HTML in one box, or the CSS in another, and the result down
below changes in real-time. It wouldn't be too hard to create
something like this for a GUI, and it'd remove some of that feeling of
non-interactivity while still retaining all the benefits of code above
drag-and-drop.

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

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: 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: 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: 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: 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: 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 

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: 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: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: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

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: 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

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?

[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 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?

[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?

[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: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?

[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?

[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?

[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: 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?

[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 

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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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: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?

[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: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?

[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?

[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?

[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: 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 

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?

[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?

[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 

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?

[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?

[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?

[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 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: 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?

[Rustom Mody]

On Sunday, February 28, 2016 at 12:04:52 PM UTC+5:30, 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.
> 
> 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.
> 
> 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. 
> 
> (By 2016 standards the UI of Hypercard would seem a bit old fashioned and
> primitive -- black and white, bitmapped graphics, no magnetic guides
> or "replicate" command, etc -- but it was the mid 80s. A modern GUI builder
> wouldn't have those limitations.)
> 
> Hypercard let you create a place widgets by hand using the mouse, or by
> running a one-line command in the "Message Box" (a simple command
> interpreter), and for complex tasks, or by writing a script and executing
> it. You didn't have to script the *entire* application, just as much or as
> little as needed scripting.
> 
> Python would be especially well-suited to this, being an interpreter. Why
> should I have to batch up all the GUI elements and run them all at once to
> see what my application looks like? Why can't I add elements interactively?
> 
> I've made a number of attempts to get into GUI development in Python, and
> every time I flounder at the lousy state of the art in GUI builder tools.
> Yes, the widget set is fantastic. But putting the GUIs together is
> primitive beyond words.
> 
> Hypercard, bless Bill Atkinson, is long gone but not forgotten. But today it
> lives on in the guise of LiveCode:
> 
> http://livecode.com/
> 
> 
> If only I could get the Linux installer to actually, you know, *work*.
> 
> 
> -- 
> Steven


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?

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

Re: Everything good about Python except GUI IDE?

[Steven D'Aprano]

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.

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.

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. 

(By 2016 standards the UI of Hypercard would seem a bit old fashioned and
primitive -- black and white, bitmapped graphics, no magnetic guides
or "replicate" command, etc -- but it was the mid 80s. A modern GUI builder
wouldn't have those limitations.)

Hypercard let you create a place widgets by hand using the mouse, or by
running a one-line command in the "Message Box" (a simple command
interpreter), and for complex tasks, or by writing a script and executing
it. You didn't have to script the *entire* application, just as much or as
little as needed scripting.

Python would be especially well-suited to this, being an interpreter. Why
should I have to batch up all the GUI elements and run them all at once to
see what my application looks like? Why can't I add elements interactively?

I've made a number of attempts to get into GUI development in Python, and
every time I flounder at the lousy state of the art in GUI builder tools.
Yes, the widget set is fantastic. But putting the GUIs together is
primitive beyond words.

Hypercard, bless Bill Atkinson, is long gone but not forgotten. But today it
lives on in the guise of LiveCode:

http://livecode.com/


If only I could get the Linux installer to actually, you know, *work*.


-- 
Steven

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

Re: Everything good about Python except GUI IDE?

[Gordon Levi]

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.

When I moved from VB "Classic" to new a language I chose Java. The
Netbeans IDE includes a drag and drop WYSIWYG form designer similar
to, but slightly better than, VB6
. Alas, thick
desktop applications are rapidly becoming out of date.

When I chose Java it was the most popular language for commercial
programming apart from .NET. I was subsequently tempted to move to
Python because I have been programming for the Raspberry Pi and Python
is the language of choice for the Pi. In addition I find Python more
readable than Java. I have been deterred because, like VB, there are
two distinct flavours and, unlike VB, there is no IDE with a form
designer.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Dietmar Schwertberger]

On 27.02.2016 19:51, Dietmar Schwertberger wrote:

You will find many "Getting started with..." for both PyQt and wxPython.
P.S.: I forgot to mention that both toolkits have very helpful mailing 
lists.


The toolkits have different licenses. With wxPython you don't need to 
worry. For PyQt you should check which versions and licenses of PyQt and 
Qt are applicable and whether they are OK for your purpose.


Regards,

Dietmar

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

Re: Everything good about Python except GUI IDE?

[MRAB]

On 2016-02-27 20:52, Mark Lawrence wrote:

On 27/02/2016 17:57, Marco Kaulea wrote:

Hi,

Haven't tried it myself, but pyforms[1] might suit your needs.

- Marco

[1] http://pyforms.readthedocs.org/en/latest/



PyForms 0.1.3 last updated on pypi 2016-01-17 and it's 2.7 only, just
awesome, not.

It's a little ambiguous. It says "Pyforms is a Python 2.7.x and 3.x 
cross-enviroment framework", but the Requirements list Python 2.7 only.


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

Re: Everything good about Python except GUI IDE?

[Mark Lawrence]

On 27/02/2016 17:57, Marco Kaulea wrote:

Hi,

Haven't tried it myself, but pyforms[1] might suit your needs.

- Marco

[1] http://pyforms.readthedocs.org/en/latest/



PyForms 0.1.3 last updated on pypi 2016-01-17 and it's 2.7 only, just 
awesome, not.


--
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?

[Anthony Papillion]

I would absolutely recommend you take a look at the Qt stuff.  Very modern, 
easy to use,  and free for non-commercial products.  

Anthony 

On February 27, 2016 5:18:57 AM CST, wrong.addres...@gmail.com wrote:
>I have some VB forms with more than a hundred objects. If I cannot drag
>and drop text boxes, list boxes, labels, etc., it will be too much work
>to create that with several lines of code for each object. 
>
>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.
>-- 
>https://mail.python.org/mailman/listinfo/python-list

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Everything good about Python except GUI IDE?

[Dietmar Schwertberger]

On 27.02.2016 19:13, wrong.addres...@gmail.com wrote:

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.

I would recommend the Python option...


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 PyQt with Qt Designer the development flow looks like e.g. 
https://nikolak.com/pyqt-qt-designer-getting-started/
For non-trivial GUIs you will probably find it easier to create the GUI 
in Python code yourself. But maybe the created Python code will show you 
how to use PyQt in the beginning.


You will find many "Getting started with..." for both PyQt and wxPython.

For either GUI toolkit, you should get a book - either "wxPython in 
Action" or "Rapid GUI Programming with Python and Qt" (or both).


For both toolkits the electronic documentation is not for Python but for 
C++.
For wxPython you get a .chm help file, which contains all documentation 
in one file and a wxPython demo which contains a browser and example 
code for almost all GUI components.
For PyQt the documentation is online. While it is quite complete, I 
always have difficulties to find the information I'm looking for...


wxPython is currently not really an option for Python 3, but this will 
change very soon. (Well, it can be used with Python 3 already, but for a 
beginner I would recommend to start with the so called "classic" version 
for Python 2, especially as the included demo will be the main source of 
information.)



For debugging you just run the interpreter with the .py file. It's 
reasonably simple to debug with e.g. WingIDE.
When you create a GUI in Python code, it's often the easiest way to 
explore properties and methods of the GUI classes from the debugger prompt.



Regards,

Dietmar

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