Brython - Python in the browser

[Pierre Quentel]

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

 

[Pierre Quentel]

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

 

[Pierre Quentel]

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

 

[Pierre Quentel]

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

 

[Chris Angelico]

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

 

[Pierre Quentel]

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)

 

[Pierre Quentel]

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)

 

[Pierre Quentel]

I forgot to mention : list comprehensions and the ternary operator (r1 if cond else r2) are now supported !
- Pierre

 

[Chris Angelico]

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

 

[Steven D'Aprano]

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?

 

[Chris Angelico]

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

 

[Ian Kelly]

So why are we all so comfortable with using "*" as the operator for
multiplication? I'm sure that a new programming language that dared to
use U+00D7 or U+2715 for multiplication would be instantly rejected on
the grounds that it was confusing and incompatible with current practice.

As long as the language doesn't also use "*" for anything so that I
can just alias Shift-8 in my editor, no objections here.

 

[Chris Angelico]

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

So why are we all so comfortable with using "*" as the operator for
multiplication? I'm sure that a new programming language that dared to
use U+00D7 or U+2715 for multiplication would be instantly rejected on
the grounds that it was confusing and incompatible with current practice.

Less on the confusing and more on the hard to type; same reason we
don't indicate division by writing a long bar, but use the slash
instead. Also, algebra has a tendency toward short variable names,
where programming tends toward longer ones, so algebra optimizes in
favour of multiplication - that's why we don't write code like
"h{ello}w{orld}" to mean "multiply hello by world".

Until recently, the number of characters available to a programming
language was limited (APL notwithstanding).

REXX had two boolean negation operators, one of which wasn't ASCII.

Practicality beat (paste tense) purity.

Yep. Definitely. We need to be able to type code fast, read code fast,
and worry about algebra slowly. Arguments from algebra are mainly for
justifying a new piece of syntax so people can understand it without
having to keep the manual open beside them.

ChrisA