Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #103575 > unrolled thread

Everything good about Python except GUI IDE?

Back to article view | Back to comp.lang.python

Contents

  Everything good about Python except GUI IDE? wrong.address.1@gmail.com - 2016-02-27 03:18 -0800
    Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-27 22:36 +1100
    Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-27 04:02 -0800
    Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-27 23:07 +1100
      Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-28 17:34 +1100
        Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-27 23:39 -0800
          Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-28 19:49 +1100
        Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-28 19:44 +1100
          Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 02:25 -0800
            Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-28 21:34 +1100
              Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-02-29 00:08 +1100
                Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 05:13 -0800
                  Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-02-29 00:24 +1100
                    Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 05:49 -0800
                      Re: Everything good about Python except GUI IDE? Chris Warrick <kwpolska@gmail.com> - 2016-02-28 15:00 +0100
                        Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 06:11 -0800
                          Re: Everything good about Python except GUI IDE? Chris Warrick <kwpolska@gmail.com> - 2016-02-28 15:26 +0100
                            Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 08:50 -0800
                            Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-29 11:39 +1100
                              Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-29 11:54 +1100
                              Re: Everything good about Python except GUI IDE? Ben Finney <ben+python@benfinney.id.au> - 2016-02-29 12:05 +1100
                              Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-29 12:13 +1100
                              Lineendings (was Everything good about Python except GUI IDE?) Rustom Mody <rustompmody@gmail.com> - 2016-02-28 17:39 -0800
                                Re: Lineendings (was Everything good about Python except GUI IDE?) Chris Angelico <rosuav@gmail.com> - 2016-02-29 12:49 +1100
                                  Re: Lineendings (was Everything good about Python except GUI IDE?) Rustom Mody <rustompmody@gmail.com> - 2016-02-28 17:55 -0800
                                    Re: Lineendings (was Everything good about Python except GUI IDE?) Chris Angelico <rosuav@gmail.com> - 2016-02-29 13:02 +1100
                                      Re: Lineendings (was Everything good about Python except GUI IDE?) Rustom Mody <rustompmody@gmail.com> - 2016-02-28 18:08 -0800
                                        Re: Lineendings (was Everything good about Python except GUI IDE?) Ben Finney <ben+python@benfinney.id.au> - 2016-02-29 13:35 +1100
                                          Re: Lineendings (was Everything good about Python except GUI IDE?) Rustom Mody <rustompmody@gmail.com> - 2016-02-28 20:48 -0800
                      Re: Everything good about Python except GUI IDE? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-02-28 17:09 +0000
                  Re: Everything good about Python except GUI IDE? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-28 11:56 -0500
                    Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-03-02 20:44 +1100
          Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-28 23:50 +1100
            Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-29 04:53 +1100
              Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-29 13:22 +1100
                Re: Everything good about Python except GUI IDE? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-02-29 17:40 +1300
        Re: Everything good about Python except GUI IDE? "Sven R. Kunze" <srkunze@mail.de> - 2016-02-28 13:23 +0100
        Re: Everything good about Python except GUI IDE? BartC <bc@freeuk.com> - 2016-02-28 12:38 +0000
          Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 04:54 -0800
            Re: Everything good about Python except GUI IDE? BartC <bc@freeuk.com> - 2016-02-28 13:07 +0000
              Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 05:20 -0800
                Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-28 15:51 +0200
                  Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 06:03 -0800
                    Re: Everything good about Python except GUI IDE? BartC <bc@freeuk.com> - 2016-02-28 14:29 +0000
                      Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-29 11:49 +1100
                        Re: Everything good about Python except GUI IDE? BartC <bc@freeuk.com> - 2016-02-29 11:56 +0000
                      Re: Everything good about Python except GUI IDE? Terry Reedy <tjreedy@udel.edu> - 2016-02-28 19:49 -0500
                    Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-28 17:08 +0200
                      Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 08:41 -0800
                        Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-28 23:38 +0200
                      Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-02-29 15:47 +1100
                        Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-29 08:18 +0200
                          Re: Everything good about Python except GUI IDE? Rustom Mody <rustompmody@gmail.com> - 2016-02-28 23:20 -0800
                            Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-29 19:20 +1100
                              Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-29 10:37 +0200
                              Re: Everything good about Python except GUI IDE? Grant Edwards <invalid@invalid.invalid> - 2016-02-29 15:43 +0000
                                Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-01 03:17 +1100
                                  Re: Everything good about Python except GUI IDE? Grant Edwards <invalid@invalid.invalid> - 2016-02-29 18:17 +0000
                                    Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-01 05:31 +1100
                            Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-29 10:25 +0200
                              Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-29 19:33 +1100
                                Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-29 10:46 +0200
                                Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-03-02 03:44 +1100
                                  Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-02 05:07 +1100
                                    Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-03-02 13:22 +1100
                                      Speaking of Javascript [was Re: Everything good about Python except GUI IDE?] Steven D'Aprano <steve@pearwood.info> - 2016-03-03 04:05 +1100
                                        Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?] Chris Angelico <rosuav@gmail.com> - 2016-03-03 04:46 +1100
                                          Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?] Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-02 18:29 +0000
                                            Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?] Chris Angelico <rosuav@gmail.com> - 2016-03-03 07:55 +1100
                                              Re: Speaking of Javascript [was Re: Everything good about Python except GUI IDE?] Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-02 22:01 +0000
                            Re: Everything good about Python except GUI IDE? Terry Reedy <tjreedy@udel.edu> - 2016-02-29 21:33 -0500
                            Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-01 15:31 +1100
                          Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-03-02 20:44 +1100
                            Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 13:57 +0200
                  Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-02-29 11:14 +1100
              Re: Everything good about Python except GUI IDE? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-28 12:08 -0500
          Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-03-02 03:35 +1100
            Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-03-01 20:06 +0200
              Re: Everything good about Python except GUI IDE? wxjmfauth@gmail.com - 2016-03-01 11:30 -0800
                Re: Everything good about Python except GUI IDE? wxjmfauth@gmail.com - 2016-03-01 11:39 -0800
              Re: Everything good about Python except GUI IDE? Steven D'Aprano <steve@pearwood.info> - 2016-03-02 12:51 +1100
                Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-02 13:15 +1100
                Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 07:41 +0200
                  Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-03-02 16:58 +1100
                    Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 10:20 +0200
                      Re: Everything good about Python except GUI IDE? Christian Gollwitzer <auriocus@gmx.de> - 2016-03-02 23:00 +0100
                        Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-03-03 00:36 +0200
        Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-28 13:38 +0100
          Re: Everything good about Python except GUI IDE? cl@isbd.net - 2016-02-28 12:52 +0000
            Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-28 14:19 +0100
        Re: Everything good about Python except GUI IDE? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-28 12:03 -0500
        Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-28 18:41 +0100
    Re: Everything good about Python except GUI IDE? BartC <bc@freeuk.com> - 2016-02-27 13:35 +0000
    Re: Everything good about Python except GUI IDE? MWS <miragewebstudio12@gmail.com> - 2016-02-27 20:05 +0530
    Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-27 15:20 +0100
      Re: Everything good about Python except GUI IDE? wrong.address.1@gmail.com - 2016-02-27 10:13 -0800
        Re: Everything good about Python except GUI IDE? Chris Angelico <rosuav@gmail.com> - 2016-02-28 05:29 +1100
        Re: Everything good about Python except GUI IDE? Marko Rauhamaa <marko@pacujo.net> - 2016-02-27 20:35 +0200
        Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-27 19:51 +0100
        Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-28 00:20 +0100
        Re: Everything good about Python except GUI IDE? Gordon Levi <gordon@address.invalid> - 2016-02-28 16:49 +1100
        Re: Everything good about Python except GUI IDE? Sibylle Koczian <nulla.epistola@web.de> - 2016-02-28 11:46 +0100
        Re: Everything good about Python except GUI IDE? Virgil Stokes <vs@it.uu.se> - 2016-02-28 12:26 +0100
        Re: Everything good about Python except GUI IDE? Sibylle Koczian <nulla.epistola@web.de> - 2016-02-28 11:46 +0100
        Re: Everything good about Python except GUI IDE? mm0fmf <none@invalid.com> - 2016-02-28 18:47 +0000
          Re: Everything good about Python except GUI IDE? Dietmar Schwertberger <maillist@schwertberger.de> - 2016-02-28 20:09 +0100
        Re: Everything good about Python except GUI IDE? Michael Torrie <torriem@gmail.com> - 2016-02-28 18:24 -0700
        Re: Everything good about Python except GUI IDE? Mike S <mscir@yahoo.com> - 2016-03-02 23:27 -0800
    Re: Everything good about Python except GUI IDE? Marco Kaulea <marco.kaulea@gmail.com> - 2016-02-27 18:57 +0100
    Re: Everything good about Python except GUI IDE? Anthony Papillion <anthony@cajuntechie.org> - 2016-02-27 13:45 -0600
    Re: Everything good about Python except GUI IDE? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-02-27 20:52 +0000
    Re: Everything good about Python except GUI IDE? MRAB <python@mrabarnett.plus.com> - 2016-02-27 21:35 +0000
    Re: Everything good about Python except GUI IDE? Mike <termim@gmail.com> - 2016-03-01 19:46 -0800

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#103669

Steven D'Aprano <steve@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#103670

On Mon, Feb 29, 2016 at 12:05 PM, Ben Finney <ben+python@benfinney.id.au> 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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

On Mon, Feb 29, 2016 at 12:39 PM, Rustom Mody <rustompmody@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

On Mon, Feb 29, 2016 at 12:55 PM, Rustom Mody <rustompmody@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

Rustom Mody <rustompmody@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

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

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)

[toc] | [prev] | [next] | [standalone]

#103653

On 28/02/2016 14:00, Chris Warrick wrote:
> On 28 February 2016 at 14:49, Rustom Mody <rustompmody@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#103650

On Sun, 28 Feb 2016 05:13:57 -0800 (PST), Rustom Mody
<rustompmody@gmail.com> declaimed the following:

>On Sunday, February 28, 2016 at 6:38:40 PM UTC+5:30, Gordon Levi wrote:
>> 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

	And VB6 hid the text representation in the form module


VERSION 5.00
Object = "{F9043C88-F6F2-101A-A3C9-08002B2F49FB}#1.2#0"; "COMDLG32.OCX"
Object = "{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0"; "MSCOMCTL.OCX"
Begin VB.Form frmMain 
   BorderStyle     =   1  'Fixed Single
   Caption         =   "Jeparody"
   ClientHeight    =   8010
   ClientLeft      =   -105
   ClientTop       =   450
   ClientWidth     =   11535
   BeginProperty Font 
      Name            =   "MS Sans Serif"
      Size            =   9.75
      Charset         =   0
      Weight          =   400
      Underline       =   0   'False
      Italic          =   0   'False
      Strikethrough   =   0   'False
   EndProperty
   LinkTopic       =   "Form1"
<SNIP>
  Begin VB.Menu mnuHelp 
      Caption         =   "&Help"
      Begin VB.Menu mnuHelpAbout 
         Caption         =   "&About "
      End
   End
End
Attribute VB_Name = "frmMain"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
Option Explicit
Dim Trivia(COLS - 1, ROWS - 1, 1) As String
Dim DDoubles(1) As Integer

Private Sub Command1_Click(Index As Integer)
    Dim aRow As Integer, aCol As Integer
    
	The VB IDE used everything above the "Option Explicit" to create the
form, and displayed the bottom as the handler code for editing.

	With enough study, one could hand edit the form definition -- just need
to use some non-Visual Studio editor <G> Differencing should be possible
too, though if one moved a GUI element, matching up where it now appears in
the text may not be easy.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#103852

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

>On Sun, 28 Feb 2016 05:13:57 -0800 (PST), Rustom Mody
><rustompmody@gmail.com> declaimed the following:
>
>>On Sunday, February 28, 2016 at 6:38:40 PM UTC+5:30, Gordon Levi wrote:
>>> 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
>
>	And VB6 hid the text representation in the form module
[snip]
>	With enough study, one could hand edit the form definition -- just need
>to use some non-Visual Studio editor <G> Differencing should be possible
>too, though if one moved a GUI element, matching up where it now appears in
>the text may not be easy.

We are talking about using source code control to cooperate on a
project, not sabotage it. When somebody alters the form they must use
the same GUI form editor as everybody else. If they did not, the form
would become impossible to maintain particularly using the form
designers that embed the form design in the language source code.

[toc] | [prev] | [next] | [standalone]

#103629

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

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

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

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

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

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


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

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

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

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

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



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

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


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

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

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

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

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

on setBtnStyle:
  for btnNum in 1 to the number of buttons:
    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 setBtnStyle


then call that handler on some event:

on openCard:
  setBtnStyle
end openCard

(In Hypercard, the UI model is of a Rolodex or set of cards, once card
displayed at a time in a window. Each card can contain widgets and
graphics. Displaying a card sends the openCard message to that card, which
runs whatever code is in the openCard handler. (Don't be put off by the
language of sending messages, that's identical to a method call.)

If this sounds kinda Javascript-y, it's because HC is one of the admitted
influences of early Javascript. If the business of sending messages sounds
kinda like Smalltalk, that's because HC was influenced by it. Apple history
buffs will see the influence of Alan Kay and Xerox PARC all over this...

Hypercard was not limited to manipulating the state of existing widgets. It
could programmatically create new ones. (Apple's Hypercard has a horrible
API for that where you literally gave a command to select a tool, then drag
from one point to another to create the widget. But later competing
products added more sensible commands for this.) If you had a complex
layout, you could code that part of the layout, but the point is that you
weren't forced to code everything.


[...]
> This doesn't have to be a dichotomy.

I didn't say it did :-)



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103655

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

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

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

Why is this a rare feature in spreadsheets? It's pretty obvious that
you can do this in code - you simply call that function. In anything
drag-and-drop, it has to be an explicitly provided feature.

> (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? Non-text source code is
fine as long as only one person at a time is ever editing. Source
control will happily track them. But merging is virtually impossible;
taking one base case and two modified files and producing a unified
result is hard for either a human or a machine, when the files are
non-text blobs.

My suspicion is that such game devs would have strict rules about
simultaneous editing of files. While that quite probably works fairly
well, it's a limitation that most of us would not accept in any code
project. Imagine if the Python bug tracker required you to send, not a
patch file, but the entire source file that has the edit you want. How
would you manage those sorts of edits?

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

Right. Testing the widgets isn't your responsibility, although testing
a composite widget might (imagine building a drop-down combo box out
of the three parts - you should be able to test that in isolation).
But I was stretching a bit here. Feel free to drop this one.

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

That's if you review the entire app. I'm talking more about the
equivalent of sharing patches; "here, I changed this window, do you
accept my change or not?" is a hard question to ask if you can't see
exactly what changed. Closely related to the source control issue - if
you can make patches/diffs for one, you can do it for the other.

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

The analogy is of having a grossly-restricted form of code reuse as
your only form. Composition is one specific option, but that's not the
only thing you can do with code.

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

This is like running a sed script over your code. That's still not the
same thing as higher-order code.

> If this was something that needed to run each time the application ran, I
> would put the script in some other layer of the application, say, in the
> card layer, in a named handler:
>
> on setBtnStyle:
>   for btnNum in 1 to the number of buttons:
>     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 setBtnStyle
>
>
> then call that handler on some event:
>
> on openCard:
>   setBtnStyle
> end openCard

I suppose that's a reasonable simulation of higher-order code. If it's
stuff you're happy to do at run time (ie it won't hurt that you can't
see it in the editor), this will work. It's still not as good IMO
though.

>> This doesn't have to be a dichotomy.
>
> I didn't say it did :-)

Good :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#103677

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 as in text code. How would you merge those two
changes as text?


[...]
> My suspicion is that such game devs would have strict rules about
> simultaneous editing of files. While that quite probably works fairly
> well, it's a limitation that most of us would not accept in any code
> project. 

I think you mean, "in any code project apart from games".


> Imagine if the Python bug tracker required you to send, not a 
> patch file, but the entire source file that has the edit you want. How
> would you manage those sorts of edits?

Patch files are for the convenience of the code reviewer, not the person
making the change. It's *less* work for me to email or upload the
entire .py file than to create a patch and email that, but it's harder for
the guy who wants to see what changes I've made before applying them.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103680

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

[toc] | [prev] | [next] | [standalone]

#103626

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 reproducible (footnote 
numbering, styling, literature, etc.).

She needed to invest some time to learn LaTeX and to tweak the initial 
template to fit her needs. Though, in the end, she's much happier and 
get reproducible results. She still uses a GUI for writing LaTeX. It 
helps her avoiding mistakes.

So, I don't think it's GUI vs text but rather how can they complement 
each other.

[toc] | [prev] | [next] | [standalone]

#103627

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

[toc] | [prev] | [next] | [standalone]

#103630

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

[toc] | [prev] | [next] | [standalone]

#103633

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.python

csiph-web