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

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

Re: [ann] pyjamas 0.8alpha1 release

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [ann] pyjamas 0.8alpha1 release Terry Reedy <tjreedy@udel.edu> - 2011-05-04 14:37 -0400
    Re: pyjamas 0.8alpha1 release lkcl <luke.leighton@gmail.com> - 2011-05-17 09:07 -0700
      Re: pyjamas 0.8alpha1 release Terry Reedy <tjreedy@udel.edu> - 2011-05-17 21:33 -0400
        Re: pyjamas 0.8alpha1 release lkcl <luke.leighton@gmail.com> - 2011-05-18 02:24 -0700
          Re: pyjamas 0.8alpha1 release lkcl <luke.leighton@gmail.com> - 2011-05-18 06:35 -0700
          Re: pyjamas 0.8alpha1 release Terry Reedy <tjreedy@udel.edu> - 2011-05-18 18:02 -0400
            Re: pyjamas 0.8alpha1 release lkcl <luke.leighton@gmail.com> - 2011-05-19 06:17 -0700
    Re: [ann] pyjamas 0.8alpha1 release harrismh777 <harrismh777@charter.net> - 2011-05-17 11:38 -0500
      Re: [ann] pyjamas 0.8alpha1 release Terry Reedy <tjreedy@udel.edu> - 2011-05-17 21:52 -0400
        Re: [ann] pyjamas 0.8alpha1 release harrismh777 <harrismh777@charter.net> - 2011-05-18 00:29 -0500
          Re: pyjamas 0.8alpha1 release lkcl <luke.leighton@gmail.com> - 2011-05-18 02:39 -0700
      Re: pyjamas 0.8alpha1 release alex23 <wuwei23@gmail.com> - 2011-05-17 22:54 -0700
      Re: pyjamas 0.8alpha1 release lkcl <luke.leighton@gmail.com> - 2011-05-18 06:42 -0700
        Re: pyjamas 0.8alpha1 release Terry Reedy <tjreedy@udel.edu> - 2011-05-18 21:13 -0400
          python2+3 lkcl <luke.leighton@gmail.com> - 2011-05-19 05:42 -0700
            Re: python2+3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-19 22:40 +0000

#4643 — Re: [ann] pyjamas 0.8alpha1 release

On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote:
> after a long delay the pyjamas project - http://pyjs.org - has begun the
> 0.8 series of releases, beginning with alpha1:
>
> https://sourceforge.net/projects/pyjamas/files/pyjamas/0.8/
>
> pyjamas is a suite of projects, including a python-to-javascript
> compiler

As you well know, there is no such thing as 'python' when it comes to 
compiling actual code. So please specify both in announcements here and 
on the project homepage http://sourceforge.net/projects/pyjamas/
which versions are supported. I do not really want to have to download 
and experiment to determine whether to bother downloading.

If you do not yet support 3.x, I request and recommend that you do so, 
even if only on Windows with comtypes. Since comtypes uses ctypes, I 
presume it works fine with Python 3 (this is one major advantage of 
using ctypes.)

Like it or not, Python 3 is the future of Python. It is the Python that 
many Python newcomers learn first, and perhaps ever will. Such students 
usually have no experience or loyalty to any other GUI package, and I am 
sure that many would love to be able to develop apps that they can run 
on their desktop, give to friends to run in a browser, and run on their 
phones.

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#5573 — Re: pyjamas 0.8alpha1 release

On May 4, 7:37 pm, Terry Reedy <tjre...@udel.edu> wrote:
> On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote:
>
> > after a long delay thepyjamasproject -http://pyjs.org- has begun the
> > 0.8 series of releases, beginning with alpha1:
>
> >https://sourceforge.net/projects/pyjamas/files/pyjamas/0.8/
>
> >pyjamasis a suite of projects, including a python-to-javascript
> > compiler
>
> As you well know, there is no such thing as 'python' when it comes to
> compiling actual code. So please specify both in announcements here and
> on the project homepagehttp://sourceforge.net/projects/pyjamas/
> which versions are supported. I do not really want to have to download
> and experiment to determine whether to bother downloading.
>
> If you do not yet support 3.x, I request and recommend that you do so,

 with the situation as it is, there is not a snowball in hell's chance
that's going to happen.

 allow me to explain.

 the python translator in pyjamas is heavily dependent on the
"compiler" module (which is written in c) and is in turn, as you are
no doubt aware, specifically dependent on the grammar file.  the
python translator for pyjamas 0.3 was 1,200 lines of code.  thanks to
some brilliant and dedicated work by kees bos, over something like a 6
month virtually full-time period, it's now somewhere around 5,000
lines of heavily-dense code in which very specific javascript
optimisations have been encoded.

 then, on top of that, it is necessary to implement the data types
that are supported in python 3.x, along with several built-ins
(exceptions etc.).  the basic implementation - pyjslib.py - is 6,700
lines of python code with in-built hand-optimised javascript, and it
would be necessary to reimplement / re-work... and then support...
that reimplementation.

 then, on top of that, there are a number of python-based
reimplementations of various python modules, such as md5.py, re.py,
string.py and so on, each of which would have to be double-checked for
compatibility with their python 3.x counterparts.  do they exist, have
they been rewritten, modified etc.`

 then, on top of that, it is necessary to run the pyjamas UI code,
which is some 15,000 lines of code, along with the other libraries
such as GChart, through lib2to3, and then to double-check them.

 then, on top of that, it is necessary to run the examples - of which
there are 70 - again through lib2to3.  i've just done a "wc" on the
examples source code: it comes to a whopping total of 60,000 lines of
code.

 so you have to do all this work, and really it's impossible to begin
realistically checking that it works until you get to the LibTest
example (which is the main test suite, comprising some 3,000 or so
regression tests), and once you've done all that work you now need a
userbase and also some maintainers.

 and, when it comes to doing a release, you need to test all 70
examples in a matrix of 14 browsers plus 4 desktop runtime engines,
and the browsers you need to recompile three times - with -O
(optimised), --strict (python-compliant) and there's one more, i
forget its name, it's designed to minimise the amount of javascript
generated.

 to support 3.x therefore requires a complete and utter rewrite, and
then a hell of a lot of work on top of that.  it's basically
supporting a totally separate language, and so is basically a
completely new project.  i know you mean well, but... you've
drastically underestimated quite how much effort has gone into the
pyjamas project - just look at the ohloh statistics for goodness sake!
it's listed as having had 31 man-years gone into it! http://www.ohloh.net/p/pyjamas

 so if you can find the money to get people paid to create a python
3.x to javascript compiler, which will require approximately twelve to
fifteen man-months of full-time dedicated programming effort, please
do speak up!

 otherwise please - really: just saying "give me support for python
3.x or else" is ... honestly - it's a free software project, _not_ a
paid-up corporate google/nokia/ibm/redhat/etc. funded project: you
know the score, and you know the drill.

 now.

 leaving _that_ aside, there happens to be absolutely no really good
compelling reason to support python 3.x in the first place.  "python 3
is the future of python" gimme a break!! [so why is archlinux the only
linux distribution that's converted over to run everything off of
python 3.x?]

 the thing is: there aren't really any major dependencies to "get in
the way" in pyjs.  as in: it's entirely self-sufficient [it has to
be].  even the installation has its own sandbox system.  the only
dependency *is* python 2.N, and when daniel kluev completes his
GSoC2011 project, that'll be a "bootstrap" into javascript, including
the translator itself being compiled into javascript, and then not
even python 2.N will be a dependency!

 the bottom line is this: somewhere in the next 8 to 10 years, python
2.N will be deprecated in all but the most die-hard places.  at *that*
time, it will have been worthwhile to convert pyjamas over to python
3.N - and probably not even then would it be strictly necessary.

 the only really compelling reason would be if it became difficult for
the pyjamas-desktop engines to be compiled for python 2.  that's
MSHTML (python-comtypes for python 2 disappearing or being hard to
get) - i'm the maintainer of the pyjd/mshtml.py engine so that'll be
around for a long time; pythonwebkit (again, i'm the maintainer, so
that'll be around for a long time) and xulrunner / python-xpcom and
python-hulahop (python-xpcom is maintained by activestate.com).

 so - if it becomes "difficult" to get hold of all the pyjd engines,
*then* and *only* then does it make sense to look at converting to
python 3.  i seriously, seriously doubt that pythonwebkit, python-
comtypes or python-xpcom for python 2 are going to disappear within
the next 5 years, don't you?

l.

p.s. if you _really_ want to use python 3 with pyjs, then run the pyjs
translator code through lib2to3, and then make damn sure that you use
the "--internal-ast" option when compiling [this is what is
recommended for people who use python 2.4, or 2.7 and above.  one
minor change and we might even be able to support python 2.3 or
below].  you will then use the (duh) internal AST code in pyjs, and
will *still* need to write pyjamas applications that are in python 2.N
syntax, because that's what the pyjs translator supports.  but you
will at least not require an http://python.org version 2.N
interpreter.

p.p.s for anyone who might be interested, the --internal-ast code sort-
of came from the lib2to3 project, and was used to create a module
which is entirely compatible with the standard http://python.org
version 2.0 "compile" module and the ast module.  except that it
supports the features of lib2to3 which include line and character
numbers.

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

#5640 — Re: pyjamas 0.8alpha1 release

On 5/17/2011 12:07 PM, lkcl wrote:
> On May 4, 7:37 pm, Terry Reedy<tjre...@udel.edu>  wrote:
>> On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote:
>>> pyjamasis a suite of projects, including a python-to-javascript
>>> compiler

>> As you well know, there is no such thing as 'python' when it comes to
>> compiling actual code. So please specify both in announcements here and
>> on the project homepagehttp://sourceforge.net/projects/pyjamas/
>> which versions are supported.

 > [no response]

I would still like to know. Do you fully support 2.7? It has many of the 
same changes that are in 3.1 and even 3.2 so I can imagine it would be 
difficult.

>> If you do not yet support 3.x, I request and recommend that you do so,
>
> with the situation as it is, there is not a snowball in hell's chance
> that's going to happen. allow me to explain.

Thank you for the explanation. You are right that I probably 
underestimated the work, though you have or will do some of what is 
needed to fully support 2.7.

...
>   otherwise please - really: just saying "give me support for python
> 3.x or else" is ...

And I did not say that. I first learned Python with 1.3 and could again 
write 2.x code if motivated.

...
>   leaving _that_ aside, there happens to be absolutely no really good
> compelling reason to support python 3.x in the first place.

Depend on who *you* want to target as users. *Your* choice, of course.

> "python 3 is the future of python" gimme a break!!

Let's discuss that in a couple of years.

> [so why is archlinux the only linux distribution that's converted
 > over to run everything off of python 3.x?]

Because being first is their thing.

-- 
Terry Jan Reedy

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

#5676 — Re: pyjamas 0.8alpha1 release

On May 18, 2:33 am, Terry Reedy <tjre...@udel.edu> wrote:

> On 5/17/2011 12:07 PM, lkcl wrote:
>
> > On May 4, 7:37 pm, Terry Reedy<tjre...@udel.edu>  wrote:
> >> On 5/4/2011 10:06 AM, Luke Kenneth Casson Leighton wrote:
> >>> pyjamasis a suite of projects, including a python-to-javascript
> >>> compiler
> >> As you well know, there is no such thing as 'python' when it comes to
> >> compiling actual code. So please specify both in announcements here and
> >> on the project homepagehttp://sourceforge.net/projects/pyjamas/
> >> which versions are supported.
>
>  > [no response]
>
> I would still like to know. Do you fully support 2.7? It has many of the
> same changes that are in 3.1 and even 3.2 so I can imagine it would be
> difficult.

 sorry, terry, missed this out.  there are two answers:

 a) at the moment a http://python.org 2.N interpreter is required to
actually run the translator.  if you use http://python.org 2.5 or 2.6
you do not need to use the "--internal-ast" option.  if you use 2.4,
2.7 or above, you will need to use --internal-ast because we're
heavily reliant on the internal c-based "compile" module [without the
--internal-ast option enabled].

 b) the actual pyjs interpreter grammar (AST) was 2.5 but has mostly
been updated to 2.6.  actual python syntax / features are therefore
mostly 2.5, with someone having pointed out that "slice" has different
return results it's hard to say exactly which is best to be picked,
2.5 or 2.6.  nobody's needed slice until recently, so it's not an
issue that's ever come up before.

 the thing is - it's worth reiterating: you just... really don't need
as much python interoperability for user-interfaces when they're split
along MVC lines.  bear in mind that it's necessary to do that split:
it's web browser technology, you can't *actually* execute things like
psycopg or mysql in a web browser as javascript!  so once you've
divided that application into "python that runs the actual user
interface" and "python on the other side of the AJAX barrier e.g. a
django app" you're left with a far smaller task for the pyjs
interpreter to have to tackle.

 this is why it's been so unnecessary to keep absolutely up-to-date
with the full python development that's been going on, yet we still
have people developing 10,000+ LOC 2 man-year pyjamas projects.

 that having been said, there _is_ the requirement to be "python
strict" as well as "fast" - mutually exclusive of course.  and there
is someone working on getting the pyjs compiler and supporting
libraries into shape in order to run the entire http://python.org
regression test suite.  there really are quite a lot of little sub-
projects within the pyjamas project.


> >> If you do not yet support 3.x, I request and recommend that you do so,
>
> > with the situation as it is, there is not a snowball in hell's chance
> > that's going to happen. allow me to explain.
>
> Thank you for the explanation.

 not a problem.

> You are right that I probably underestimated the work,

 yeah... i apologise for the somewhat-evident flabbergasted tone that
may have been apparent in what could otherwise be considered to be a
project outline / roadmap :)

> though you have or will do some of what is
> needed to fully support 2.7.

 weell... see above: it's kiinda unnecessary - it just depends on
people's needs.  if there are intelligent and willing people (like
kees) who just come along and go "yep, that's nice, but it's not good
enough for me: i'm going to make it so" then it'll happen.  everyone
else _not_ willing to put in the effort to make pyjs do what they want
will just have to put up with the foibles.

 so if someone wants to do it, hell i'm not going to stand in the way
- anyone who asks i give them commit rights, point them at the
DEVELOPER.RULES and let them get on with it.

> ...
>
> >   otherwise please - really: just saying "give me support for python
> > 3.x or else" is ...
>
> And I did not say that.

 yeah i know - i'm sorry: it just, with a little bit of "twisting",
could be construed as implying that.

> > "python 3 is the future of python" gimme a break!!
>
> Let's discuss that in a couple of years.

 :)  i think... people forget that there are now two mutually-
exclusively-incompatible programming languages out there, where the
first six letters of the name of the programming language happen to be
the same...

l.

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

#5694 — Re: pyjamas 0.8alpha1 release

On May 18, 10:24 am, lkcl <luke.leigh...@gmail.com> wrote:

> > >   otherwise please - really: just saying "give me support for python
> > > 3.x or else" is ...
>
> > And I did not say that.
>
>  yeah i know - i'm sorry: it just, with a little bit of "twisting",
> could be construed as implying that.

 in case it wasn't clear, i apologise for doing that :)

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

#5747 — Re: pyjamas 0.8alpha1 release

On 5/18/2011 5:24 AM, lkcl wrote:

There seem to be two somewhat separate requirement issues: the 
interpreter binary and the language version.

>   a) at the moment a http://python.org 2.N interpreter is required to
> actually run the translator.  if you use http://python.org 2.5 or 2.6
> you do not need to use the "--internal-ast" option.  if you use 2.4,
> 2.7 or above, you will need to use --internal-ast because we're
> heavily reliant on the internal c-based "compile" module [without the
> --internal-ast option enabled].

I presume '--internal-ast' is a 'compile the interpreter' option. Since 
I have never compilied Python (or anything else for perhaps 15 years), I 
do not understand completely. Am I correct to guess that the PSF Windows 
binaries for 2.7 were not compiled with the flag, and will not work? If 
so, Windows users should, I would think, use the latest 2.6.6 binaries.

>   b) the actual pyjs interpreter grammar (AST) was 2.5 but has mostly
> been updated to 2.6.  actual python syntax / features are therefore
> mostly 2.5, with someone having pointed out that "slice" has different
> return results it's hard to say exactly which is best to be picked,
> 2.5 or 2.6.  nobody's needed slice until recently, so it's not an
> issue that's ever come up before.

If I understand this, the safe thing to do is to stick with 2.5 syntax 
and omit exotic 3.x features put into 2.6 for eventual porting to 3.x.

>   the thing is - it's worth reiterating: you just... really don't need
> as much python interoperability for user-interfaces when they're split
> along MVC lines.  bear in mind that it's necessary to do that split:
> it's web browser technology, you can't *actually* execute things like
> psycopg or mysql in a web browser as javascript!  so once you've
> divided that application into "python that runs the actual user
> interface" and "python on the other side of the AJAX barrier e.g. a
> django app" you're left with a far smaller task for the pyjs
> interpreter to have to tackle.

I do not get all this but it seems to say that I do not really need all 
the features of the later Pythons to write user-interface code. But I am 
not sure how this applies to business code behind the front end. Of 
course, it might work to run the UI in a separate process if on the same 
machine.

>>>    otherwise please - really: just saying "give me support for python
>>> 3.x or else" is ...
>>
>> And I did not say that.
>
>   yeah i know - i'm sorry: it just, with a little bit of "twisting",
> could be construed as implying that.

Let me be clear: some people think that free (as in beer) software 
developers have some sort of one-sided responsibility or obligation to 
users who pay nothing. I don't. If I say "Give me a Python 3 version of 
pyjamas or I will not use it", I consider you free to respond "Fine, 
don't use it." End of story until I compromise or contribute. I feel 
free to say the same to anyone who says "Stop developing new versions of 
Python or I will quit using the current version".

>   :)  i think... people forget that there are now two mutually-
> exclusively-incompatible programming languages out there, where the
> first six letters of the name of the programming language happen to be
> the same...

Something of an exaggeration. It might well be possible to use a 3to2 
frontend and run a mildly restricted subset of 3.x.

-- 
Terry Jan Reedy

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

#5776 — Re: pyjamas 0.8alpha1 release

On May 18, 11:02 pm, Terry Reedy <tjre...@udel.edu> wrote:
> On 5/18/2011 5:24 AM, lkcl wrote:
>
> There seem to be two somewhat separate requirement issues: the
> interpreter binary and the language version.

 yes.  [with the startling possibility of compiling the entire pyjs
compiler into javascript and executing under e.g. spidermonkey's /usr/
bin/js turning that into just the one requirement - but that's another
story]

> >   a) at the moment ahttp://python.org2.N interpreter is required to
> > actually run the translator.  if you usehttp://python.org2.5 or 2.6
> > you do not need to use the "--internal-ast" option.  if you use 2.4,
> > 2.7 or above, you will need to use --internal-ast because we're
> > heavily reliant on the internal c-based "compile" module [without the
> > --internal-ast option enabled].
>
> I presume '--internal-ast' is a 'compile the interpreter' option.

 mmm... sort of.  what it does is, in translator.py (the pyjs python-
to-javascript compiler) is this:

 if options.internal_ast:
     import pyjamas.pgen.compile as compile # python version of
compile module
 else:
     import compile # standard python compile module

 that "internal" compile module contains a complete independent
grammar.txt file, and is basically lib2to3 re-ported *back* to being
interoperable with, and a complete replacement for, the standard
python "compile" module.  including the ast module.

 we haven't *quite* got round to doing a "compile the interpreter" yet
- it's half way there.  the work that daniel kluev is doing, for his
gsoc2011 project, will be a complete "compile the interpreter".

 by the time he's done, we'll even have "eval()" and "exec()"
builtins... inside a web browser.

> Since
> I have never compilied Python (or anything else for perhaps 15 years), I
> do not understand completely. Am I correct to guess that the PSF Windows
> binaries for 2.7 were not compiled with the flag, and will not work? If
> so, Windows users should, I would think, use the latest 2.6.6 binaries.

 ahh... i'm reading this as "requiring http://python.org c code to be
compiled with different compilation flags".  this isn't anything to do
with compiling c-code: "pyjs the translator" is and always will be a
pure vanilla python application, requiring absolutely no modifications
to the python interpreter whatsoever.

 the --internal-ast option is an option which is passed to the pyjs
application (which is a pure and vanilla python application).  here's
an example, shows the inter-relationships:

 /usr/bin/python pyjsbuild.py --internal-ast Hello.py
 python.exe pyjsbuild.py --internal-ast Hello.py

 * /usr/bin/python or python.exe - python2.N.

 * pyjsbuild.py - the pyjs python-to-javascript translator

 * --internal-ast - an option to pyjsbuild to tell it to use a version
of compiler.ast which is written in pure python [and supports the 2.6
grammar]

 * Hello.py - the pyjamas application, written in python, being
translated to javascript, for execution in a web browser.


> >   b) the actual pyjs interpreter grammar (AST) was 2.5 but has mostly
> > been updated to 2.6.  actual python syntax / features are therefore
> > mostly 2.5, with someone having pointed out that "slice" has different
> > return results it's hard to say exactly which is best to be picked,
> > 2.5 or 2.6.  nobody's needed slice until recently, so it's not an
> > issue that's ever come up before.
>
> If I understand this, the safe thing to do is to stick with 2.5 syntax
> and omit exotic 3.x features put into 2.6 for eventual porting to 3.x.

 yes.  that would be the easiest path.  however, we have a teeny
problem: pyjamas desktop (pyjd).  that's where you get to *really*
execute the python code, exactly the same code that you munged through
the pyjs compiler.  in the pyjd case, what is going on is that it is
*python* that has access to the features of the web browser engine
(DOM functions, HTML5 etc.) and that is... ho hum, each engine is
itself a massive project, and has to be a python c module (except for
the MSHTML engine, which is COM).

 so for pyjd, we *have* to support whatever the latest easiest python
2.N is.  that in turn dictates that we have to keep up-to-date with
the python 2.N syntax/grammar, and, consequently, it dictates
logically that the pyjs compiler, which *must* be interoperable with
pyjd, must also support the latest python 2.N syntax/grammar.

 bummer, huh? :)

 fortunately, nobody on the pyjamas mailing list has really noticed
that there _are_ any differences (!) between 2.5, 6 and 7 - except for
daniel kluev, the gsoc2011 student, who is using pyjs with python-pyv8
to actually create a version of a python interpreter... by translating
everything to javascript!

 the reason why they haven't really noticed is because the use-case
for pyjamas UI code is much much smaller (due to web browsers being a
restricted execution environment - see ongoing discussion below).

> >   the thing is - it's worth reiterating: you just... really don't need
> > as much python interoperability for user-interfaces when they're split
> > along MVC lines.  bear in mind that it's necessary to do that split:
> > it's web browser technology, you can't *actually* execute things like
> > psycopg or mysql in a web browser as javascript!  so once you've
> > divided that application into "python that runs the actual user
> > interface" and "python on the other side of the AJAX barrier e.g. a
> > django app" you're left with a far smaller task for the pyjs
> > interpreter to have to tackle.
>
> I do not get all this but it seems to say that I do not really need all
> the features of the later Pythons to write user-interface code.

 by a roundabout route... yes.  it's due to web browsers being a
massively restricted environment.

> But I am
> not sure how this applies to business code behind the front end. Of
> course, it might work to run the UI in a separate process if on the same
> machine.

 ok, that's basically what happens: it's not like there is any choice
in the matter.  the python UI code has been translated to javascript:
it's now an AJAX application, not a python application.  the UI code
therefore runs in that browser's "separate process".  it's a highly
restricted execution environment that's very very well-defined, and
you cannot, *cannot* in any way go outside of the boundaries, as
defined by W3C (sort-of).

 the only access to the outside world is either AJAX, HTML5 Sockets
(if supported), or for the user to agree to the installation of a
plugin (such as silverlight, java, adobe flash, or god forbid the
xulrunner / firefox "language=python" extension which was sponsored by
the mozilla foundation back in 2000 - it quite literally embeds the
entire libpython library into a firefox plugin!)

 so, you REALLY have to subdivide the application, just as you have to
subdivide *any* AJAX application, into "front-end", "back-end".  at
the front-end, you can do anything... as long as it's restricted
javascript; at the back-end (server-side) you can do ANYTHING.
django, whatever - even php or .net if you're feeling sick...

 this does take quite a long time to sink in :)  even i had difficulty
appreciating that yes, you can write UI web applications *in python*,
but nooo, you can't *actually* execute that python code in the web
browser, and consequently nooo, you cannot have "standard" python
modules in the web browser.

 it's kinda like pypy - you can have anything you like, as long as
it's in pure python [so it can be translated to javascript].

l.

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

#5578

Terry Reedy wrote:
> Like it or not, Python 3 is the future of Python. It is the Python that
> many Python newcomers learn first, and perhaps ever will.

Yes, no doubt, and I'm genuine about that...

... but there is something else to consider, as I'm sure you are aware. 
At some point Python is going to have to standardize in order to 
survive. And by survive I'm not talking about the Python 'community,' as 
much as I'm talking about the acceptance and wide-spread use of Python 
by people who just want to get work done and solve problems.

If there is another major jump like  2.x --> 3.x  in the future, Python 
will die. I hope you guys are aware of this. The user base might accept 
this thing once, but they're not going do it again...

Like it or not, Python 2.x has millions of lines of code running out 
there, and they're not going to get morphed into 3.x coding. So, 2x is 
going to be around for many years to come.

On the other hand, I'm teaching 3x, coding 3x, and porting to 3x... and 
also encouraging others to do the same... but there is a limit to that 
also. My system has 2.4, 2.5, 2.6, 2.7 and 3.2...   and that's the 
trouble with an interpreter. Different versions of the source code (.py 
files) require a matching 'interpreter,' where-as in other languages a 
new compiler version does not require recompiling source, but if source 
is recompiled everything still works... not so in Python. The fact that 
Python is free to morph gleely from PEP to PEP without responsibility or 
accountability with the user base is what may kill Python, unless the 
Python community gets a grip on this concept.


kind regards,
m harris

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

#5643

On 5/17/2011 12:38 PM, harrismh777 wrote:
> Terry Reedy wrote:
>> Like it or not, Python 3 is the future of Python. It is the Python that
>> many Python newcomers learn first, and perhaps ever will.
>
> Yes, no doubt, and I'm genuine about that...
>
> ... but there is something else to consider, as I'm sure you are aware.
> At some point Python is going to have to standardize in order to
> survive. And by survive I'm not talking about the Python 'community,' as
> much as I'm talking about the acceptance and wide-spread use of Python
> by people who just want to get work done and solve problems.
>
> If there is another major jump like 2.x --> 3.x in the future,

There can't be, in that the essence of the jump was elimination of 
original flaws in 1.0 or 1.1 by elimination of old ways in favor of new 
ways that are already present in 2.7 or before.

> Python will die. I hope you guys are aware of this.

No, because I think you are exaggerating.  That said, I think core 
Python is pretty close to 'complete' and I would not mind further syntax 
freezes like the one for 3.2.

> Like it or not, Python 2.x has millions of lines of code running out
> there, and they're not going to get morphed into 3.x coding.

Except for public libraries, I do not think it should be.

> So, 2x is going to be around for many years to come.

For as long the existing binaries can run or a long as the code can be 
compiled.

> with an interpreter. Different versions of the source code (.py files)
> require a matching 'interpreter,'

Most 2.x code is forward compatible with newer 2.x versions.

> where-as in other languages a new
> compiler version does not require recompiling source, but if source is
> recompiled everything still works...

Unless the new compiler is for a newer version of the language. I 
believe C89 compilers had problems with some K&R + extensions C. I do 
not know if C89 code is completely C99 compatible. I know the reverse is 
not true, CPython is still C89 code since that apparently still makes it 
available on more machines.

-- 
Terry Jan Reedy

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

#5653

Terry Reedy wrote:
>
> No, because I think you are exaggerating.  That said, I think core
> Python is pretty close to 'complete' and I would not mind further syntax
> freezes like the one for 3.2.

I am exaggerating only to the extent that someone can imagine folks 
becoming just annoyed with PEP progress to drop the whole thing... I am 
exaggerating only to the extent that we define 'it' as language death... 
if the user base narrows, python's future is held tentative... on the 
other hand, if the user base grows and campers are happy, then python's 
future is more stable... I don't think this is an exaggeration...

That said, I am encouraged to here your other words, including a favored 
tendency towards syntax freeze... thanks...



kind regards,
m harris

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

#5678 — Re: pyjamas 0.8alpha1 release

On May 18, 6:29 am, harrismh777 <harrismh...@charter.net> wrote:
> Terry Reedy wrote:
>
> > No, because I think you are exaggerating.  That said, I think core
> > Python is pretty close to 'complete' and I would not mind further syntax
> > freezes like the one for 3.2.
>
> I am exaggerating only to the extent that someone can imagine folks
> becoming just annoyed with PEP progress to drop the whole thing... I am
> exaggerating only to the extent that we define 'it' as language death...
> if the user base narrows, python's future is held tentative... on the
> other hand, if the user base grows and campers are happy, then python's
> future is more stable... I don't think this is an exaggeration...

 one thing that people are not aware of - because it normally simply
does not make its way out into the public world: you're forgetting
those people who "just use" python.  they don't get onto public
mailing lists, they don't develop free software projects.

 i've mentioned this story before, but it's worth repeating in this
context.  i worked in a military environment (NC3A) back in
2006-2007.  the version of python that they were using was http://python
two... point... ONE.  six years after its release.  why???

 well, it went something like this.  someone got the idea that doing a
portal would be good.  so they looked around, and found Zope.  so,
they evaluated the latest version somewhere around ooo april to june
of 2001.  ok they _started_ evaluating it.  so, some four months
later, after doing some coding examples, we're now up to august 2001,
a decision has to be made by the internal client.  they say "yep, go
for it", but that took another four months (dec 2002).  now we do 18
months of software development (july 2003) to produce a base package.

 now the code now has to be handed over to a team who perform security
evaluations.  this has to be paid for.  another six months go by, and
the security accreditation is received (dec 2004).  but this was just
for the "base" code: now we have deployment and actual product /
portal development, and a maintenance cycle of 2 years (2006).  now
i'm called in to help with that maintenance and development cycle
(2007).

 and throughout this time there is *no way* that they can upgrade from
python 2.1, because it would cost another $EUR 10,000 to get the
accreditation certificate.

 it's now 2011. for all i know, some TEN YEARS after python 2.1 was
released, they're still using it.

 you ... _just_ don't normally hear about these kinds of deployments
of free software, but it illustrates that a particular version can
hang around for a hell of a long time.

 l.

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

#5655 — Re: pyjamas 0.8alpha1 release

harrismh777 <harrismh...@charter.net> wrote:
> If there is another major jump like  2.x --> 3.x  in the future, Python
> will die. I hope you guys are aware of this. The user base might accept
> this thing once, but they're not going do it again...

The differences between major version releases of Python are far, far
less than those of PHP's _minor_ releases. Hasn't seemed to have
harmed its uptake at all.

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

#5695 — Re: pyjamas 0.8alpha1 release

On May 17, 5:38 pm, harrismh777 <harrismh...@charter.net> wrote:

> is recompiled everything still works... not so in Python. The fact that
> Python is free to morph gleely from PEP to PEP without responsibility or
> accountability with the user base is what may kill Python, unless the
> Python community gets a grip on this concept.

 he's got a good point, terry.  breaking backwards-compatibility was a
completely mad and incomprehensible decision.  i don't believe version
N of python is going to "die" due to changes - the sheer inertia of
hundreds of millions of lines of code and hundreds of thousands of
projects will make sure that's not going to happen, but it doesn't
help.

 it doesn't matter what the leading-edge developers behind python
_want_ to happen: it took 10+ years for python 1 and 2 to gain
traction, and i believe that's the sort of order of magnitude lag-time
to expect people world-wide to make decisions [to replace code].  you
only have to look at how long it's taking IE6 to die.... :)

 l.

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

#5758 — Re: pyjamas 0.8alpha1 release

On 5/18/2011 9:42 AM, lkcl wrote:

>   he's got a good point, terry.  breaking backwards-compatibility was a
> completely mad and incomprehensible decision.

I see that I should take everything you (or Harris) say with a big grain 
of salt;-). You just gave me a lecture about the impossibility of doing 
everything one might like with limited all or mostly volunteer 
resources. So surely you can comprehend that the same applies to CPython 
also.

Given that Python 1.0/1 had some design defects that became evident with 
experience and simply lacked some things thought of later, I can think 
of several options:

1. Never fix them.

2. Add fixes, but keep the old stuff. If the old and new ways are 
somewhat compatible, keep both available at the same time*. If they 
conflict, keep old as default and make new available on demand (future 
import)#. This was 2.x strategy.

2A. Make new ways default and have past imports.

3. Gradually delete old. This was and is policy mostly for library.

4. Delete lots of old ways all at once. This was 3.x.

What would you have had us do instead?

* Example: old and new style classes. Problems: the differences are hard 
to learn and hard to remember; they are sometimes irrelevant, but 
sometimes not; if you import and instantiate a class, you may not know 
which you have.

# Example: int division. Problems: having the deprecated meaning be 
default is a damn nuisance; learning it is a stupid burden; if you see 
'a/b' in a snippet extracted from a file, you do not know what it means.

2.7 is really the end of the road for strategy 2. Keeping obsolete 
features around is a learning burden for most newbies and a maintenance 
burden for developers.

-- 
Terry Jan Reedy

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

#5773 — python2+3

[changing subject, seems a good idea...]

On May 19, 2:13 am, Terry Reedy <tjre...@udel.edu> wrote:
> On 5/18/2011 9:42 AM, lkcl wrote:
>
> >   he's got a good point, terry.  breaking backwards-compatibility was a
> > completely mad and incomprehensible decision.
>
> I see that I should take everything you (or Harris) say with a big grain
> of salt;-).

 *lol* - i realise it's a hell of a lot of work to get a python
interpreter to support two different grammars and syntaxes: you can
appreciate that i'm in a better position than most to understand that
[i've also done a port of python to gnu-win32 so am familiar with the
codebase]

 now that the code for both has been written, tested and proven, the
task of adding one t't'othr is a leetle less of a challenging task.

 there is one teeny tiny annoying challenge: namespace clashes in c,
of functions and data structures between the two codebases.  however,
this isn't as bad as it first seems.  it's only the "public" face
(Python.h) which has to remain the same, and that can be taken care of
by having data structures that are identical internally and externally
(macros to the rescue) where the internal name is Python2_xxxx and the
external name Python_xxx.

 where it becomes less of a maintenance burden is when you say "ok,
that's it: definitely end-of-the-road for all 2.N development,
period".

 has anyone considered the idea of literally creating a Python2/
subdirectory in the python3 codebase, literally just dropping the
entire python2.N code directly into it, renaming all functions and
data structures, adding a "--2-compatible" switch to the python3 argc/
v and seeing what happens?

 no interoperability, no maintenance, no "compatibility" - just
"support for python 2 directly in the python3 binary".

l.

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

#5793 — Re: python2+3

On Thu, 19 May 2011 05:42:29 -0700, lkcl wrote:

>  has anyone considered the idea of literally creating a Python2/
> subdirectory in the python3 codebase, literally just dropping the entire
> python2.N code directly into it, renaming all functions and data
> structures, adding a "--2-compatible" switch to the python3 argc/ v and
> seeing what happens?
> 
>  no interoperability, no maintenance, no "compatibility" - just
> "support for python 2 directly in the python3 binary".

No maintenance?

The code won't maintain itself, people using it won't stop reporting 
bugs. Are you suggesting that the CPython developers should just grit 
their teeth and refuse to maintain or support code that is part of the 
official release?

Who is your suggested user-base? Those who want support for 2.7 to 
continue won't be happy with an unmaintained, unsupported compatibility 
layer. Those who are happy to keep on using obsolete software won't need 
this compatibility layer, they can just keep using the Python 2.7 they 
already have. Or 2.5, or 1.5 if they prefer. (I have 1.5 on my machine, 
installed from source, and it works perfectly well.)

And what of the others? Jython, IronPython, PyPy, Stackless ... once they 
make the move to Python 3 compatibility, are they expected to implement 
this compatibility layer as well?

I dare say that once the original developers stop supporting Python 2.7 
in three or seven(?) years, there will be a good niche for some 
commercial distribution like ActiveState to continue support. Or one of 
the many critics who insist that Python 3 is a mistake can put their 
money where their mouth is and continue support themselves. 

After all, Python is open source. Somebody (you?) could even fork the 
code base and implement your suggested compatibility layer, or backport 
Python 3 features, be really daring and create a 2/3 hybrid.



-- 
Steven

[toc] | [prev] | [standalone]

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

csiph-web