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

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

Python declarative

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

Contents

  Python declarative Sergio Tortosa Benedito <sertorbe@gmail.com> - 2014-01-15 18:02 +0100
    Re: Python declarative Francesco Bochicchio <bieffe62@gmail.com> - 2014-01-17 06:22 -0800
      Re: Python declarative Francesco Bochicchio <bieffe62@gmail.com> - 2014-01-19 23:25 -0800
    Re: Python declarative sertorbe@gmail.com - 2014-01-17 06:47 -0800
      Re: Python declarative Tim Roberts <timr@probo.com> - 2014-01-18 13:13 -0800
    Re: Python declarative sertorbe@gmail.com - 2014-01-19 02:27 -0800
    Re: Python declarative sertorbe@gmail.com - 2014-01-22 12:38 -0800
    Re: Python declarative Asaf Las <roegltd@gmail.com> - 2014-01-22 13:16 -0800
      Re: Python declarative Chris Angelico <rosuav@gmail.com> - 2014-01-23 13:29 +1100
      Re: Python declarative Terry Reedy <tjreedy@udel.edu> - 2014-01-22 23:08 -0500
      Re: Python declarative "Frank Millman" <frank@chagford.com> - 2014-01-24 11:21 +0200
        Re: Python declarative Rustom Mody <rustompmody@gmail.com> - 2014-01-24 01:53 -0800
          Re: Python declarative "Frank Millman" <frank@chagford.com> - 2014-01-24 15:06 +0200
      Re: Python declarative Chris Angelico <rosuav@gmail.com> - 2014-01-24 22:18 +1100
      Re: Python declarative "Frank Millman" <frank@chagford.com> - 2014-01-24 14:49 +0200
      Re: Python declarative Burak Arslan <burak.arslan@arskom.com.tr> - 2014-01-24 15:40 +0200
      Re: Python declarative Chris Angelico <rosuav@gmail.com> - 2014-01-25 00:55 +1100
      Re: Python declarative Matěj Cepl <mcepl@redhat.com> - 2014-01-24 17:28 +0100
      Re: Python declarative Chris Angelico <rosuav@gmail.com> - 2014-01-25 03:33 +1100
        Re: Python declarative sertorbe@gmail.com - 2014-01-24 10:51 -0800
      Re: Python declarative "Frank Millman" <frank@chagford.com> - 2014-01-25 09:18 +0200
        Re: Python declarative Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-26 02:33 +0000
          Re: Python declarative Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-26 02:45 +0000
            Re: Python declarative Asaf Las <roegltd@gmail.com> - 2014-02-02 18:17 -0800
          Re: Python declarative Chris Angelico <rosuav@gmail.com> - 2014-01-26 14:38 +1100
          Re: Python declarative Chris Angelico <rosuav@gmail.com> - 2014-01-26 15:06 +1100
            Re: Python declarative Rustom Mody <rustompmody@gmail.com> - 2014-01-25 20:47 -0800
              Re: Python declarative Chris Angelico <rosuav@gmail.com> - 2014-01-26 16:23 +1100
                Re: Python declarative Rustom Mody <rustompmody@gmail.com> - 2014-01-26 00:05 -0800
                  Re: Python declarative "Frank Millman" <frank@chagford.com> - 2014-01-26 11:12 +0200
                    Re: Python declarative Rustom Mody <rustompmody@gmail.com> - 2014-01-26 06:36 -0800
            Re: Python declarative Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-26 12:05 +0000
          Re: Python declarative "Frank Millman" <frank@chagford.com> - 2014-01-26 08:03 +0200
            Re: Python declarative Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-26 12:21 +0000
      Re: Python declarative Chris Angelico <rosuav@gmail.com> - 2014-01-25 18:33 +1100
      Re: Python declarative matej@ceplovi.cz (Matěj Cepl) - 2014-01-25 12:23 +0100
    Re: Python declarative Asaf Las <roegltd@gmail.com> - 2014-01-24 04:04 -0800

Page 2 of 2 — ← Prev page 1 [2]

#64728

"Chris Angelico" <rosuav@gmail.com> wrote in message 
news:CAPTjJmpi-kvJAVs2gK+nH5n6q3REkJaKR=CZeRfzUgDk8_VLGw@mail.gmail.com...
> On Fri, Jan 24, 2014 at 11:49 PM, Frank Millman <frank@chagford.com> 
> wrote:
>>
>

[...]

I have realised that we unlikely to come to an agreement on this in the near 
future, as our philosophies are completely different.

You have stated that your objective is to express as much as possible in 
Python code.

I have stated that my objective is to express as little as possible in 
Python code.

We would have to resolve that difference of opinion first, before discussing 
our respective approaches in detail, and that is way beyond the scope of 
this thread.

As a brief example of my approach, here is how I would write your simple 
'About' box.

Here is your version -

mainwindow = GTK2.Window(0)->add(GTK2.Vbox(0,0)
    ->add(GTK2.Label("About Gypsum: big long multi-line string"))
    ->add(GTK2.HbuttonBox()
        ->add(GTK2.Button("Close"))
        ->add(GTK2.Button("Foobar"))
    )
);

Here is my version -

<form name="ChrisAbout_form">
  <data_objects/>
  <input_params/>
  <output_params/>
  <rules/>
  <frame>
    <body>
      <block/>  <!-- an html div -->
      <panel/>  <!-- an html table -->
      <row/>
      <col/>
      <text value="This is line one of a multi-line string"/>
      <row/>
      <col/>
      <text value="This is line two of a multi-line string"/>
      <row/>
      <col/>
      <text value="This is line three of a multi-line string"/>
    </body>
    <button_row>  <!-- an html div -->
      <button btn_id="btn_close" btn_label="Close" len="60"
          btn_enabled="true" btn_validate="false" btn_default="true">
        <end_form state="completed"/>
      </button>
      <button btn_id="btn_foo" btn_label="Foobar" len="60"
          btn_enabled="true" btn_validate="false" btn_default="false">
        <pyfunc name="path1.path2.foobar"/>
      </button>
    </button_row>
    <frame_methods>
      <method name="on_req_close">  <!-- user clicked [X] or pressed 
Shift_F4 -->
        <end_form state="completed"/>
      </method>
      <method name="on_req_cancel">  <!-- user pressed Escape -->
        <end_form state="completed"/>
      </method>
    </frame_methods>
  </frame>
</form>

Currently I do not have a widget for a multi-line label, so I just show 
three separate lines. If I ever needed one, it would not take long to 
create.

I took two screenshots, but I don't know the best way to upload and share 
them. I found a site called tinypic, which works, but the screen is 
cluttered with a lot of other stuff. Still, it shows what I want.

First, here is the screen as rendered in Internet Explorer (it works in 
other browsers as well - even on my smart phone, though I have not done any 
optimising for mobile devices yet) -

http://tinypic.com/r/ip15xx/5



Second, here is the screen designer, showing a portion of the screen 
definition - one of the buttons. As you can see, the designer does not have 
to worry about XML at all -


http://tinypic.com/r/1j7sdh/5



I am not claiming that I am 'right', or that this is a perfect solution. It 
is just 'where I am' right now, after quite a long period of evolution, and 
it is achieving a large portion of what I am aiming for, so I will press on 
with my current approach for now.



Hopefully it will not take *too* long before I am in a position to release 
something, and then I will be very interested in any feedback.



Thanks for the interesting discussion.



Frank

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

#64757

On Sat, 25 Jan 2014 09:18:44 +0200, Frank Millman wrote:

> I have realised that we unlikely to come to an agreement on this in the
> near future, as our philosophies are completely different.
> 
> You [Chris Angelo] have stated that your objective is to express as
> much as possible in Python code.
> 
> I have stated that my objective is to express as little as possible in
> Python code.

Interesting perspective.


> We would have to resolve that difference of opinion first, before
> discussing our respective approaches in detail, and that is way beyond
> the scope of this thread.
> 
> As a brief example of my approach, here is how I would write your simple
> 'About' box.
> 
> Here is your version -
> 
> mainwindow = GTK2.Window(0)->add(GTK2.Vbox(0,0)
>     ->add(GTK2.Label("About Gypsum: big long multi-line string"))
>     ->add(GTK2.HbuttonBox()
>         ->add(GTK2.Button("Close"))
>         ->add(GTK2.Button("Foobar"))
>     )
> );

That's not Python code, but it's reasonably concise and readable. (By the 
way, what language is it?) The meaning is fairly obvious, and it's all 
pretty simple. I'd like to see a more human readable GUI designer 
language:

# hypothetical code in a DSL for creating GUI elements
create new window mainwindow
with mainwindow
    add vbox at 0,0
    add label "About Gypsum: big long multi-line string"
    add hbuttonbox
    add button "Close"
    add button "Foobar"

but what you've got there is okay. Seven lines of readable code.


> Here is my version -
> 
> <form name="ChrisAbout_form">
>   <data_objects/>
>   <input_params/>
>   <output_params/>
>   <rules/>
>   <frame>
>     <body>
>       <block/>  <!-- an html div -->
>       <panel/>  <!-- an html table -->
>       <row/>
>       <col/>
>       <text value="This is line one of a multi-line string"/> <row/>
>       <col/>
>       <text value="This is line two of a multi-line string"/> <row/>
>       <col/>
>       <text value="This is line three of a multi-line string"/>
>     </body>
>     <button_row>  <!-- an html div -->
>       <button btn_id="btn_close" btn_label="Close" len="60"
>           btn_enabled="true" btn_validate="false" btn_default="true">
>         <end_form state="completed"/>
>       </button>
>       <button btn_id="btn_foo" btn_label="Foobar" len="60"
>           btn_enabled="true" btn_validate="false" btn_default="false">
>         <pyfunc name="path1.path2.foobar"/>
>       </button>
>     </button_row>
>     <frame_methods>
>       <method name="on_req_close">  <!-- user clicked [X] or pressed
> Shift_F4 -->
>         <end_form state="completed"/>
>       </method>
>       <method name="on_req_cancel">  <!-- user pressed Escape -->
>         <end_form state="completed"/>
>       </method>
>     </frame_methods>
>   </frame>
> </form>

Thirty. Seven. Lines. Of. XML.

You've got to be kidding me. How can you *possibly* prefer that? 

First rule of XML: it is not human-writable. It's barely human-readable. 
It's a *document* interchange language which happens to use mostly human-
readable elements, which is not the same thing at all. It's designed to 
be machine written. Using XML for *data* is abusive to both the XML 
design goals and to the poor schmuck who has to read your config file. 
Using XML *as a programming language* is not just abuse, it's getting 
into grievous bodily harm territory.

Here's a simple programming expression, familiar to most people, common 
to hundreds of programming languages:

3+4*5

Here it is written as XML:

<add><int>3</int><mult><int>4</int><int>5</int></mult></add>


Source:
http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html

More here:

http://www.codinghorror.com/blog/2008/05/xml-the-angle-bracket-tax.html
http://myarch.com/why-xml-is-bad-for-humans/


If you expect a human being to routinely *read*, let alone *write*, XML 
in preference to some real programming language, that is a horrible, 
horrible thing. Using XML as an internal, machine-generated, format not 
intended for humans is not too bad. Anything else is abusive.



-- 
Steven

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

#64758

On 26/01/2014 02:33, Steven D'Aprano wrote:
> Here's a simple programming expression, familiar to most people, common
> to hundreds of programming languages:
>
> 3+4*5
>
> Here it is written as XML:
>
> <add><int>3</int><mult><int>4</int><int>5</int></mult></add>
>
> Source:
> http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html
>
> More here:
>
> http://www.codinghorror.com/blog/2008/05/xml-the-angle-bracket-tax.html
> http://myarch.com/why-xml-is-bad-for-humans/
>
> If you expect a human being to routinely *read*, let alone *write*, XML
> in preference to some real programming language, that is a horrible,
> horrible thing. Using XML as an internal, machine-generated, format not
> intended for humans is not too bad. Anything else is abusive.
>

If I worked as a consultant I'd much prefer the XML version as I'd be 
able to charge much more on the grounds that I'd done much more, hoping 
that the people paying didn't bother with design reviews or the like :)

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

#65313

On Sunday, January 26, 2014 4:45:59 AM UTC+2, Mark Lawrence wrote:
> On 26/01/2014 02:33, Steven D'Aprano wrote:
> 
> If I worked as a consultant I'd much prefer the XML version as I'd be 
> able to charge much more on the grounds that I'd done much more, hoping 
> that the people paying didn't bother with design reviews or the like :)
>
> My fellow Pythonistas, ask not what our language can do for you, ask 
> what you can do for our language.
> Mark Lawrence

Google's android uses XML for GUI widget definitions.
/Asaf

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

#64760

On Sun, Jan 26, 2014 at 1:33 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> Here is your version -
>>
>> mainwindow = GTK2.Window(0)->add(GTK2.Vbox(0,0)
>>     ->add(GTK2.Label("About Gypsum: big long multi-line string"))
>>     ->add(GTK2.HbuttonBox()
>>         ->add(GTK2.Button("Close"))
>>         ->add(GTK2.Button("Foobar"))
>>     )
>> );
>
> That's not Python code, but it's reasonably concise and readable. (By the
> way, what language is it?) The meaning is fairly obvious, and it's all
> pretty simple.

It's Pike, and the above example is pure Pike without any of my own
helpers. If you fire up Pike's interactive mode and type two commands
"GTK2.setup_gtk();" and "start backend" first, you can paste that in
and it'll create you a window. (It won't DO anything, but it'll sit
there looking like a window.) It tends to get a little verbose after a
while (hence the need for helper functions to combat the complexity),
but the advantage of this system is that it took me absolutely zero
code. I didn't have to write any framework.

> I'd like to see a more human readable GUI designer
> language:
>
> # hypothetical code in a DSL for creating GUI elements
> create new window mainwindow
> with mainwindow
>     add vbox at 0,0
>     add label "About Gypsum: big long multi-line string"
>     add hbuttonbox
>     add button "Close"
>     add button "Foobar"
>
> but what you've got there is okay. Seven lines of readable code.

Sure. That would make reasonable sense, as a DSL. And, in fact, if I
were making a Python GUI, I would want to add something that would let
me do it that way - at least compared to PyGTK, which insists on every
box getting a temporary name, since the add() methods don't chain. But
that's a cost, that has to be written. I'm happy with the no-code
version to start with. Now, with something as complicated as the
character sheet, well, that's different. I think if I did all the
charsheet code as pure no-helpers Pike, it would be a dozen pages of
code and indented about fifty tabs. At that point, it's worth putting
some effort into taming the beast :) Here's an actual example from the
charsheet:

GTK2.Hbox(0,10)->add(GTK2Table(({
    ({"Name",ef("name",12),0,0,"Char level",num("level",8)}),
    ({"Race",ef("race",8),"HD",ef("race_hd"),"Experience",num("xp",8)}),
    ({"Class",ef("class1",12),"Level",num("level1"),"To next
lvl",calc("`+(@enumerate(level,1000,1000))-xp")}),
    ({"Class",ef("class2",12),"Level",num("level2"),"Size",select("size",sizes)}),
    ({"Class",ef("class3",12),"Level",num("level3"),
        "Grapple",calc(grapple_formula,"grapple","string")
    }),
    ({"Class",ef("class4",12),"Level",num("level4")}),
}))->set_col_spacings(4))
->add(GTK2.Frame("Wealth")->add(GTK2Table(({
    ({"Platinum",num("wealth_plat",7)}),
    ({"Gold",num("wealth_gold",7)}),
    ({"Silver",num("wealth_silver",7)}),
    ({"Copper",num("wealth_copper",7)}),
    ({"Total gp",calc("(wealth_plat*1000+wealth_gold*100+wealth_silver*10+wealth_copper)/100")}),
}))))


It's a mix of basic Pike and GTK functions (GTK2.Frame is one of the
standard widgets) and helpers (num, ef, and calc) that return widgets,
maybe with child widgets. GTK2Table takes an array and plops
everything into it at appropriate locations. I use that function
*everywhere* in the charsheet - mainly because I was porting from a
spreadsheet, but D&D character sheets are inherently tabular.

(Note that I've reformatted this a bit from the original, and it might
be disrupted a bit by the email/newsgroup format. In the original,
this is all a few tabs in, but as long as your editor isn't wrapping
the lines, it's pretty readable.)

At what point is it a DSL rather than just "Pike code with helper
functions"? This is particularly true with Python code; it wouldn't be
hard to make a DSL that's derived from Python.

(By the way, your translation "add a vbox at 0,0" isn't accurate; the
0,0 are parameters to the Vbox itself, being the homogenous flag (if
it's nonzero, it forces its children to the same height and/or width,
but 0 means each child gets what it asks for) and the padding (0 puts
children hard up against one another, nonzero puts that much room
between them). A window has only a single child, which occupies its
entire space; that's why it's conventional to add a layout manager as
the one child, and then add multiple children to that. Means the
window needn't care about the minutiae of child positioning. But if
you call that "add a vbox 0,0", that'd work fine; and if you're making
a DSL, I'd make 0,0 the defaults and say "add a vbox padding 10" if I
want to override.)

The only problem with your DSL as I see it is that it doesn't mark the
beginning and end of child widget layouts. This needs to be a tree.
But Python already has a notation for that: indent! So if the two
buttons are indented, they'll be inside the hbuttonbox (which is a
type of horizontal box), which is within the vertical box (again,
indent everything that's inside it), which is within the main window.

Of course, then you need to work out how to attach code to buttons,
but let's leave that aside... mainly because it's a nightmare to do in
XML, but pretty easy (if a little tedious in large quantities) in
code. :)

ChrisA

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

#64761

On Sun, Jan 26, 2014 at 1:45 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> If I worked as a consultant I'd much prefer the XML version as I'd be able
> to charge much more on the grounds that I'd done much more, hoping that the
> people paying didn't bother with design reviews or the like :)

And that's very true. If someone wants something infinitely
customizeable, the best solution might be an empty file with a shebang
at the top - but that's hardly something you can charge oodles for.
This is where soft-coding comes from.

http://thedailywtf.com/Articles/Soft_Coding.aspx

The business logic examples given there are best served by hard code.
Suppose you need to calculate this-value plus that-value times
other-value; is there any difference between writing that in Python
(ugh, that's hard code!) and putting the formula in a config file,
where it'll get parsed and evaluated (oh, that's a config file, that's
fine)? As you'll see in my other post, there's a formula evaluator
routine there; it takes a string of code and compiles it:

(wealth_plat*1000+wealth_gold*100+wealth_silver*10+wealth_copper)/100

It's straight code, and it's embedded. If ever the rules change, I can
edit the code. For instance, here's the D&D Fourth Edition version of
that:

(wealth_plat*10000+wealth_gold*100+wealth_silver*10+wealth_copper)/100

Should the value of a platinum coin be moved out into a config file?
Maybe. MAYBE. Should the value of a silver piece be? Definitely not!
There's no use-case for silver pieces being worth anything other than
ten copper. If and when there is one, the code can simply be edited.
There is no value in soft-coding this formula.

Code isn't something to be afraid of. It's just text files like any
other. After all, Python code is a config file for /usr/bin/python, so
if you want to change what Python does, just edit its config file!

ChrisA

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

#64762

On Sunday, January 26, 2014 9:36:15 AM UTC+5:30, Chris Angelico wrote:
> Code isn't something to be afraid of. It's just text files like any
> other. After all, Python code is a config file for /usr/bin/python, so
> if you want to change what Python does, just edit its config file!

Windows stores configuration in the registry -- by fiat
Linux (posix) stores configuration in /etc + ~/.files -- by convention

Which do you think is preferable?

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

#64763

On Sun, Jan 26, 2014 at 3:47 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Sunday, January 26, 2014 9:36:15 AM UTC+5:30, Chris Angelico wrote:
>> Code isn't something to be afraid of. It's just text files like any
>> other. After all, Python code is a config file for /usr/bin/python, so
>> if you want to change what Python does, just edit its config file!
>
> Windows stores configuration in the registry -- by fiat
> Linux (posix) stores configuration in /etc + ~/.files -- by convention
>
> Which do you think is preferable?

Not exclusively, in either case. Many many things are config files of
various sorts. The terms of the GPL specifically state that a GPL'd
language does not enforce that code written in it is GPL'd, because
it's just (to the GPL code) data files.

Plenty of Windows programs store config files outside the registry.

ChrisA

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

#64765

On Sunday, January 26, 2014 10:53:32 AM UTC+5:30, Chris Angelico wrote:
> On Sun, Jan 26, 2014 at 3:47 PM, Rustom Mody wrote:
> > On Sunday, January 26, 2014 9:36:15 AM UTC+5:30, Chris Angelico wrote:
> >> Code isn't something to be afraid of. It's just text files like any
> >> other. After all, Python code is a config file for /usr/bin/python, so
> >> if you want to change what Python does, just edit its config file!
> > Windows stores configuration in the registry -- by fiat
> > Linux (posix) stores configuration in /etc + ~/.files -- by convention
> > Which do you think is preferable?

> Not exclusively, in either case. Many many things are config files of
> various sorts. The terms of the GPL specifically state that a GPL'd
> language does not enforce that code written in it is GPL'd, because
> it's just (to the GPL code) data files.

Ok so you are being careful and hedging your bets!!
[And Ive no idea what the gpl has to do with this]

If you see the 'Principle of Least Power here:
http://www.w3.org/DesignIssues/Principles.html
there is a spectrum of power from narrow data format to universal data
format to Turing complete programming language. And a strong case is
made for minimizing the 'power' in any application.

By decreeing things about the registry, windows solves many problems
that create unnecessary headaches for developers, packagers, uses with
the laissez-faire approach of 'put whatever you like in /etc.'  This
follows from the principle: "Anything goes" applied to /etc means messes
go in. Its harder to push messes into a dictat-ed registry

Steven's link
http://www.codinghorror.com/blog/2008/05/xml-the-angle-bracket-tax.html
linked to
http://nothing-more.blogspot.in/2004/10/where-xml-goes-astray.html
explains what the real problem is:

Xml, originally a document format, is nowadays used as a data-format.
This conduces to humongous messing, first for the xml-library writers, and
thence to the users of those libraries because library messes inevitably 
leak past abstraction barriers to cause user-programmer headaches.

tl;dr
Frank's principle: "Express little as possible in <programming language>"
is correct.
"And therefore XML is the solution"
is bad logic
[Unless <programming language> == "java" !]

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

#64767

"Rustom Mody" <rustompmody@gmail.com> wrote in message 
news:3683cd10-592b-4a3d-ba77-b963a1aa2282@googlegroups.com...
>
> Xml, originally a document format, is nowadays used as a data-format.
> This conduces to humongous messing, first for the xml-library writers, and
> thence to the users of those libraries because library messes inevitably
> leak past abstraction barriers to cause user-programmer headaches.
>
> tl;dr
> Frank's principle: "Express little as possible in <programming language>"
> is correct.
> "And therefore XML is the solution"
> is bad logic
> [Unless <programming language> == "java" !]

If that is the case, what is 'good logic'? JSON or YAML?

It does not make much difference which format I use. However, I will say 
that I found it a useful discipline to create an xml schema to describe my 
form definition, for two reasons.

Firstly, I was hand-crafting my form definitions initially, and as I added 
features it became unwieldy. Forcing myself to create the schema highlighted 
a lot of anomalies and I ended up with a much cleaner structure as a result.

Secondly, it has picked up a lot of errors in the resulting documents which 
would otherwise have generated hard-to-find runtime exceptions.

Frank

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

#64775

On Sunday, January 26, 2014 2:42:57 PM UTC+5:30, Frank Millman wrote:
> "Rustom Mody"  wrote:
> > Xml, originally a document format, is nowadays used as a data-format.
> > This conduces to humongous messing, first for the xml-library writers, and
> > thence to the users of those libraries because library messes inevitably
> > leak past abstraction barriers to cause user-programmer headaches.
> > tl;dr
> > Frank's principle: "Express little as possible in <programming language>"
> > is correct.
> > "And therefore XML is the solution"
> > is bad logic
> > [Unless <programming language> == "java" !]

> If that is the case, what is 'good logic'? JSON or YAML?

> It does not make much difference which format I use. However, I will say 
> that I found it a useful discipline to create an xml schema to describe my 
> form definition, for two reasons.

> Firstly, I was hand-crafting my form definitions initially, and as I added 
> features it became unwieldy. Forcing myself to create the schema highlighted 
> a lot of anomalies and I ended up with a much cleaner structure as a result.

> Secondly, it has picked up a lot of errors in the resulting documents which 
> would otherwise have generated hard-to-find runtime exceptions.

There are json/yaml 'schema'* validators if you want eg
https://github.com/alecthomas/voluptuous
http://rx.codesimply.com/

* if you want to call them that!

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

#64771

On Sun, 26 Jan 2014 15:06:15 +1100, Chris Angelico wrote:

> Code isn't something to be afraid of. 

Not according to the Laundry series by Charles Stross. The protagonist of 
the series was "recruited" to the Laundry after the computer program he 
was working on almost summoned Nyarlathotep the Crawling Chaos Elder God 
to Wolverhampton.


-- 
Steven

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

#64764

"Steven D'Aprano" <steve+comp.lang.python@pearwood.info> wrote in message 
news:52e473fc$0$29999$c3e8da3$5496439d@news.astraweb.com...
> On Sat, 25 Jan 2014 09:18:44 +0200, Frank Millman wrote:
>
>> I have realised that we unlikely to come to an agreement on this in the
>> near future, as our philosophies are completely different.
>>
>> You [Chris Angelo] have stated that your objective is to express as
>> much as possible in Python code.
>>
>> I have stated that my objective is to express as little as possible in
>> Python code.
>
> Interesting perspective.
>

[...]

I did not really want to continue this, but I have to respond to that.

There is a sub-context within which I made my statement.

Here is a quote from one of my earlier posts -

> Each form definition is stored as gzip'd XML in a database, and linked to 
> the
> menu system. There is just one python program that responds to the 
> selection
> of a menu option, retrieves the form from the database, unpacks it and 
> runs it.

I do not expect anyone to read or edit the XML - it is just a storage 
format. I am sure it could be done in JSON or YAML as well.

One objective is to make it easy for non-programmers to modify forms and 
create new ones. I showed a screenshot earlier that illustrated a 'button' 
definition.

Frank

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

#64772

On Sun, 26 Jan 2014 08:03:18 +0200, Frank Millman wrote:

> I do not expect anyone to read or edit the XML - it is just a storage
> format. I am sure it could be done in JSON or YAML as well.

But that's not what you originally said. You stated:

"here is how I would write your simple 'About' box"

and compared your XML to actual code written by Chris.

As I said in my previous post, if the XML is intended as a purely 
internal document, written by and read by your application, it's not so 
bad. (But then XML is intended for document *exchange*, i.e. from one 
application to another. If your XML is just used *internally*, with no 
interchange needed, why not use a more efficient internal format?

XML's strength is that it is a well-known standard that allows 
application A to interchange documents with application B. But it's 
weaknesses include, it is neither efficient like a custom-designed binary 
format, not human-editable.

It seems to me that if I were in your position, I would have the GUI 
designer generate source code in some language directly, rather than XML. 
Ah, wait! An idea strikes... if your GUI designer generates XML, you 
could then have a plug-in system to convert the XML to source code in 
whatever languages the plug-in supports. So that's a possible good use 
for XML as an intermediate language.


> One objective is to make it easy for non-programmers to modify forms and
> create new ones. I showed a screenshot earlier that illustrated a
> 'button' definition.

The idea of drag-and-drop GUI designers is hardly new. I was using one 
back in 1986 or '88, Apple's Hypercard. Now that was a user-friendly 
programming language/environment/toolkit.


-- 
Steven

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

#64731

On Sat, Jan 25, 2014 at 6:18 PM, Frank Millman <frank@chagford.com> wrote:
> I have realised that we unlikely to come to an agreement on this in the near
> future, as our philosophies are completely different.
>
> You have stated that your objective is to express as much as possible in
> Python code.
>
> I have stated that my objective is to express as little as possible in
> Python code.

Ah but the question is *why* you want to minimize code. I write
everything in code because it minimizes unnecessary coding - yes,
that's right, I maximize code to minimize code :) - because all that
code that isn't written also isn't debugged, isn't maintained, and
isn't placing unnecessary restrictions on anything. What's the
advantage of doing it in XML?

Your GUI builder is all very well, but it could as easily write Python
code as XML, so it doesn't give a strong incentive for XML. And
personally, I think it's more likely to be a waste of effort, too, but
that's more because a good GUI builder takes a *ton* of effort to
build. That's time that has to be spent up-front, before you have
experience with the system, before you _can get_ experience with the
system - and, see above, it's code that has to be debugged and
maintained.

Every framework has to justify itself. Just "it lets people not write
code" isn't enough unless not-writing-code can justify the costs.

ChrisA

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

#64739

[This message has also been posted to gmane.comp.python.general.]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2014-01-25, 07:18 GMT, Frank Millman wrote:
> I have stated that my objective is to express as little as 
> possible in Python code.

Yes, and I believe that it is very wrong. But anyway, if you are 
so passionate about GUI-via-XML, what’s wrong with Glade 
(http://www.pygtk.org/pygtk2reference/class-gladexml.html)? You 
have editors for that XML etc.

Matěj

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iD8DBQFS457O4J/vJdlkhKwRAlA7AJ9nTl4v+FoiNZb3NLaSsIZMd2HO5wCeNYwe
EVLDNqlw3YaQtloF1RGWP8Y=
=AloI
-----END PGP SIGNATURE-----

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

#64676

On Wednesday, January 15, 2014 7:02:08 PM UTC+2, Sergio Tortosa Benedito wrote:
> Hi I'm developing a sort of language extension for writing GUI programs
> called guilang, right now it's written in Lua but I'm considreing Python
> instead (because it's more tailored to alone applications). My question
> it's if I can achieve this declarative-thing in python. Here's an
> example:
> Window "myWindow" {
> 	title="Hello world";
> 	Button "myButton" {
> 		label="I'm a button";
> 		onClick=exit
> 	}
> }
> print(myWindow.myButton.label)
> Of course it doesn't need to be 100% equal. Thanks in advance
> Sergio

you can also encode widget event handler 
function names into same text file and module names where 
functions are written so they will be called by string name.
The only thing will be left - creation of those module(s).py
and writing functions there and of course the subject of your 
project interpreter/mapper/creator of encoded text to graphical 
primitives. 
For convenience text encoding can retain properties of 
widget library you will choose. or you can/should
also create derived widgets with some predefined look and feel 
and properties to make encoding simpler and typing faster.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web