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 3 of 3 — ← Prev page 1 2 [3]

#35380

On Sat, 22 Dec 2012 23:11:00 +1100, Chris Angelico wrote:

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

Wikipedia (http://en.wikipedia.org/wiki/Asterisk) doesn't even list 
multiplication as a mathematical use of the asterisk.

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

Practicality beat (paste tense) purity.

Dan

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

#35386

On Sat, Dec 22, 2012 at 1:31 PM, Dan Sommers <dan@tombstonezero.net> wrote:
> 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.

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

#35393

On Sun, Dec 23, 2012 at 7:31 AM, Dan Sommers <dan@tombstonezero.net> wrote:
> On Sat, 22 Dec 2012 23:11:00 +1100, Chris Angelico wrote:
>
>> "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

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

#35346

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

#35343

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]

#35332

On Sat, Dec 22, 2012 at 10:50 AM, Amirouche Boubekki
<amirouche.boubekki@gmail.com> wrote:
> 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...

Not sure how most of the world works, but I write using the DOM.
There's little point using jquery etc when what you're doing is really
simple - which, for me, it is. So I'm probably not representative.

ChrisA

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

#35307

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

#35298

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

#35288

Pierre Quentel <pierre.quentel@gmail.com> wrote:

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

Or you can do something like this:

>>> from lxml.html.builder import *
>>> snippet = DIV("Hello ", B("world"))
>>> etree.tostring(snippet)
'<div>Hello <b>world</b></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 ?
> 
The one that doesn't do unexpected things with operators.


-- 
Duncan Booth http://kupuguy.blogspot.com

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

#35289

Duncan Booth, 21.12.2012 14:14:
> Pierre Quentel wrote:
>>> 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?
>>
>> 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)
> 
> Or you can do something like this:
> 
> >>> from lxml.html.builder import *
> >>> snippet = DIV("Hello ", B("world"))
> >>> etree.tostring(snippet)
> '<div>Hello <b>world</b></div>'

For which there even happens to be an ElementTree implementation available:

http://svn.effbot.org/public/stuff/sandbox/elementlib/builder.py

(It's not like I made this up ...)

Stefan

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

#35286

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

#35333

On Fri, 21 Dec 2012 12:25:01 +0100, Stefan Behnel wrote:

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

Yo mean something old, unpythonic and ugly? :-P



-- 
Steven

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

#35187

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 <tjreedy@udel.edu> wrote:
> 
> > That says that my browser, Firefox 17, does not support HTML5. Golly gee. I
> 
> > don't think any browser support5 all of that moving target, and Gecko
> 
> > apparently supports about as large a subset as most.
> 
> > https://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29
> 
> > It is possible the FF still does not support the particular feature needed
> 
> > for the clock, but then the page should say just that. Has the latest FF
> 
> > (17) actually been tested?
> 
> 
> 
> It works for me using FF 17.0.1.
> 
> 
> 
> >> 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.  The DOM already has a well-established API.  The following may
> 
> require more typing:
> 
> 
> 
> link = document.createElement('a')
> 
> link.setAttribute("href", "http://www.python.org/")
> 
> link.appendChild(document.createTextNode('Python'))
> 
> document.body.appendChild(link)
> 
> 
> 
> But it is much clearer in intent.  Since these methods map directly to
> 
> DOM methods, I know exactly what I expect them to do, and I can look
> 
> them up in the browser documentation if I have any doubts.  With the
> 
> one-liner above, I don't know exactly what that maps to in actual DOM
> 
> calls, and so I'm a lot less clear on what exactly it is supposed to
> 
> do.  I'm not even entirely certain whether it's actually equivalent to
> 
> my code above.
> 
> 
> 
> I suggest that Brython should have a "low-level" DOM API that matches
> 
> up to the actual DOM in as close to a 1:1 correspondence as possible.
> 
> Then if you want to have a higher-level API that allows whiz-bang
> 
> one-liners like the above, build it as an abstraction on top of the
> 
> low-level API and include it as an optional library.  This has the
> 
> added benefit that if the user runs into an obscure bug where the
> 
> fancy API breaks on some particular operation on some specific
> 
> browser, they will still have the option of falling back to the
> 
> low-level API to work around it.  It would also make the conversion
> 
> barrier much lower for web programmers looking to switch to Brython,
> 
> if they can continue to use the constructs that they're already
> 
> familiar with but just write them in Python instead of JavaScript.

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

With this idea in mind, asking Brython to have a Javascript-like low-level API is like asking CPython to support iteration with a low-level construct like "for i=0;i<10;i++" along with "for i in range(10)". The Python engine is stable enough that we don't have to inspect the bytecode for debugging ; similarly, when Brython is mature enough, you won't have to look at the generated Javascript code (which you can do though, eg in the console)

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

#35175

On 12/19/2012 7:54 PM, Ian Kelly wrote:
> On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> That says that my browser, Firefox 17, does not support HTML5. Golly gee. I
>> don't think any browser support5 all of that moving target, and Gecko
>> apparently supports about as large a subset as most.
>> https://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29
>> It is possible the FF still does not support the particular feature needed
>> for the clock, but then the page should say just that. Has the latest FF
>> (17) actually been tested?
>
> It works for me using FF 17.0.1.

It works for me too when ignore the mistaken and misleading error 
message and just turn on javascript for the page. Some sites say things 
like "You have javascript turned off. Turn it on to see all features."
>
>>> 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.  The DOM already has a well-established API.  The following may
> require more typing:
>
> link = document.createElement('a')
> link.setAttribute("href", "http://www.python.org/")
> link.appendChild(document.createTextNode('Python'))
> document.body.appendChild(link)
>
> But it is much clearer in intent.

I agree with the rest of your suggestion.

-- 
Terry Jan Reedy

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

#35189

* Ian Kelly <ian.g.kelly@gmail.com> [2012-12-19 17:54:44 -0700]:

> On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> > That says that my browser, Firefox 17, does not support HTML5. Golly gee. I
> > don't think any browser support5 all of that moving target, and Gecko
> > apparently supports about as large a subset as most.
> > https://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29
> > It is possible the FF still does not support the particular feature needed
> > for the clock, but then the page should say just that. Has the latest FF
> > (17) actually been tested?
> 
> It works for me using FF 17.0.1.

I'm using FF 13 on OpenBSD and it works for me too. 

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

#35348

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

[toc] | [prev] | [standalone]

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

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

csiph-web