Interesting opinion on Python vs Javascript

[Pierre Quentel]

Hi,

I found this text written by Phil Jones on http://www.quora.com/What-are-the-kinds-of-applications-that-are-not-suitable-to-be-developed-using-Python#. Very interesting, not only because he quotes Brython ;-)

The big crisis facing Python is the rise of Javascript.

Bluntly, much of the UI of applications has migrated to the browser. And with things like meteor.js you're starting to see code which is written to span the browser and server. Not just using the same language at both ends, but defining functions and data-structures which migrate transparently between the two.

node.js is increasingly popular serverside. node-webkit lets you write full desktop GUI apps. in javascript / html5 / css.

Python is a far nicer language than Javascript, but CoffeeScript is pretty close to Python for most purposes.

So there's interesting work to make Python compile to Javascript (eg. Brython ), so that like CoffeeScript and ClojureScript etc. it can be a full browser citizen. but it's hardly the first choice for in-browser apps.

Similarly, it's not really making much of an impact on mobile development, where Java and Objective-C still dominate and there doesn't seem to be much of an opening for Python-based development.

[Kiko]

Interesting lecture. Python is suffering the hype of Node and Go these days, mainly in web development. On other fields the is quite strong like data analytics.

In my proselitism about Brython I think that Brython is seen in a skeptical way with people saying 'learn js', 'it has performance issues', 'it is very heavy',... 

Brython is quite stable and most of the usual CPython3 functionality is covered and maybe some work should be done in marketing. To solve some of these issues I think the best way is to write very good tutos about Brython, create interesting and useful things using Brython, conferences, create a speed.brython.info site to show that Brython is not so slow (when compared to vanilla js) and in most of the cases the performance is not and issue, create some scripts to create standalone brython distributions only with the libs and with the parts of Brython.js that you are using to obtain lighter Brython distributions provide a possibility to compile directly to js would be a must (IMHO),...

[Kiko]

Some ideas:

I was working in a Python tutorial using Brython and I tried to use the official Python tutorial so most of the text is already written. There are parts of the official Python tutorial that are not easily portable to the browser but most of it is possible to be used. Maybe this could be a good marketing for newcomers to Python (Universities teaching Python, MOOCS,...)

Another idea was some code in the browser.javascript module to convert between js objects to Python classes so js libs could be more easily ported/used to/with Brython or write wrappers around these js libs would be easier.

But my time is very limited these days :-(

[Billy Earney]

I'd like to get the group's opinion on a few things...

I sometimes wonder where my 'brython' time is best used.  There are many fronts:

* implement python 3 syntax, so that brython is python 3 compliant.

* try to port python 3 standard libraries to brython (this requires importing the module, and trying to track down errors/bugs).

* get python 3 unit tests to work with brython.  (many tests pass, but many tests fail).  Many of the ones that fail are edge cases that do not usually occur in most applications, or tests fail because those modules/functions/feature has not been ported yet.

* speed.brython.info:  I believe as time goes on this will be very useful to convince people that brython does perform well compared to its peers (Cpython, jython, pypy, etc).

* implement some type of interface that allows brython to be used in the classroom.  Integrate with google drive (or some other storage mechanism)  so that python scripts can be saved/loaded (or imported) by brython to a students personal drive in the cloud.   If the prep time/cost is low for instruction of python (via brython), I could see more classrooms using brython.   If brython is one of the first languages students learn, they could use it for decades.  Wouldn't it be cool to learn brython for an intro to programming class, and then later use brython to develop websites?  Need a tool to do data analysis, you can use brython/python, need to tool for x, (you get the picture!)  :)

Lately, I've used most of my time fixing bugs, speeding up javascript code, getting some unit tests to work, and code coverage.

I believe all these fronts are important.   I've been leaning toward doing tasks that make brython, python 3 compliant (or doing things that support python 3 compliant work).

What do others think?   I want my time to be used to the maximum effect for this project.   I believe in brython, and I want to see it succeed.

I also wonder if we should create a brython foundation who's mission is to promote brython.  I believe Pierre is taking on the cost of the brython.info website.  Should we help with that burden?

Thanks!

Billy

--
You received this message because you are subscribed to the Google Groups "brython" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brython+u...@googlegroups.com.
To post to this group, send email to bry...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/brython/CAB-sx605JXONj_CjHXaM_AoVmJ5NtYmLh-_5DEoeOiU6Geoijg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Kiko]

2014-09-04 16:15 GMT+02:00 Billy Earney <billy....@gmail.com>:

I'd like to get the group's opinion on a few things...

I sometimes wonder where my 'brython' time is best used.  There are many fronts:

* implement python 3 syntax, so that brython is python 3 compliant.

You can have a look to other projects like jython, pypy,... Be 100% compliant is a lot of effort. Pypy has some funding and the (experienced and motivated) team is working in v3.3 and the CPython 3.5 is almost there. Pypy has more contributors than Brython. It is always a race and a huge effort if you want to be updated.

 

* try to port python 3 standard libraries to brython (this requires importing the module, and trying to track down errors/bugs).

Some libs are not very useful in a browser environment. I made a poll on reddit to know which stdlibs are more important for the community:

http://www.reddit.com/r/Python/comments/28r85w/what_modules_of_the_python_stdlib_do_you_use_more/

There is also this question:

http://www.reddit.com/r/Python/comments/28yo37/what_are_the_top_10_builtin_python_modules_that_a/

Maybe we should focus on these modules if they have sense in the browser.

The first and second fronts you are working on are like the 5% of functionality that costs the 95% of your time.

 

* get python 3 unit tests to work with brython.  (many tests pass, but many tests fail).  Many of the ones that fail are edge cases that do not usually occur in most applications, or tests fail because those modules/functions/feature has not been ported yet.

I started to look at this. I will try to start working on small stuff.

 

* speed.brython.info:  I believe as time goes on this will be very useful to convince people that brython does perform well compared to its peers (Cpython, jython, pypy, etc).

If it is faster than CPython is a plus but I think the battle here is not to be much slower than js. To work in a regular Python environment you have CPython and Pypy. Brython is useful in the browser and in the browser the assembly language is JS.

 

* implement some type of interface that allows brython to be used in the classroom.  Integrate with google drive (or some other storage mechanism)  so that python scripts can be saved/loaded (or imported) by brython to a students personal drive in the cloud.   If the prep time/cost is low for instruction of python (via brython), I could see more classrooms using brython.   If brython is one of the first languages students learn, they could use it for decades.  Wouldn't it be cool to learn brython for an intro to programming class, and then later use brython to develop websites?  Need a tool to do data analysis, you can use brython/python, need to tool for x, (you get the picture!)  :)

Project Jupyter (IPython folks) is working on that direction with google. See https://colaboratory.jupyter.org/welcome/. Again, they have a solid project, money, they use CPython and a big community. I think Brython should focus in the browser as a tool to create rich applications in the web at least I use Brython for that. I mean, for me Brython is for the web. Of course you can create interesting interactive tutorials (see for example this I read today on HN, http://shaunlebron.com/t3tr0s-slides/#0). I think this kind of materials are more helpful, funny and useful for the people.

 

Lately, I've used most of my time fixing bugs, speeding up javascript code, getting some unit tests to work, and code coverage.

Thanks for the hard work. 

I believe all these fronts are important.   I've been leaning toward doing tasks that make brython, python 3 compliant (or doing things that support python 3 compliant work).

What do others think?   I want my time to be used to the maximum effect for this project.   I believe in brython, and I want to see it succeed.

Me too. It is a very interesting project and I am learning a lot.

 

I also wonder if we should create a brython foundation who's mission is to promote brython.  I believe Pierre is taking on the cost of the brython.info website.  Should we help with that burden?

I could create a mirror of Brython.info, I could host speed.brython.info,... IF I can help in this sense just let me know.

Some ideas:

-A roadmap detailing where is brython going.

-Migrate to GitHub. For me it's a Catch-22 situation and I don't like to be on GitHub but it is a good marketing tool.

-Proselitism on twitter and other sites. The @Brython3 account is not very active.

-The most experienced Brython developers (Pierre and Billy) could open small issues to allow other people help. In Guthub you have tags for issues and 'Easy Fix' is one of them. Sometimes I don't know where to start.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/brython/CAB1ii-c%3D7GFcf9pH0msgNEv_wfMeLSQN%2BcmN6OtxwivF%3DCRS7A%40mail.gmail.com.

[André]

On Thursday, 4 September 2014 11:15:05 UTC-3, Billy Earney wrote:

I'd like to get the group's opinion on a few things...

I sometimes wonder where my 'brython' time is best used.  There are many fronts:

* implement python 3 syntax, so that brython is python 3 compliant.

* try to port python 3 standard libraries to brython (this requires importing the module, and trying to track down errors/bugs).

* get python 3 unit tests to work with brython.  (many tests pass, but many tests fail).  Many of the ones that fail are edge cases that do not usually occur in most applications, or tests fail because those modules/functions/feature has not been ported yet.

* speed.brython.info:  I believe as time goes on this will be very useful to convince people that brython does perform well compared to its peers (Cpython, jython, pypy, etc).

* implement some type of interface that allows brython to be used in the classroom.  Integrate with google drive (or some other storage mechanism)  so that python scripts can be saved/loaded (or imported) by brython to a students personal drive in the cloud.   If the prep time/cost is low for instruction of python (via brython), I could see more classrooms using brython.   If brython is one of the first languages students learn, they could use it for decades.  Wouldn't it be cool to learn brython for an intro to programming class, and then later use brython to develop websites?  Need a tool to do data analysis, you can use brython/python, need to tool for x, (you get the picture!)  :)

Lately, I've used most of my time fixing bugs, speeding up javascript code, getting some unit tests to work, and code coverage.

I believe all these fronts are important.   I've been leaning toward doing tasks that make brython, python 3 compliant (or doing things that support python 3 compliant work).

What do others think?   I want my time to be used to the maximum effect for this project.   I believe in brython, and I want to see it succeed.

I also wonder if we should create a brython foundation who's mission is to promote brython.  I believe Pierre is taking on the cost of the brython.info website.  Should we help with that burden?

Thanks!

Billy

(disclaimer: I recognize that it is always easier to offer observations that may appear to be negative criticism than to actually contribute to a project.  I am [at least currently] not in a position to contribute to Brython's development and what I write below is meant to be taken as positive criticism/observations/suggestions.)

Taking a step back ... I think that to have Brython become "successful" (for some definition of success), it has to be recognized by the Python community as a true Python implementation.  Thus, implementing Python 3 syntax and getting standard unit tests to work (except for modules that do not make much sense in a browser - and clearly identified as that) has to be the first priority.  Once Brython is perceived as truly compatible, I expect that some active Python contributors will start contributing to Brython's effort which could speed its development quite considerably.   I would worry slightly less about how complete the standard library is ported.

Looking at the current Brython site, the take home message is that we have some sort of Python implementation with a whole bunch of non-standard browser-specific modules.  To me, the emphasis on those modules (which is, in some ways, extremely appropriate) needs to be counterbalanced by clear statements about Brython being or seeking to become a true and faithful Python implementation which just happens to be designed to run in browsers and has additional relevant modules in its standard library.

Focusing on speed is interesting as it captures the attention in the way a sound-bite does for news media; I think it is important to have Brython be at least roughly as fast as CPython and not an order of magnitude slower than pure Javascript, so that it can not be dismissed on that count. Eventually, more speed might be interesting obviously...

 

In addition to the suggested speed.brython.info site, I think it might be useful to have a page devoted to listing Python 3 implemented features, as well as those left to do  (perhaps using "Syntax, keywords and built-in functions" from the current Brython documentation as a starting point).  Perhaps this could include a table of all unit tests (!) indicating which ones are passing and which ones are failing.

Similarly, a page listing all the modules of the standard library, indicating which ones are supported and which ones are not, might be useful.

Just my opinion...

André

[Billy Earney]

Thanks..  all comments are greatly appreciated.   I think we need to have these conversations.

To view this discussion on the web visit https://groups.google.com/d/msgid/brython/4ebc4eef-6762-40fd-8128-dbdea5f421e2%40googlegroups.com.

[Dirk Krause]

I fully agree on most points and also think that this discussion has to happen.

Let me chime in by adding/emphasizing a few points.

- +1 for github. They clearly won. Projects that are not on github are either old, irrelevant or both. I don't know how much work migrating is, though.

- ergo also +1 on Billy's 'small issues tag' comment

- +1 on Kiko's comment about marketing. I hate to say this, but there must be some more effort on this (I say that because I am guily in that respect, too, for most of my projects).

- I would love to see a page (or a playground) that shows the JS that is created from Brython. It's not mandatory, but I think there will be people who want to see the efficency of the transpiling step.

- 'interface for brython in classrooms': I recently whipped up a prototype for exactly that in the last days. Now that this discussion comes up, I will post that example ASAP.

Also: JS won't go away for a long time. There are very good JS libs out there that don't need to be recreated just because everything needs to be brythonized. If for example mrdoob's ThreeJS gets improved, I don't want to re-transpile this to Brython - I just want to be able to use it. With Brython I can have the core logic written in Python and the rest of it stays JS.

Best,

 Dirk

[Andre Roberge]

On Fri, Sep 5, 2014 at 4:01 AM, Dirk Krause <dir...@googlemail.com> wrote:

I fully agree on most points and also think that this discussion has to happen.

Let me chime in by adding/emphasizing a few points.

- +1 for github. They clearly won. Projects that are not on github are either old, irrelevant or both. I don't know how much work migrating is, though.

- ergo also +1 on Billy's 'small issues tag' comment

- +1 on Kiko's comment about marketing. I hate to say this, but there must be some more effort on this (I say that because I am guily in that respect, too, for most of my projects).

- I would love to see a page (or a playground) that shows the JS that is created from Brython. It's not mandatory, but I think there will be people who want to see the efficency of the transpiling step.

http://brython.info/tests/editor.html

Enter some Python code in the editor then click on the "Javascript" button at the top right of the output window.

 

You received this message because you are subscribed to a topic in the Google Groups "brython" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/brython/m7PwnhSQimY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to brython+u...@googlegroups.com.

To post to this group, send email to bry...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/brython/b54de27d-36b8-4cba-81e5-7c40ec83da95%40googlegroups.com.

[Dirk Krause]

Cool, thanks! I wasn't aware of that.

> https://groups.google.com/d/msgid/brython/CAGMu_%3DqK%3Dyb0HYhSQtV8ZB5NRRSqgYwFgWKJ6bBdO2%2BLv8EfBw%40mail.gmail.com.

[Billy Earney]

I agree with just about everything commented on.  This verifies many of the thoughts l have had.

Do others have suggestions or comments?

To view this discussion on the web visit https://groups.google.com/d/msgid/brython/CAOABhMCFpiG4OEy8mhpC-rghvOsU3E4RBtcscBjz7UP71UZWTw%40mail.gmail.com.

[Pierre Quentel]

Le vendredi 5 septembre 2014 15:52:13 UTC+2, Billy Earney a écrit :

I agree with just about everything commented on.  This verifies many of the thoughts l have had.

Do others have suggestions or comments?

Thanks for all the comments, its nice to see how committed you are to make Brython more successful !

First thing to cheer us up : Brython *is* popular. Not as much as we would like, sometimes with a stress on its weaknesses, but when people discuss Python in the browser nowadays, Brython is almost always mentioned. Google "python browser" : Brython is 2nd, after the module webbrowser in the standard distribution. Google "Python implementations" : the first page is the wiki on python.org, and Brython comes first in the list of "working implementations". Even Guido thinks it's interesting (https://mail.python.org/pipermail/idle-dev/2014-February/003371.html) !

Among all the topics listed in this thread, I agree with André that in order to reach our main target (the Python community) the first thing is to produce an implementation that works like CPython. A huge effort has been made in this direction, thanks primarily to all those who have reported differences between Brython and CPython (special thanks to Carlo here). For me it remains the top priority, meaning that if someone reports a difference, its resolution takes priority over any other task. But I think it will require less and less work in the next months

Speed is important, and this is my priority at the moment. Brython must be faster than today, and I will use the PyPy benchmark to see where it can be improved. It's good to see it can be faster than CPython in some cases, but I'm almost certain it will remain slower in most cases, because there will be no tradeoff between compliance and speed

Many of you (Kiko, Billy) suggest developing an environment to teach Python in classes. It would be great to join efforts in this direction : could one of you take the lead on this task and open a specific project ? I would help as much as I can but I think I'm more useful on core development. As a Python teacher myself, I have created an online tutorial based on the official Python tutorial, you can find it here : http://brython.info/cours_python/cours_python.html. It's in French but probably not too difficult to translate into other languages. Of course it is developed using the slideshow module (https://bitbucket.org/brython/brython-slideshow)

About documentation : it certainly lacks a "getting started" section for newcomers. Someone suggested a video on Youtube, that would be great ! There again, could someone take the lead on this ?

Ok for moving to github if everyone agrees that it would be better for exposure. I have created a project PierreQuentel/brython and will initialize it soon

Just for information, the domain brython.info and the hosting cost me less than 10€ per year, I can manage it ;-)

- Pierre
 

[João Ventura]

Hi there,

I'm not very active in the brython community, but I would like to express my opinion, if I may.

Nowadays, a good marketing strategy is very important for any project, be it commercial or open-source. And I think that the focus for the project, considering that it is pretty stable for now, should be on performance (or speed). There could be a web page only with comparative benchmarks, that could say to developers something in the lines of "you can use brython, it is x% as fast as CPython/Javascript/other".

Some time ago, I ported some of my Python code to Brython. However, the imports were so slow that I had to forget it. But I keep coming back to this group to see if things are better. It is inevitable for me to use Python in the browser someday. It is so much better than Javascript that I can take _some_ speed penalty to make up for it!

Also, although I am not contributing code to the project, I fully support the move to Github. The Github community seems larger and they seem to provide better tools than bitbucket. The traction is better on that side of the world..

Finally, since I'm planning to use Brython for a commercial web application, protecting "somewhat" the source code has some importance to me. Is anything in the pipeline for this? For instance, use of pyc files, or doing "controlled" imports using websockets instead of having your precious python source files in a public static folder?


João Ventura

[Olemis Lang]

On 9/5/14, Pierre Quentel <pierre....@gmail.com> wrote:
>
[...]

>
> Ok for moving to github if everyone agrees that it would be better for
> exposure. I have created a project PierreQuentel/brython and will
> initialize it soon
>

fwiw -1 from my perspective ... I really see no benefit for moving
onto github . Has anybody really wanting to contribute with the
project actually found bitbucket to be a barrier ?

If you want to switch to using git (which I really do not like at all
, it's messy to carry upon dev shoulders a bunch of command aliases
just to do simple operations) there is a git clone (in sync afaics)
already available at https://bitbucket.org/mlopezqc/brython-git and
pull requests may be managed (in bitbucket) for both hg and git repos
.

What's the real benefit of moving onto github ? I see none . People
willing to contribute to the project can fork it / work on it / submit
pull requests / etc ... Indeed I do see using github as a barrier .

--
Regards,

Olemis - @olemislc

Apache(tm) Bloodhound contributor
http://issues.apache.org/bloodhound
http://blood-hound.net

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

[Olemis Lang]

On 9/4/14, Kiko <kikoco...@gmail.com> wrote:
> 2014-09-04 16:15 GMT+02:00 Billy Earney <billy....@gmail.com>:
>

[...]

>>
>> I also wonder if we should create a brython foundation who's mission is
>> to
>> promote brython. I believe Pierre is taking on the cost of the
>> brython.info website. Should we help with that burden?
>>
>
> I could create a mirror of Brython.info, I could host
> speed.brython.info,...
> IF I can help in this sense just let me know.
>

The bureaucratic burden of running one such "Brython foundation" is
high . Another alternative decision would be to insert Brython in the
context of an existing foundation ... and if you ask me preferably one
such open-source foundation outside the US ( French ? European ? ) .
Why ? Because the OFAC [2]_ laws and regulations impose restrictions
over some people to participate in those US-based "open" foundations
[1]_ [3]_ due to reasons beyond the spirit of free & open source
collaboration . Therefore by doing so this action would lead to
actually banning such persons to interact with the project .

I've never heard of such trouble for institutions based on European
countries . CMIIW

> Some ideas:
>
> -A roadmap detailing where is brython going.

Billy has been been very explicit mentioning some of them in previous messages .

> -Migrate to GitHub. For me it's a Catch-22 situation and I don't like to be
> on GitHub but it is a good marketing tool.

-1 ... already explained in previous messages .
And this position is about moving the main development efforts onto
github . Keeping a clone synchronized and publish it at github as well
is quite possible and straightforward to do . The same holds for
accepting pull requests in both github as well as bitbucket . Indeed
it is so possible that I think I'll be able to get that done by
tomorrow .

> -Proselitism on twitter and other sites. The @Brython3 account is not very
> active.

+1

> -The most experienced Brython developers (Pierre and Billy) could open
> small issues to allow other people help. In Guthub you have tags for issues
> and 'Easy Fix' is one of them. Sometimes I don't know where to start.
>

I'd be very glad to join them but , for job-related reasons , the free
time I had for brython has been consumed by my participation in a
series of MOOCs . I'll do my best to **finally** start contributing
some code soon . Though I think I'll scratch my itches with some
issues by improving some unit tests .

.. [1] http://www.apache.org/licenses/exports/

.. [2] http://en.wikipedia.org/wiki/Office_of_Foreign_Assets_Control

.. [3] http://www.treasury.gov/resource-center/sanctions

[Cyrille Rossant]

Also, although I am not contributing code to the project, I fully support the move to Github. The Github community seems larger and they seem to provide better tools than bitbucket. The traction is better on that side of the world..

 

Git is a pain to use, but, in my opinion, not moving to GitHub is shooting oneself in the foot. That's where the vast majority of the most common open source projects are. The only fact of moving to GitHub is likely to bring you many more users...

[Kiko]

2014-09-12 10:45 GMT+02:00 Cyrille Rossant <cyrille...@gmail.com>:

Also, although I am not contributing code to the project, I fully support the move to Github. The Github community seems larger and they seem to provide better tools than bitbucket. The traction is better on that side of the world..

 

Git is a pain to use, but, in my opinion, not moving to GitHub is shooting oneself in the foot. That's where the vast majority of the most common open source projects are. The only fact of moving to GitHub is likely to bring you many more users...

+1, though git, all that social shit related with github is what can make your project be more visible and popular. And also, some functionality of the platform could be helpful. I don't like git but github is a very interesting option.

[Pierre Quentel]

Le vendredi 12 septembre 2014 10:45:22 UTC+2, Cyrille Rossant a écrit :

Also, although I am not contributing code to the project, I fully support the move to Github. The Github community seems larger and they seem to provide better tools than bitbucket. The traction is better on that side of the world..

 

Git is a pain to use, but, in my opinion, not moving to GitHub is shooting oneself in the foot. That's where the vast majority of the most common open source projects are. The only fact of moving to GitHub is likely to bring you many more users...

I must say I am not enthousiastic about moving to Github : I prefer the Bitbucket look and feel, I have to learn a new version control tool, the existing content on BB (issues, wiki pages, downloads...) will be lost or I'll have to copy/paste, etc.

But most of you (sorry Olemis) think that Brython will be more attractive to Open Source developers and users. This is only a marketing reason, and marketing is evil, but I am going to make a concession...

- Pierre

[Kiko]

2014-09-12 13:47 GMT+02:00 Pierre Quentel <pierre....@gmail.com>:

Le vendredi 12 septembre 2014 10:45:22 UTC+2, Cyrille Rossant a écrit :

Also, although I am not contributing code to the project, I fully support the move to Github. The Github community seems larger and they seem to provide better tools than bitbucket. The traction is better on that side of the world..

 

Git is a pain to use, but, in my opinion, not moving to GitHub is shooting oneself in the foot. That's where the vast majority of the most common open source projects are. The only fact of moving to GitHub is likely to bring you many more users...

I must say I am not enthousiastic about moving to Github : I prefer the Bitbucket look and feel, I have to learn a new version control tool, the existing content on BB (issues, wiki pages, downloads...) will be lost or I'll have to copy/paste, etc.

http://hg-git.github.io/ allos you to work with mercurial on a git repo. I never tested so I can't say more than this.

 

But most of you (sorry Olemis) think that Brython will be more attractive to Open Source developers and users. This is only a marketing reason, and marketing is evil, but I am going to make a concession...

I'm not friend of marketing but, please, have a look at the 'Github' section on this post: http://jakevdp.github.io/blog/2012/09/20/why-python-is-the-last/ Maybe the concession on that is not a bad idea :-)

 

- Pierre

--
You received this message because you are subscribed to the Google Groups "brython" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brython+u...@googlegroups.com.
To post to this group, send email to bry...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/brython/175de882-569d-421f-acd9-d363f54f1312%40googlegroups.com.

[Billy Earney]

I can live with bitbucket or github, but the link kiko gives about github seems impressive.    I do think it is a mistake to have repo's on bitbucket AND github.  Since we only have a given amount of time, I would rather have one good repo site on one of the platforms, than 2 half-assed repo sites.  That could do more harm than good.

To view this discussion on the web visit https://groups.google.com/d/msgid/brython/CAB-sx61Hm_ggEmq2DodazCCNvDBz1GxQsc-NEsNWA9x%2BqtXPBA%40mail.gmail.com.

[Billy Earney]

On Thu, Sep 11, 2014 at 10:30 PM, Olemis Lang <ole...@gmail.com> wrote:

On 9/4/14, Kiko <kikoco...@gmail.com> wrote:
> 2014-09-04 16:15 GMT+02:00 Billy Earney <billy....@gmail.com>:
>
[...]
>>
>> I also wonder if we should create a brython foundation who's mission is
>> to
>> promote brython.  I believe Pierre is taking on the cost of the
>> brython.info website.  Should we help with that burden?
>>
>
> I could create a mirror of Brython.info, I could host
> speed.brython.info,...
> IF I can help in this sense just let me know.
>

The bureaucratic burden of running one such "Brython foundation" is
high . Another alternative decision would be to insert Brython in the
context of an existing foundation ... and if you ask me preferably one
such open-source foundation outside the US ( French ? European ? ) .
Why ? Because the OFAC [2]_ laws and regulations impose restrictions
over some people to participate in those US-based "open" foundations
[1]_ [3]_ due to reasons beyond the spirit of free & open source
collaboration . Therefore by doing so this action would lead to
actually banning such persons to interact with the project .

I've never heard of such trouble for institutions based on European
countries . CMIIW

I'd be fine with this.  I'm in the USA, and I understand the complications.  So a European foundation would be okay with me.  Finding a foundation maybe premature, but I thought I'd bring it up.  It maybe not too early to start looking at options! :)

 

--
You received this message because you are subscribed to the Google Groups "brython" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brython+u...@googlegroups.com.
To post to this group, send email to bry...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/brython/CAGMZAuN9dR4g5o8po9xemcxwfCG9pqtwHJ4ur8Y%2BFDJ%2BVtP2kw%40mail.gmail.com.

[Cyrille Rossant]

I must say I am not enthousiastic about moving to Github : I prefer the Bitbucket look and feel, I have to learn a new version control tool, the existing content on BB (issues, wiki pages, downloads...) will be lost or I'll have to copy/paste, etc.

The search for "migrate bitbucket to github" on google gives a few results that might be of interest. I know that some projects successfully migrated and were able to keep the full history (including issues, wiki, etc.).

[Nicolas Pinault]

Le 12/09/2014 15:06, Cyrille Rossant a écrit :

I must say I am not enthousiastic about moving to Github : I prefer the Bitbucket look and feel, I have to learn a new version control tool, the existing content on BB (issues, wiki pages, downloads...) will be lost or I'll have to copy/paste, etc.

The search for "migrate bitbucket to github" on google gives a few results that might be of interest. I know that some projects successfully migrated and were able to keep the full history (including issues, wiki, etc.).

I also prefer bitbucket. In fact I much prefer mercurial than git.

On the mercurial mailing list, there is a thread where people wonder why github is so popular.
Some say mercurial is missing functionalities compared to git but others say there equivalent functionalities in mercurial.
It seems that the same repository weights much more (bytes) in mercurial. It can be an argument when transferring through the internet.
It seems that github (not git) is more attractive because of some functionalities bitbucket and others do not have.
In conclusion, there is no serious argument for pros and cons.

Bitbucket is a good tool. Maybe github is better. I don't know. But, to my opinion, I don't think migrating from bitbucket to github would make a difference on the number of people investigating time on the development of Brython. I think it is better to spend time working on the development of Brython.

My two cents.

Nicolas

[James Hutchison]

A lot of people have github accounts already. When I saw this was on bitbucket, I was at first concerned that it was no longer maintained just because I hadn't encountered a recent open source project that wasn't on github. BitBucket lets you submit issues anon but you can't comment anon. I'm presuming I can fork a git repo from bitbucket but I haven't tried yet. I'd vote for moving to github, because also from a professional standpoint, people who contribute can easily show off to others their contributions, which can help them land a job. Thus there is more incentive to contribute.

Piloting Brython on a project here's my thoughts:

1. The name needs to change. Might sound silly, but when I see Brython I read that as "Bryan's version of Python". Or rather, it's what some guy name Bryan would name his own version of Python. It put me off from originally looking into this. I think the name needs to entail Py in it somewhere.

2. Brython needs to support all major browsers. Clearly IE has been ignored because brython.info (also, .info should probably become .org or something more legit looking) doesn't even load. Ideally, Brython abstracts all the crap that makes Javascript a pain to work with, including cross-browser issues and other problems. Brython should make solving asynchronous problems easy, which javascript makes unnecessarily difficult.

3. Brython needs template support, and ideally some MVC option. I don't know if anyone has tried Jinja2 or not on it but there are some use cases where templates can make things significantly easier, more intuitive, and more readable than having to mix HTML output in your Python code. I'm not a fan of angularJS but it has some nice features. Unfortunately I couldn't get it to work with Brython.

4. Getting support for step-debugging in Chrome would be ideal. 

Overall though, I'm excited I found this. Imagine native Python support in a browser, and for browsers that don't support it, you can have them use the Brython library as a fall back. Of course, Brython needs to be top quality before that can happen.

[James Hutchison]

Sorry, just noticed a typo:

Brython should make solving asynchronous problems easy, which javascript makes unnecessarily difficult.

Should be:

Brython should make solving synchronous problems easy, which javascript makes unnecessarily difficult.

To give an example, I prefer the requests library to using AJAX. Much less lines of code.

[Nicolas Pinault]

> Brython should make solving synchronous problems easy, which
> javascript makes unnecessarily difficult.
>
>

I was thinking to write about this. This is a good occasion.

I will take ajax as an example.
When one read the brython ajax documentation, one can see that all ajax
JS API is usable with brython. There is also a use example. Good.
So what ? What's the benefit of using brython ? Python syntax. What else
? Nothing. One still have to deal with callbacks and all the stuff.
As a python programmer I though there is an abstract layer on top of the
raw API to get a python way of using ajax.

So I have written a small wrapper :

class AjaxRequest():
def __init__(self, url):
self.url=url
self.ajax_timeout = 4
self.ajax_answer = 'None'

def _on_complete(self, req):
if req.status==200 or req.status==0:
self.ajax_answer = req.text
else:
self.ajax_answer = "error "+req.text

def _err_msg(self):
self.ajax_answer = "server didn't reply after %s seconds" %
ajax_timeout

def post(self, **params):
req = ajax()
req.on_complete = self._on_complete
req.set_timeout(self.ajax_timeout, self._err_msg)
req.open('POST', self.url, False)
req.set_header('content-type','application/x-www-form-urlencoded')
req.send(params)
return self.ajax_answer


A small use example :

from ajax_request import AjaxRequest

ar = AjaxRequest("/Activation.py/click_ajax")

def click_led(number, this):
#print('set_led = %d' % number, this)
this.src='/Images/LedChange.svg'
led = ar.post(number=number)
led = int(led)
if led :
this.src='/Images/LedOn.svg'
else :
this.src='/Images/LedOff.svg'


With a simple class wrapper, using ajax is pythonic so it is simple.

I believe it is possible to do the same with other APIs.

I think this higher level API should be in brython. Or at least, it
should be in a recipe section of the documentation site.

Regards,
Nicolas

I

[Kiko]

Nicolas, the problem with this approach it is that brython.js or the
stdlib will start to grow and this is not very good in a browser
environment. Also, now you can look for a lot of js docs but in
Brython, if the official or maintainers docs are not very helpful then
the lib would be less useful.

> --
> You received this message because you are subscribed to the Google Groups
> "brython" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to brython+u...@googlegroups.com.
> To post to this group, send email to bry...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/brython/5413FC2C.9030001%40famillepinault.fr.

[Nicolas Pinault]

Le 13/09/2014 10:58, Kiko a écrit :
> Nicolas, the problem with this approach it is that brython.js or the
> stdlib will start to grow and this is not very good in a browser
> environment. Also, now you can look for a lot of js docs but in
> Brython, if the official or maintainers docs are not very helpful then
> the lib would be less useful.

There is no problem with stdlib size. If you don't import the high level
lib, you don't suffer an extra cost in size.
Of course, documentation has to be written for such modules.
I really think brython must have such functionalities to gain in popularity.

[Pierre Quentel]

Le samedi 13 septembre 2014 04:44:38 UTC+2, James Hutchison a écrit :

A lot of people have github accounts already. When I saw this was on bitbucket, I was at first concerned that it was no longer maintained just because I hadn't encountered a recent open source project that wasn't on github. BitBucket lets you submit issues anon but you can't comment anon. I'm presuming I can fork a git repo from bitbucket but I haven't tried yet. I'd vote for moving to github, because also from a professional standpoint, people who contribute can easily show off to others their contributions, which can help them land a job. Thus there is more incentive to contribute.

Piloting Brython on a project here's my thoughts:

1. The name needs to change. Might sound silly, but when I see Brython I read that as "Bryan's version of Python". Or rather, it's what some guy name Bryan would name his own version of Python. It put me off from originally looking into this. I think the name needs to entail Py in it somewhere.

I am ready to change many things in Brython, but not the name. It stands for "browser python", and it means Breton in Welsh - you can't defeat this argument with me ;-)

2. Brython needs to support all major browsers. Clearly IE has been ignored

Right, and thank you for the fix. It just happens that my PCs are still on Windows XP so I'm stuck with IE8, which is obviously not supported
 

because brython.info (also, .info should probably become .org or something more legit looking)

I wish I could have used brython.org or brython.net or brython.com, but they were already owned when I created the project
 

[Olemis Lang]

I'll complement Pierre's response with my own opinions .

On 9/15/14, Pierre Quentel <pierre....@gmail.com> wrote:
>
> Le samedi 13 septembre 2014 04:44:38 UTC+2, James Hutchison a écrit :
>>
>> A lot of people have github accounts already. When I saw this was on
>> bitbucket, I was at first concerned that it was no longer maintained just
>>
>> because I hadn't encountered a recent open source project that wasn't on
>> github. BitBucket lets you submit issues anon but you can't comment anon.
>>

<rant> With all respect , this is a peculiar way of thinking ; it's
like saying New York is the city , everything else is just country
side . I don't buy your arguments . </rant>

... but it's useless to start that flamewar , the migration's already happened .

>> I'm presuming I can fork a git repo from bitbucket

I honestly do not know what would be the point of the company for
running bitbucket otherwise . Creating a new fork (among other
features) is an obvious option ...

>> but I haven't tried
>> yet.

jftr

https://confluence.atlassian.com/.../BITBUCKET/Forking+a+Repository
https://confluence.atlassian.com/.../BITBUCKET/Fork+a+Repo,+Compare+
Code,+and+Create+a+Pull+Request

>> I'd vote for moving to github, because also from a professional
>> standpoint,
>> people who contribute can easily show off to others their contributions,
>> which can help them land a job. Thus there is more incentive to
>> contribute.
>>

... no further comments ...

>> Piloting Brython on a project here's my thoughts:
>>
>> 1. The name needs to change. Might sound silly, but when I see Brython I
>> read that as "Bryan's version of Python". Or rather, it's what some guy
>> name Bryan would name his own version of Python. It put me off from
>> originally looking into this. I think the name needs to entail Py in it
>> somewhere.
>>
>
> I am ready to change many things in Brython, but not the name. It stands
> for "browser python", and it means Breton in Welsh - you can't defeat this
> argument with me ;-)
>

+1 ... many languages out there

> 2. Brython needs to support all major browsers. Clearly IE has been ignored
>
> Right, and thank you for the fix. It just happens that my PCs are still on
> Windows XP so I'm stuck with IE8, which is obviously not supported
>

+1 ... versions of MSIE are generally broken , so I really have little
time to struggle with them .

<joke> I'd rather prefer to show a warning message saying "You are
using an unsupported browser . Please use a real browser ." </joke>

... but yes , it's an important feature for users . Should someone be
motivated to write patches to improve this , of course they'll be more
than welcome .

[...]

>> doesn't even load. Ideally, Brython abstracts all the crap that makes
>> Javascript a pain to work with, including cross-browser issues and other
>> problems. Brython should make solving asynchronous problems easy, which
>> javascript makes unnecessarily difficult.
>> 3. Brython needs template support, and ideally some MVC option. I don't
>> know if anyone has tried Jinja2 or not on it but there are some use cases
>>
>> where templates can make things significantly easier, more intuitive, and
>>
>> more readable than having to mix HTML output in your Python code. I'm not
>> a
>> fan of angularJS but it has some nice features. Unfortunately I couldn't
>> get it to work with Brython.

I honestly think that Brython goals should be limited to

1. Python interpreter powered by js
2. Maximize language compatibility
3. Library imports for extensibility
4. Maximize stdlib support and compatibility
5. Foundations for interop with js + DOM

Anything else (unless I've missed something important of course)
should be implemented beyond the boundaries of brython itself as a
library (see §3) . All of this mainly due to practical reasons

IMHO templating is beyond the scope of Brython as a project , but may
be implemented as a separate module to be imported in real projects .

>> 4. Getting support for step-debugging in Chrome would be ideal.
>>

+1

>> Overall though, I'm excited I found this.

\o/

[...]

[Billy Earney]

+1 on this comment by Olemis....

I honestly think that Brython goals should be limited to

1. Python interpreter powered by js
2. Maximize language compatibility
3. Library imports for extensibility
4. Maximize stdlib support and compatibility
5. Foundations for interop with js + DOM

Anything else (unless I've missed something important of course)
should be implemented beyond the boundaries of brython itself as a
library (see §3) . All of this mainly due to practical reasons

--
You received this message because you are subscribed to the Google Groups "brython" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brython+u...@googlegroups.com.
To post to this group, send email to bry...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/brython/CAGMZAuMFSUB92%3DW9HMDxgG5skSScJsR%3DR-1_ncmqPSP-2-YXNw%40mail.gmail.com.

[James Hutchison]

brython.rocks is available. Only $7.88 USD / year on namecheap.com :)

[Pierre Quentel]

How much is brython.sucks ? ;-)

[Carl Smith]

On Monday, 15 September 2014 07:49:16 UTC+1, Olemis Lang wrote:

I'll complement Pierre's response with my own opinions .

On 9/15/14, Pierre Quentel <pierre....@gmail.com> wrote:
>
> Le samedi 13 septembre 2014 04:44:38 UTC+2, James Hutchison a écrit :
>>
>> A lot of people have github accounts already. When I saw this was on
>> bitbucket, I was at first concerned that it was no longer maintained just
>>
>> because I hadn't encountered a recent open source project that wasn't on
>> github. BitBucket lets you submit issues anon but you can't comment anon.
>>

<rant> With all respect , this is a peculiar way of thinking ; it's
like saying New York is the city , everything else is just country
side . I don't buy your arguments . </rant>

... but it's useless to start that flamewar , the migration's already happened .

>> I'm presuming I can fork a git repo from bitbucket

I honestly do not know what would be the point of the company for
running bitbucket otherwise . Creating a new fork (among other
features) is an obvious option ...

>> but I haven't tried
>> yet.

jftr

Personally -> If a project's not on GitHub, it's not important. GitHub is where open source happens. Google Code is dead, and BitBucket is just some second-rate crap that massive corporations use because GitHub's highly successful, anarchistic ethos undermines their rational for treating their own staff like property. 

[Christophe Bal]

>>> BitBucket is just some second-rate crap that massive corporation...

Not so simple. I use BitBucket for in progress stuffs that I do not want yet to be visible by others. For example, I'm writing a book about SageMathCloud. This book will be free but for the moment I do not want anyone to access to it.

I also use BitBucket for my teaching work so as to store infos about my lessons like date of tests, work done with my students... All of this accessible by anyone wouldn't makes sense.

For other projects, I use github so as to be visible and also because I find git very easy to use.

Sorry for this noisy answer. ;-)

--

You received this message because you are subscribed to the Google Groups "brython" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brython+u...@googlegroups.com.
To post to this group, send email to bry...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/brython/142671de-80a7-44aa-b18f-07c002fb1df5%40googlegroups.com.

[Carl Smith]

On Tuesday, 30 September 2014 08:18:55 UTC+1, Christophe Bal wrote:

>>> BitBucket is just some second-rate crap that massive corporation...

Not so simple. I use BitBucket for in progress stuffs that I do not want yet to be visible by others. For example, I'm writing a book about SageMathCloud. This book will be free but for the moment I do not want anyone to access to it.

I also use BitBucket for my teaching work so as to store infos about my lessons like date of tests, work done with my students... All of this accessible by anyone wouldn't makes sense.

For other projects, I use github so as to be visible and also because I find git very easy to use.

Fair enough. I was just having a fun, little rant, in kind. Now I've read my comment back, it seems a bit much. Sorry.

[Dan Stromberg]

On Mon, Sep 29, 2014 at 4:51 PM, Carl Smith <carl....@gmail.com> wrote:
> Personally -> If a project's not on GitHub, it's not important. GitHub is
> where open source happens. Google Code is dead, and BitBucket is just some
> second-rate crap that massive corporations use because GitHub's highly
> successful, anarchistic ethos undermines their rational for treating their
> own staff like property.

github is becoming a dangerous monoculture. There need to be other options.

The opensource community usually shuns single-sourced necessities.
Why is github any different?

[Carl Smith]

github is becoming a dangerous monoculture.  There need to be other options.

The opensource community usually shuns single-sourced necessities.
Why is github any different?

It's not, but it's raised the bar: https://about.gitlab.com/ 

[Dirk Krause]

Gitlab is not Github, it is an open source clone of Github IIRC.
Interestingly enough the source was also hosted on Github before, but now they seem to have started their own service.

[Petros Moisiadis]

Hello,

I would like to share my thoughts on what should happen to help Python thrive in the browser world. I see three basic requirements:

• Actively maintain a production-ready Python implementation for the browsers:
• Brython seems to be the most promising project, but it needs improvements on these aspects:
• Standardization
• improve compatibility with CPython
• standardization for the browser-specific interface and modules
• promise of API stability 
• Documentation:
• use sphinx or mkdocs
• use docs.python.org as a guide for structure and content
• add more content
  
• Speed:
• More optimizations (there is good progress on this)
• Production tools:
• Out-of-browser compiler
• Developer tools:
• Debugger at python/brython level
• Support from PSF and/or other organizations:
• Bring and support more developers
• Promotion
• Better logo

•  Create and actively maintain a full-featured, all-batteries-included web frontend application framework in Python:
• A pythonic Angular (could be a port: Angular.py) or a "django for the frontend" project

• Bring big players and browser vendors into the game:
• Google, Mozilla
• Native implementations of python in the browser

Brython is very promising in fulfilling the first requirement and surely more resources and time is needed to spend on it.

The second requirement is a very ambitious one, and it needs some standardization / stabilization to take place first at the browser interface implementation. Difficult but possible. Even at its start, a project like that would attract a lot of python developers.

The third requirement however is the most difficult. Truth be told, no web technology is going to succeed if at least one big name does not push it for his own good. Unfortunately, although it has great man power with strong python background, Google chose a different path and implemented dart as a 'better-than-javascript' language for the web (which borrows some ideas from Python). So, I wonder if Mozilla could find any potential in supporting Python in the browser as a "better-than-javascript" language which is far more widely deployed and mature than dart. On the other hand, there is much more buzz in making javascript better (with new standards) than just replacing it.

[Carl Smith]

Hi Petros. I spent a couple of years doing Python in the browser, so your post was really interesting.

On Sunday, 5 October 2014 11:49:13 UTC+1, Petros Moisiadis wrote:

Hello,

I would like to share my thoughts on what should happen to help Python thrive in the browser world. I see three basic requirements:

• Actively maintain a production-ready Python implementation for the browsers:

All your points on this requirement seem reasonable, and Brython is chipping away at them.

•  Create and actively maintain a full-featured, all-batteries-included web frontend application framework in Python:
• A pythonic Angular (could be a port: Angular.py) or a "django for the frontend" project

This would be interesting, if it can be done well. It would stand as a good example of how well Brython works. I fear it would actually highlight more problems than you expect though.

• Bring big players and browser vendors into the game:
• Google, Mozilla
• Native implementations of python in the browser

This has been done. FireFox did some stuff with Python, but it didn't take off, and you can run Python2.7 and 3.4 in Chrome on PNaCl. In practice, it doesn't work very well. Python has no ecosystem for the browser and doesn't play nice with JavaScript, so you need to reimplement, let's say, jQuery, else you're stuck with the raw DOM in Python. And Python absolutely sucks at event oriented [ergo GUI] programming. Having to define a function before you can use it in an expression... there's issues with Python once you get it working.

Personally, I think Brython has fundamental issues that need to be fixed before it can be taken seriously. If it had simple bindings for major libraries, if it introduced real lambdas, whether CPython has them or not, that kind of thing, it could convince the world that Python could work in the browser. Because these issues are not really important to Brython, it does feel like Brython is just an indulgent, fun little project for Python hackers. No harm in that, but it isn't going to get support from the Web community with that reputation.