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

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

Brython - Python in the browser

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

Contents

  Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-19 10:19 -0800
    Re: Brython - Python in the browser jkn <jkn_gg@nicorp.f9.co.uk> - 2012-12-19 14:59 -0800
    Re: Brython - Python in the browser Terry Reedy <tjreedy@udel.edu> - 2012-12-19 19:07 -0500
      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-20 01:37 -0800
        Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-20 20:56 +1100
        Re: Brython - Python in the browser Terry Reedy <tjreedy@udel.edu> - 2012-12-20 18:59 -0500
          Re: Brython - Python in the browser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-21 02:05 +0000
            Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-21 16:07 +1100
          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 08:16 -0800
            Re: Brython - Python in the browser Stefan Behnel <stefan_ml@behnel.de> - 2012-12-21 17:52 +0100
            Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-21 11:31 -0700
              Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 12:59 -0800
                Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-21 14:17 -0700
              Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 12:59 -0800
          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 08:16 -0800
        Re: Brython - Python in the browser Rouslan Korneychuk <rouslank@msn.com> - 2012-12-21 03:31 -0500
          Re: Brython - Python in the browser Terry Reedy <tjreedy@udel.edu> - 2012-12-21 04:44 -0500
      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-20 01:37 -0800
    Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-19 17:54 -0700
      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-20 01:42 -0800
        Re: Brython - Python in the browser Stefan Behnel <stefan_ml@behnel.de> - 2012-12-21 12:25 +0100
          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 04:38 -0800
            Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-21 23:57 +1100
              Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 07:36 -0800
                Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 02:48 +1100
                  Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 08:36 -0800
                    Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 09:52 +1100
                    Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-21 16:45 -0700
                    Re: Brython - Python in the browser Amirouche Boubekki <amirouche.boubekki@gmail.com> - 2012-12-22 00:50 +0100
                    Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-21 16:51 -0700
                      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 23:59 -0800
                      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 23:59 -0800
                    Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-21 16:57 -0700
                    Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 11:08 +1100
                      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 23:57 -0800
                        Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 19:31 +1100
                          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-22 00:54 -0800
                            Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 20:08 +1100
                              Re: Brython - Python in the browser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-22 11:05 +0000
                                Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 23:11 +1100
                                  Re: Brython - Python in the browser Dan Sommers <dan@tombstonezero.net> - 2012-12-22 20:31 +0000
                                    Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-22 13:53 -0700
                                    Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-23 08:49 +1100
                          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-22 00:54 -0800
                      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 23:57 -0800
                    Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 11:09 +1100
                  Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 08:36 -0800
              Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 07:36 -0800
            Re: Brython - Python in the browser Duncan Booth <duncan.booth@invalid.invalid> - 2012-12-21 13:14 +0000
              Re: Brython - Python in the browser Stefan Behnel <stefan_ml@behnel.de> - 2012-12-21 14:34 +0100
          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 04:38 -0800
          Re: Brython - Python in the browser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-22 02:31 +0000
      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-20 01:42 -0800
    Re: Brython - Python in the browser Terry Reedy <tjreedy@udel.edu> - 2012-12-19 21:46 -0500
    Re: Brython - Python in the browser Jamie Paul Griffin <jamie@kode5.net> - 2012-12-20 11:32 +0000
    Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-22 01:01 -0800

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

#35282

Pierre Quentel, 20.12.2012 10:42:
> Le jeudi 20 décembre 2012 01:54:44 UTC+1, Ian a écrit :
>> On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy wrote:
>>>> To create an element, for instance an HTML anchor :
>>>> doc <= A('Python',href="http://www.python.org")
>>>
>>> To me, that is a awful choice and I urge you to change it.

+1

>> +1.  The DOM already has a well-established API. [...]
>>
>> link = document.createElement('a')
>> link.setAttribute("href", "http://www.python.org/")
>> link.appendChild(document.createTextNode('Python'))
>> document.body.appendChild(link)
> 
> We don't have the same point of view. Mine is to offer an alternative to Javascript, with the simplicity and elegance of the Python syntax, for a programer who wants to develop a web application and doesn't know Javascript. Ultimately this means that the whole DOM API would be described without any mention of Javascript, only with the Python API

If that's your intention, then instead of coming up with something totally
new, unpythonic and ugly, why not take the normal Python route and
implement a subset of the ElementTree API?

Stefan

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

#35284

> If that's your intention, then instead of coming up with something totally
> new, unpythonic and ugly, why not take the normal Python route and
> implement a subset of the ElementTree API?
> 
> Stefan
Because the tree implementation in ElementTree or other tree modules in Python require a lot of typing and parenthesis

To produce the HTML code

<DIV>hello <B>world</B></DIV>

these modules require writing something like 

div = Tag('DIV')
div.appendChild(TextNode('hello '))
b = Tag('B')
b.appendChild(TextNode('world'))
div.appendChild(b)
doc.appendChild(div)

With the tree syntax proposed in Brython it would just be

doc <= DIV('hello '+B('world'))

If "pythonic" means concise and readable, which one is more pythonic ?

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

#35287

On Fri, Dec 21, 2012 at 11:38 PM, Pierre Quentel
<pierre.quentel@gmail.com> wrote:
> With the tree syntax proposed in Brython it would just be
>
> doc <= DIV('hello '+B('world'))
>
> If "pythonic" means concise and readable, which one is more pythonic ?

Pythonic also means:
If the implementation is hard to explain, it's a bad idea.

What, exactly, does the sum of a string and a bolded string produce?
Can you explain that easily and clearly? Don't forget that humans, as
well as machines, will expect to be able to parse what's inside the
parentheses without looking outside them.

The DOM structure is, undeniably, quite verbose. But you could go for
something with the same tree structure while a lot less wordy by
simply returning self from lots of methods, thus allowing method
chaining - something like this:

https://github.com/Rosuav/Gypsum/blob/master/window.pike#L247

Note how the tree structure is defined by the parentheses, with
->add(...) calls creating children. (That's Pike, not Python, as I
don't have a good Python example handy. The -> operator does more or
less what Python's . does.) Now, I can conceive of a kind of API - an
ideal API, the creature of my fancy, you know - which would be totally
unobjectionable. An API, for instance, which would abolish taxes and
make everything cheap, except gondolas... oh wait, wrong mailing list.

To produce the HTML code

<DIV>hello <B>world</B></DIV>

you might use:

doc.add(Tag('DIV').add('hello ').add(Tag('B').add('world')))

And you can easily wrap that to suit, since it's surrounded by parentheses:

doc.add(
  Tag('DIV')
    .add('hello ')
    .add(Tag('B').add('world'))
)

There's no magic with operators, just simple method chaining. It's a
bit more verbose than your proposed tree syntax, but not nearly as bad
as the JS version; and it's not magical.

Reject the idea if you will, but do at least please consider it :)

ChrisA

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

#35297

> Pythonic also means:
> If the implementation is hard to explain, it's a bad idea.
> What, exactly, does the sum of a string and a bolded string produce?  Can you explain that easily and clearly?

Yes : a+b returns the string a+str(b)

It is exactly what you get in CPython with 
>>> class B:
...   def __init__(self,value):
...     self.value = value
...   def __radd__(self,other):
...     return '%s<b>%s</b>' %(other,self.value)
...
>>> 'hello '+B('world')
'hello <b>world</b>'

> The DOM structure is, undeniably, quite verbose. But you could go for
> something with the same tree structure while a lot less wordy by
> simply returning self from lots of methods, thus allowing method
> chaining - something like this:
> 
> https://github.com/Rosuav/Gypsum/blob/master/window.pike#L247
> 
Hang me if I understand what this code is supposed to do ;-)
> 
> To produce the HTML code
> 
> <DIV>hello <B>world</B></DIV>
> 
> you might use:
> 
> doc.add(Tag('DIV').add('hello ').add(Tag('B').add('world')))
> 
No, with this syntax, the result of Tag('B').add('world') is below 'hello' in the tree structure, not at the same level (just below Tag('DIV')) as it should be

In this case it's not a real problem, but it's obvious if you want to produce <ul><li>one<li>two</ul> : you would need 2 different 'add'
top = Tag('UL')
top.add(Tag('LI').add('one'))
top.add(Tag('LI').add('two'))

With the syntax used in Brython : UL(LI('one')+LI('two'))


> 
> Reject the idea if you will, but do at least please consider it :)
> 
I did in fact consider many options before proposing this one. I have done a lot of web programming, including a web framework, and I faced the problem of generating HTML code from Python. I started with a syntax with nested parenthesis and chained methods returning self, only ending in ugly, unreadable code. Once I started using <= for "add child" and "+" for "add brother" (I first proposed it in the Python Cookbook recipe #366000, the HTMLTags module) - and I've used it on fairly large projects - the result was a much cleaner code

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

#35299

On Sat, Dec 22, 2012 at 2:36 AM, Pierre Quentel
<pierre.quentel@gmail.com> wrote:
>> doc.add(Tag('DIV').add('hello ').add(Tag('B').add('world')))
>>
> No, with this syntax, the result of Tag('B').add('world') is below 'hello' in the tree structure, not at the same level (just below Tag('DIV')) as it should be

No; look at the expanded form for a more readable (but syntactically
identical) version:

doc.add(
  Tag('DIV')
    .add('hello ')
    .add(Tag('B').add('world'))
)

'world' is below Tag('B') - look at the parentheses - but
Tag('DIV').add('hello ') returns the DIV, not the hello, so B and
hello are peers.

> In this case it's not a real problem, but it's obvious if you want to produce <ul><li>one<li>two</ul> : you would need 2 different 'add'
> top = Tag('UL')
> top.add(Tag('LI').add('one'))
> top.add(Tag('LI').add('two'))
>
> With the syntax used in Brython : UL(LI('one')+LI('two'))

They can be directly combined, because Tag.add(self,other) returns
self, not other.

> Yes : a+b returns the string a+str(b)
>
>>>> 'hello '+B('world')
> 'hello <b>world</b>'

Hmm. So when that gets added into a DIV, it has to get parsed for
tags? How does this work? This seems very odd. I would have expected
it to remain as DOM objects.

What happens if I do, for instance:

'blah blah x<y: '+B('True!')

I would expect B('True!') to mean the word "True!" in bold; what
happens with the angle bracket in the text? Am I supposed to manually
escape that as &lt; to protect it? If so, your library isn't doing
much - B might just as well be defined as

lambda s: '<b>'+s+'</b>'

rather than any sort of class.

ChrisA

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

#35306

> Hmm. So when that gets added into a DIV, it has to get parsed for
> tags? How does this work? This seems very odd. I would have expected
> it to remain as DOM objects.

In DIV(child) :
- if child is a string, integer or float, a text node is added (addChild) to the DIV element, with the string value of child
- if child is another DOM element (as in DIV(B('foo'))) then this element is added to the DIV element

The code is in module py_dom.js, class $TagClass

> 
> What happens if I do, for instance:
> 'blah blah x<y: '+B('True!')
> 
You can test this code in the console on the Brython site (http://brython.info/tests/console_fr.html) :

doc <= 'blah blah x<y: '+B('True!')

It will add a text node to the document, with the string 'blah blah x<y: ' followed by 'True!' in bold characters

- Pierre

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

#35325

On Sat, Dec 22, 2012 at 3:36 AM, Pierre Quentel
<pierre.quentel@gmail.com> wrote:
>
>> Hmm. So when that gets added into a DIV, it has to get parsed for
>> tags? How does this work? This seems very odd. I would have expected
>> it to remain as DOM objects.
>
> In DIV(child) :
> - if child is a string, integer or float, a text node is added (addChild) to the DIV element, with the string value of child
> - if child is another DOM element (as in DIV(B('foo'))) then this element is added to the DIV element

Meaning that:
doc <= <p></p>'
will add literal text, not a paragraph object, right? That's
definitely what I would expect.

> doc <= 'blah blah x<y: '+B('True!')
>
> It will add a text node to the document, with the string 'blah blah x<y: ' followed by 'True!' in bold characters

This is where it's getting confusing. My expectation of this is that
it adds a text node with the literal text, followed by a bold node
with its child text. This operation should never involve the parsing
of HTML tags, as the document structure is all there in the code. So
it ought to be a DOM object, not a text string, that gets <='d onto
doc (is <= a verb now?). That means the result of the addition has to
be a DOM object, not a text string; but you said that adding a string
to a B object converts the object to a string and concatenates the
strings.

Do you see now what I mean about the API being difficult to explain?

ChrisA

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

#35326

On Fri, Dec 21, 2012 at 3:52 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Dec 22, 2012 at 3:36 AM, Pierre Quentel
> <pierre.quentel@gmail.com> wrote:
>>
>>> Hmm. So when that gets added into a DIV, it has to get parsed for
>>> tags? How does this work? This seems very odd. I would have expected
>>> it to remain as DOM objects.
>>
>> In DIV(child) :
>> - if child is a string, integer or float, a text node is added (addChild) to the DIV element, with the string value of child
>> - if child is another DOM element (as in DIV(B('foo'))) then this element is added to the DIV element
>
> Meaning that:
> doc <= <p></p>'
> will add literal text, not a paragraph object, right? That's
> definitely what I would expect.
>
>> doc <= 'blah blah x<y: '+B('True!')
>>
>> It will add a text node to the document, with the string 'blah blah x<y: ' followed by 'True!' in bold characters
>
> This is where it's getting confusing. My expectation of this is that
> it adds a text node with the literal text, followed by a bold node
> with its child text. This operation should never involve the parsing
> of HTML tags, as the document structure is all there in the code. So
> it ought to be a DOM object, not a text string, that gets <='d onto
> doc (is <= a verb now?). That means the result of the addition has to
> be a DOM object, not a text string; but you said that adding a string
> to a B object converts the object to a string and concatenates the
> strings.
>
> Do you see now what I mean about the API being difficult to explain?

In my playing around with it just now, the addition doesn't seem to
actually return a string.  I typed this script into the test console:

log('hello ' + B('world'))

and clicked Run, and the result was:

[object Object]

whereas if I just try to log a plain string literal, it actually
prints out the string.  Somewhat disturbingly, this also gives the
[object Object] result:

log(str('hello ' + B('world')))

In Brython, the str builtin does not return strings?

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

#35327

[Multipart message — attachments visible in raw view] — view raw

Héllo,


> > doc <= 'blah blah x<y: '+B('True!')
>

I will surely backlog latter or some crytologist from the futur will do and
he will surely agree about the fact something strange happened around
december 2012.

Sorry for that, that's me trying to be funny. Last time I checked DOM
manipulation is not the primary way for js devs to do DOM manipulation
anymore, or is it ? Javascript template engines do DOM manipulation but
this is almost invisible for the user so whatever the API, I expect this
will be minor, if not completly overlooked by users of Brython. I could
even argue more that for cross-language knowledge sharing the low level API
should be the same but no.

Brython is a very good idea. I failed at something similar except I took
the pyjs route and focused on classes (functions being callable class
objects) and "bindings" which is IMO more interessant than list
comprehensions, operator-overloading and plain functions. The idea was that
bindings will be even more important than in CPython because most of the
hard work for browser compatibility was already done and optimised by the
JS community. I may completly be off beat but the vision was that Python
would be for framework and application developpement and not for utility
libraries that would replace jQuery, SocketIO, Mediator.js History.js or
any template engine hence the focus on classes and meta-programming.

What is the plan regarding this issues in Brython ?

Regards,


Amirouche

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

#35328

On Fri, Dec 21, 2012 at 4:45 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> In Brython, the str builtin does not return strings?

Oh, and repr is just a synonym of str, which makes it useless.

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

#35341

> Oh, and repr is just a synonym of str, which makes it useless.
3 days ago repr was not even implemented at all, so it's a step forward...

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

#35342

> Oh, and repr is just a synonym of str, which makes it useless.
3 days ago repr was not even implemented at all, so it's a step forward...

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

#35329

On Fri, Dec 21, 2012 at 4:45 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> In my playing around with it just now, the addition doesn't seem to
> actually return a string.

>From the code, it appears that adding two nodes together *actually*
returns a $AbstractTag object, which seems to be just a container for
a list of child nodes with no parent, that automagically gets removed
from the hierarchy when appended to another node.

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

#35331

On Sat, Dec 22, 2012 at 10:57 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> From the code, it appears that adding two nodes together *actually*
> returns a $AbstractTag object, which seems to be just a container for
> a list of child nodes with no parent, that automagically gets removed
> from the hierarchy when appended to another node.

That actually makes good sense. The sum of two nodes is an ordered
pair of peers, which will be added sequentially to the same parent.
For this to work, *every* situation needs to be able to handle (with
equal ease) a string, an $AbstractTag, or a node.

ChrisA

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

#35340

I was over-simplifying - or, to put is less diplomatically, I screwed up - when I answered that the addition returned a string. As Chris pointed out, it made the explanation very confusing. My apologies

The objects handled by + and <= can be :
- strings, integers, floats
- instances of $TagClass instances (more precisely, of classes copied from $TagClass, one for each HTML tag) : they are wrappers around a DOM element. The DOM element itself is the attribute "elt" of the $TagClass instance
- the document, represented by the keyword doc. Its attribute "elt" is the document (top of the DOM tree)
- instances of $AbstractClass, a container with a list of DOM elements. This list is the attribute "children" of the $TagClass instance


Depending of the objects types, a+b returns the following objects :

string + string : string (!)
string + $TagClass : $AbstractTag with children [textNode(a),b.elt]
string + $AbstractTag : $AbstractTag with [textNode(b)]+ b.children

The 2 latter are implemented by the method __radd__ of $TagClass and $AbstractTag, invoqued by the method __add__ of the string class

$TagClass + string : $AbstractTag with [a.elt,textNode(b)]
$TagClass + $TagClass : $AbstractTag with [a.elt,b.elt]
$TagClass + $AbstractTag : $AbstractTag with [a.elt]+b.children
$AbstractTag + string : $AbstractTag with a.children+[textNode(b)]
$AbstractTag + $TagClass : $AbstractTag with a.children + [b.elt]
$AbstractTag + $AbstractTag : $AbstractTag with a.children + b.children

(any type) + doc : unsupported
doc + (any type) : unsupported

The operation x <= y does the following :

string <= (any object) : comparison, if possible

($TagClass | doc) <= string | integer | float : adds textNode(str(y)) to x.elt
($TagClass | doc) <= $TagClass : adds child y.elt to parent x.elt
($TagClass | doc) <= $AbstractTag : adds DOM elements in y.children to x.elt

$AbstractClass <= (any type) : unsupported

- Pierre

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

#35344

On Sat, Dec 22, 2012 at 6:57 PM, Pierre Quentel
<pierre.quentel@gmail.com> wrote:
> I was over-simplifying - or, to put is less diplomatically, I screwed up - when I answered that the addition returned a string. As Chris pointed out, it made the explanation very confusing. My apologies
>
> The objects handled by + and <= can be :
> - strings, integers, floats
> - instances of $TagClass instances (more precisely, of classes copied from $TagClass, one for each HTML tag) : they are wrappers around a DOM element. The DOM element itself is the attribute "elt" of the $TagClass instance
> - the document, represented by the keyword doc. Its attribute "elt" is the document (top of the DOM tree)
> - instances of $AbstractClass, a container with a list of DOM elements. This list is the attribute "children" of the $TagClass instance

Ah! Okay, that makes a LOT more sense.

Still, it tends to be a lot harder to explain, document, and read
documentation for, something that uses operators weirdly, rather than
keyword-searchable method names.

ChrisA

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

#35345

> Still, it tends to be a lot harder to explain, document, and read
> documentation for, something that uses operators weirdly, rather than
> keyword-searchable method names.

You don't explain how to use the Python syntax (for instance the operator %, which behaves very differently between integers and strings) by explaining what happens in the underlying C code in the different cases, do you ?

I would put the above explanations in the "implementation notes" of Brython, but not on the "how to use Brython" documentation, which is quite simple to explain with <= and + (it's in the section "Handling of HTML documents" in the docs)

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

#35349

On Sat, Dec 22, 2012 at 7:54 PM, Pierre Quentel
<pierre.quentel@gmail.com> wrote:
>> Still, it tends to be a lot harder to explain, document, and read
>> documentation for, something that uses operators weirdly, rather than
>> keyword-searchable method names.
>
> You don't explain how to use the Python syntax (for instance the operator %, which behaves very differently between integers and strings) by explaining what happens in the underlying C code in the different cases, do you ?

Agreed, and it's sometimes confusing. I don't see "string % tuple" as
a good syntax; I prefer to spell it sprintf("format",arg,arg,arg).
When it comes to operators on strings, what I'd prefer to see is
something that does more-or-less what the operator does with integers
- for instance:

"This is a string" / " " ==> ["This","is","a","string"]

Taking a string modulo a tuple doesn't make any sense in itself, so it
CAN be given an alternative meaning. But if you see that in a program
and aren't sufficiently familiar with %s formatting to recognize it,
how are you going to locate the documentation on the subject? Googling
for 'python % string' doesn't help; 'python string modulo' brings up
an article on informit.com that explains the matter, but nothing
official. By contrast, searching for 'c sprintf' brings up heaps of
useful links, because 'sprintf' is a searchable keyword.

On the flip side, operator-based notations end up a lot more compact.
I'd definitely not want to give up, for instance, list comprehension
syntax. Difficulty of searching for docs is a downside, but definitely
not a blocker.

ChrisA

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

#35353

On Sat, 22 Dec 2012 20:08:25 +1100, Chris Angelico wrote:

> I don't see "string % tuple" as a good syntax; I prefer to spell it
> sprintf("format",arg,arg,arg). 

Very possibly one of the worst names ever from a language that excels at 
bad names. "Sprint f"? WTF?

Certainly not appropriate for Python, where a sprintf equivalent would 
return a new string, rather than automatically print the result. Oh 
wait... C's sprintf doesn't automatically print either.

*wink*



> When it
> comes to operators on strings, what I'd prefer to see is something that
> does more-or-less what the operator does with integers - for instance:
> 
> "This is a string" / " " ==> ["This","is","a","string"]

I don't see the connection between the above and numeric division. If it 
were this:

"This is a string" / 3 ==> ["This ", "is a ", "strin", "g"]

(and presumably // 3 would be the same except the "g" would be dropped) 
then I could see the connection. But there's no relationship between 
numeric division, which divides a number up into N equal-sized parts, and 
string splitting as you show above.

Of course, if we can just invent a meaning for the % operator that has 
nothing to do with either percentages or numeric modulo, then we could 
equally invent a meaning for / for strings. But if we did so, it still 
wouldn't have anything to do with numeric division.


> Taking a string modulo a tuple doesn't make any sense in itself, 

Taking an integer cross an integer doesn't make any sense if you haven't 
learned the meaning of the + operator. Why insist that only string 
operators must make inherent sense to somebody who doesn't know what the 
operator means? If we're allowed to learn the meaning of + * and &, why 
not % as well?


-- 
Steven

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

#35356

On Sat, Dec 22, 2012 at 10:05 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sat, 22 Dec 2012 20:08:25 +1100, Chris Angelico wrote:
>
>> I don't see "string % tuple" as a good syntax; I prefer to spell it
>> sprintf("format",arg,arg,arg).
>
> Very possibly one of the worst names ever from a language that excels at
> bad names. "Sprint f"? WTF?
>
> Certainly not appropriate for Python, where a sprintf equivalent would
> return a new string, rather than automatically print the result. Oh
> wait... C's sprintf doesn't automatically print either.
>
> *wink*

Sure, it's not ideal, but it's the string-returning form of printf,
which prints formatted text, so it's not completely inappropriate. But
my point stands: it's an easy thing to search for.

>> When it
>> comes to operators on strings, what I'd prefer to see is something that
>> does more-or-less what the operator does with integers - for instance:
>>
>> "This is a string" / " " ==> ["This","is","a","string"]
>
> I don't see the connection between the above and numeric division. If it
> were this:
>
> "This is a string" / 3 ==> ["This ", "is a ", "strin", "g"]
>
> (and presumably // 3 would be the same except the "g" would be dropped)
> then I could see the connection. But there's no relationship between
> numeric division, which divides a number up into N equal-sized parts, and
> string splitting as you show above.

Sure, but it's still dividing. It's a different form of division, but
it still makes sense. "Oh, you're dividing that string by a delimiter.
I'd prefer to call it 'on' a delimiter, but 'by' works." Your
description makes perfectly good sense too, though; however, if:

"This is a string" / 3 ==> ["This ", "is a ", "strin", "g"]
and
"This is a string" // 3 ==> ["This ", "is a ", "strin"]
then
"This is a string" % 3 ==> ["g"] or possibly "g"

which is incompatible with current usage. But that's a meaning that
makes reasonable sense as "modulo".

>> Taking a string modulo a tuple doesn't make any sense in itself,
>
> Taking an integer cross an integer doesn't make any sense if you haven't
> learned the meaning of the + operator. Why insist that only string
> operators must make inherent sense to somebody who doesn't know what the
> operator means? If we're allowed to learn the meaning of + * and &, why
> not % as well?

Sure, but + and * have meaning in mathematics, not just programming,
and it's a similar meaning. Even the much-maligned = assignment, which
has quite a different meaning to = equality, which itself isn't the
same as the = equality in mathematics, is sufficiently close that it's
grokkable. But someone coming from a mathematical background has no
particular advantage in figuring out that % means formatting, or that
<= means add child. That doesn't mean they shouldn't be done, just
that the justification hump is that bit higher.

ChrisA

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

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

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

csiph-web