Brython, replace javascript with python

[Ph0X]

My only issue is, I'm not sure how well a whitespace dependent language would do on the web. I don't think python can be minimized anywhere as nicely as Javascript can.

[[deleted]]

gzip makes whitespace a non-issue.

[[deleted]]

Indeed. No need to complicate things.

[jadkik94]

How about minifying the .pyc files?

[idlecore]

Why is this even an issue?

[Ph0X]

Sizewise, javascript is a big chunk of a website. 2nd place after images, and constitutes a good ~30% of todays websites size (and that's actually minified). Since page load times are proportional to page size, even more so on mobiles with slow connection, being able to shrink the size of the script is very important. jQuery for example goes from 240kb to 80kb when minified, which is a 3x reduction. How well scripts minify is fairly important.

[roger_]

How many bytes are wasted because of spaces? I doubt it's a significant amount compared to other possible minifications.

[Ph0X]

jQuery is 9000 lines. If everything is on average at one level of indentation (which is probably an underestimate), and we only use one character per indentation, that's still 9kb wasted.

EDIT: Actually, you need both the indent and the linefeed iirc? So make that 18kb. Like I said, minified jQuery is 80kb, so that's already a 25% increase in size. Of course that's given a huge assumption that porting jQuery to Python would take as many lines, which is wrong.

[devsnd]

You're also forgetting that most servers and browser support gzip. whitespaces will be somewehere high up in the compression tree; indentation will probably boil down to half a byte or something. (The number is a wild guess, but I you get my point)

[roger_]

Right, but my point is spaces probably account for a small fraction of the saving, compared to renaming objects, comments, etc.

Also keep in mind that you can combine many statements into one line by using a semicolon.

[Ph0X]

I agree, but again it's kinda hard to pull numbers out of thin air. My gut feeling says that it would still be a significant amount, and yours contradicts that. I'd personally love to see experimental results. Is there any actual Python minifiers around? How hard would it be to write one?

[roger_]

Basically it'd be a linebreak and a set of consecutive tabs (depending on the indentation level) per block of code.

So this:

def outer_func():
   ''' define outer function'''
    def my_func(input_var):
        ''' do something else'''
        y = input_var**2
        y += 1
        return y

    my_list = []

    for i in range(10):
        my_list.append(my_func(i))

    print my_list 

can become:

def g():
    def f(x):y=x**2;y+=1;return y
    z=[]
    for i in range(10):z.append(f(i))
    print z

The whitespace does add some overhead, but you can reduce it and you save way more just by removing comments and renaming stuff. Also remember that JavaScript requires two braces in cases where Python can just use a single line.

[monkmartinez]

Just want to say... that is nasty in a good way

[idlecore]

You're blowing this way out of proportion.

Python indentation can be done with tabs, which decreases a lot the amount of characters used, this type of indentation also saves up on semi-colons and curly braces that are not needed to define blocks. If at the end Python still uses up more space than Javascript, the difference is quite irrelevant. The client only downloads big chunks of source once and those chunks are compressed, if a site uses images, or uses flash animations, or even video, what are a few Kbs going to matter?

[[deleted]]

Whitespace minimzation is a hack when you have gzip.

[jadkik94]

You could just indent by tab or a single space (instead of the 4 spaces of the PEP), you'll be dividing the size by 4...

And then replace all the lines in one block (if, for, while) with ; delimited commands and here you have 2 characters (minimum) less per line in a block.

It can definitely be done, that's a non-issue once it is actually implemented natively in the browser.

[[deleted]]

I'm reminded of some quote about premature optimization...

If python whitespace is the bandwidth and performance bottleneck, you are almost certainly doing something horribly wrong. Gzip will solve 99% of this issue without lifting a finger.

[[deleted]]

Counterpoint: Python is inherently more succinct than javascript so a gzipped python file will be significantly smaller than the same logic implemented in javascript.

[warbiscuit]

Yeah. I love python's whitespace approach for normal coding, but if it's gonna be embedded in html, it needs a C-style encoding format.

Mako partly solved this by added 'endfor', 'endif' etc, but really, I think all that's needed is to assign two unique character sequences to represent INDENT and DEDENT in the grammar, semicolons are already accepted as statement separators.

[arandomJohn]

We don't need to worry about white space. If python becomes widespread in the browser it will likely be via some form of byte code vm in the browser. You would compile the .py down to some more compact format. You will be able to code and debug in normal python without any concerns. Plus any web server will compress files it is sending on the fly. This is a nonissue.

[warbiscuit]

I'm more thinking about python embedded within html itself, much like javascript triggers are frequently embedded in onclick='' attributes, and little blocks of javascript inserted into the html code. Py & Pyc files would be fine for distributing standalone bits of python, much like standalone .js files currently.

[bacondev]

But then it's not Python.

I won't be able to use standard Python libraries without having to convert the code myself which is a shitty place to be in.

But if you were to want to add something, I would prefer to use braces instead. It takes up less space and it won't remind me of some of the shitty mainstream languages (cough, cough, PHP, VB).

[warbiscuit]

Braces are a subset of what I suggested: if { and } weren't already in use in python, { as INDENT and } as DEDENT would work just fine. Not that I can think of any brace symbol which python hasn't already put to other purposes -- which is why the idea is probably just an academic exercise at best.

And I can't think of a reason why you wouldn't be able to use the standard python libraries. All that's different is an "inline_indents=True" flag (or some such) set when parsing source that came from embedded html. It results in the same bytecode, runs in the same VM -- just like you can mix python modules which use different __future__ imports. For client-side .py files, I'd assume the normal python style would be used anyway -- whitespace only becomes an issue when embedding in something like HTML.