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

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

How keep Python 3 moving forward

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

Contents

  How keep Python 3 moving forward Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-23 21:16 +0100
    Re: How keep Python 3 moving forward Roy Smith <roy@panix.com> - 2014-05-23 19:57 -0400
      Re: How keep Python 3 moving forward Ethan Furman <ethan@stoneleaf.us> - 2014-05-23 17:27 -0700
        Re: How keep Python 3 moving forward Roy Smith <roy@panix.com> - 2014-05-23 21:12 -0400
      Python 3 support for Fabric (was: How keep Python 3 moving forward) Ben Finney <ben@benfinney.id.au> - 2014-05-24 14:29 +1000
      Re: How keep Python 3 moving forward - suds & Python 3 Jurko Gospodnetić <jurko.gospodnetic@pke.hr> - 2014-05-25 10:54 +0200
      Re: How keep Python 3 moving forward Stefan Behnel <stefan_ml@behnel.de> - 2014-05-25 11:25 +0200
        Re: How keep Python 3 moving forward Roy Smith <roy@panix.com> - 2014-05-25 14:03 -0400
          Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward) Ben Finney <ben@benfinney.id.au> - 2014-05-26 13:16 +1000
            Re: Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward) Roy Smith <roy@panix.com> - 2014-05-26 08:44 -0400
              Re: Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-27 02:59 +0000
                Re: Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward) Rustom Mody <rustompmody@gmail.com> - 2014-05-26 20:54 -0700
              Re: Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-27 03:06 +0000
    Re: How keep Python 3 moving forward wxjmfauth@gmail.com - 2014-05-24 00:13 -0700
      Re: How keep Python 3 moving forward blindanagram <noone@nowhere.net> - 2014-05-24 15:35 +0100
        Re: How keep Python 3 moving forward Marko Rauhamaa <marko@pacujo.net> - 2014-05-24 12:59 +0300
          Re: How keep Python 3 moving forward Rustom Mody <rustompmody@gmail.com> - 2014-05-24 03:40 -0700
          Re: How keep Python 3 moving forward Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-05-24 09:03 -0700
            Re: How keep Python 3 moving forward Marko Rauhamaa <marko@pacujo.net> - 2014-05-24 22:49 +0300
              Re: How keep Python 3 moving forward Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-24 21:11 +0100
              Re: How keep Python 3 moving forward Terry Reedy <tjreedy@udel.edu> - 2014-05-24 20:27 -0400
                Re: How keep Python 3 moving forward wxjmfauth@gmail.com - 2014-05-24 23:43 -0700
                  Re: How keep Python 3 moving forward Ethan Furman <ethan@stoneleaf.us> - 2014-05-25 08:21 -0700
                    Re: How keep Python 3 moving forward Rustom Mody <rustompmody@gmail.com> - 2014-05-25 10:38 -0700
                      Re: How keep Python 3 moving forward Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-25 18:17 +0000
                        Re: How keep Python 3 moving forward Tim Chase <python.list@tim.thechases.com> - 2014-05-25 13:56 -0500
                        Re: How keep Python 3 moving forward Ethan Furman <ethan@stoneleaf.us> - 2014-05-25 13:18 -0700
                      Re: How keep Python 3 moving forward Ethan Furman <ethan@stoneleaf.us> - 2014-05-25 11:34 -0700
                      Re: How keep Python 3 moving forward Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-25 21:24 +0100
                      Re: How keep Python 3 moving forward Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-25 18:22 -0400
                      Re: How keep Python 3 moving forward Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-26 00:09 +0100
                        Re: How keep Python 3 moving forward wxjmfauth@gmail.com - 2014-05-26 07:03 -0700
                      Re: How keep Python 3 moving forward Chris Angelico <rosuav@gmail.com> - 2014-05-26 10:24 +1000
                      Re: How keep Python 3 moving forward Ethan Furman <ethan@stoneleaf.us> - 2014-05-25 17:32 -0700
                  Re: How keep Python 3 moving forward Chris Angelico <rosuav@gmail.com> - 2014-05-26 01:52 +1000
                  Re: How keep Python 3 moving forward Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-25 17:32 +0100
                  Re: How keep Python 3 moving forward Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-25 18:20 -0400
                  Re: How keep Python 3 moving forward Terry Reedy <tjreedy@udel.edu> - 2014-05-25 21:32 -0400
          Re: How keep Python 3 moving forward Ethan Furman <ethan@stoneleaf.us> - 2014-05-24 12:08 -0700
          Re: How keep Python 3 moving forward Stefan Behnel <stefan_ml@behnel.de> - 2014-05-24 21:44 +0200
        Re: How keep Python 3 moving forward Travis Griggs <travisgriggs@gmail.com> - 2014-05-24 11:02 -0700
        Re: How keep Python 3 moving forward Gene Heskett <gheskett@wdtv.com> - 2014-05-25 20:45 -0400
      Re: How keep Python 3 moving forward Grant Edwards <invalid@invalid.invalid> - 2014-05-24 14:06 +0000

Page 1 of 3  [1] 2 3  Next page →

#71942 — How keep Python 3 moving forward

An article by Brett Cannon that I thought might be of interest 
http://nothingbutsnark.svbtle.com/my-view-on-the-current-state-of-python-3

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [next] | [standalone]

#71948

In article <mailman.10254.1400876180.18130.python-list@python.org>,
 Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:

> An article by Brett Cannon that I thought might be of interest 
> http://nothingbutsnark.svbtle.com/my-view-on-the-current-state-of-python-3

Thanks for the pointer.  I installed and ran caniusepython3.  It tells 
me:

> Finding and checking dependencies ...
> [WARNING] rpclib not found
> 
> You need 19 projects to transition to Python 3.
> Of those 19 projects, 17 have no direct dependencies blocking their 
> transition:
> 
>   beanstalkc
>   dateglob
>   diamond
>   django-multi-sessions
>   django-timedeltafield
>   dnspython
>   ecks
>   fabric
>   gevent (which is blocking grequests)
>   hash_ring
>   httmock
>   jellyfish
>   boto (which is blocking mrjob)
>   paste
>   pyephem
>   python-cjson
>   suds

That's a big list.  A few of those we could probably work around or 
replace with a different module without too much pain.  But, between 
gevent, boto, fabric, and suds, any idea of migrating is a total 
non-starter for us.  I imagine they're all working on ports, but I'll 
check back in a year and see how things stand.

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

#71951

On 05/23/2014 04:57 PM, Roy Smith wrote:
>
> Thanks for the pointer.  I installed and ran caniusepython3.  It tells
> me:

[snip]

> That's a big list.  A few of those we could probably work around or
> replace with a different module without too much pain.  But, between
> gevent, boto, fabric, and suds, any idea of migrating is a total
> non-starter for us.  I imagine they're all working on ports, but I'll
> check back in a year and see how things stand.

Don't imagine.  Send 'em an email!  Let them know there is one more user who'd like a Python 3 port.

--
~Ethan~

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

#71952

In article <mailman.10260.1400892736.18130.python-list@python.org>,
 Ethan Furman <ethan@stoneleaf.us> wrote:

> On 05/23/2014 04:57 PM, Roy Smith wrote:
> >
> > Thanks for the pointer.  I installed and ran caniusepython3.  It tells
> > me:
> 
> [snip]
> 
> > That's a big list.  A few of those we could probably work around or
> > replace with a different module without too much pain.  But, between
> > gevent, boto, fabric, and suds, any idea of migrating is a total
> > non-starter for us.  I imagine they're all working on ports, but I'll
> > check back in a year and see how things stand.
> 
> Don't imagine.  Send 'em an email!  Let them know there is one more user 
> who'd like a Python 3 port.

But, you're assuming I want that.  I don't.  What I have now works.

I'm not trying to be difficult here.  I'm just looking at all the things 
I could be doing with my time that will improve my product and/or help 
grow the business.  "Transition to Python 3" isn't even on the list.

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

#71954 — Python 3 support for Fabric (was: How keep Python 3 moving forward)

Roy Smith <roy@panix.com> writes:

> Thanks for the pointer.  I installed and ran caniusepython3.  It tells 
> me:
>
> > Of those 19 projects, 17 have no direct dependencies blocking their 
> > transition:
> > […]
> >   fabric

Fabric was for a long time held back by its dependency on the Paramiko
library. But that library is now Python 3 compatible, and Fabric is
moving steadily in the direction of Python 3 support.

The latest is a change in the documentation to explicitly remove the
last dependency hurdle <URL:https://github.com/fabric/fabric/pull/1137>.

Now the only blockers are internal; Fabric 2.0 is AFAICT going to be the
Python 3 compatible version of Fabric, and it is coming along well.

-- 
 \       “Some people have a problem, and they think “I know, I'll use |
  `\     Perl!”. Now they have some number of problems but they're not |
_o__)     sure whether it's a string or an integer.” —Benno Rice, 2011 |
Ben Finney

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

#71991 — Re: How keep Python 3 moving forward - suds & Python 3

   Hi Roy.

On 24.5.2014. 1:57, Roy Smith wrote:
>> You need 19 projects to transition to Python 3.
>> Of those 19 projects, 17 have no direct dependencies blocking their
>> transition:
>>
>>[...snipped...]
>>    suds
>
> That's a big list.  A few of those we could probably work around or
> replace with a different module without too much pain.  But, between
> gevent, boto, fabric, and suds, any idea of migrating is a total
> non-starter for us.  I imagine they're all working on ports, but I'll
> check back in a year and see how things stand.

   FYI, the suds-jurko fork works on Python 3. And since I'm not aware 
of any other actively maintained fork, should I find more free time in 
the future I might rename it to suds and try to convert it to a formal 
successor to suds.

   Hope this helps.

   Best regards,
     Jurko Gospodnetić

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

#71992

Roy Smith, 24.05.2014 01:57:
> I installed and ran caniusepython3.  It tells me:
> 
>> Finding and checking dependencies ...
>> [WARNING] rpclib not found
>>
>> You need 19 projects to transition to Python 3.
>> Of those 19 projects, 17 have no direct dependencies blocking their 
>> transition:
>>
>>   beanstalkc
>>   dateglob
>>   diamond
>>   django-multi-sessions
>>   django-timedeltafield
>>   dnspython
>>   ecks
>>   fabric
>>   gevent (which is blocking grequests)
>>   hash_ring
>>   httmock
>>   jellyfish
>>   boto (which is blocking mrjob)
>>   paste
>>   pyephem
>>   python-cjson
>>   suds
> 
> That's a big list.  A few of those we could probably work around or 
> replace with a different module without too much pain.  But, between 
> gevent, boto, fabric, and suds, any idea of migrating is a total 
> non-starter for us.  I imagine they're all working on ports, but I'll 
> check back in a year and see how things stand.

Ubuntu provides a (partial) Py3 port of boto. And I don't really see why
you would consider fabric a dependency that keeps you from switching to
Py3. In many cases, you can just keep running it in Py2 as you did before.

Taking a closer look at the "big list" that caniusepython3 spits out will
usually make it shrink to a manageable size. Meaning, the blind size of
that list is not an excuse for anything.

Stefan

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

#72025

In article <mailman.10285.1401009964.18130.python-list@python.org>,
 Stefan Behnel <stefan_ml@behnel.de> wrote:

> Ubuntu provides a (partial) Py3 port of boto.

As long as the part that's ported includes all the bits of boto we 
currently need, plus all the bits of boto we haven't yet discovered we 
need, but will sometime in the future, we're good :-)

> And I don't really see why you would consider fabric a dependency 
> that keeps you from switching to Py3. In many cases, you can just 
> keep running it in Py2 as you did before.

In theory, that's possible.  In practice, it would mean having to 
maintain two different versions of Python, and test everything against 
both.  That adds a lot of complexity, for very little value.

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

#72047 — Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward)

Roy Smith <roy@panix.com> writes:

> Stefan Behnel <stefan_ml@behnel.de> wrote:
>
> > And I don't really see why you would consider fabric a dependency
> > that keeps you from switching to Py3. In many cases, you can just
> > keep running it in Py2 as you did before.
>
> In theory, that's possible. In practice, it would mean having to
> maintain two different versions of Python

Why would using Fabric – a build tool – require you to “maintain two
different versions of Python”? You only need to maintain the build
scripts, not Python itself.

> and test everything against both.

That makes even less sense. The build system runs under whatever version
of Python it needs, and your code runs under whatever version of Python
you like. The two don't affect each other at run time, and don't affect
each other's testing dependencies.

How would Fabric's dependency on Python 2 require you to “test
everything against both [Python 2 and Python 3]”? Fabric needs Python 2
(for now), but your code doesn't.

At least one of us seems to be misunderstanding what is required.

-- 
 \       “Science and religion are incompatible in the same sense that |
  `\       the serious pursuit of knowledge of reality is incompatible |
_o__)                       with bullshit.” —Paul Z. Myers, 2010-03-14 |
Ben Finney

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

#72060 — Re: Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward)

In article <mailman.10329.1401074189.18130.python-list@python.org>,
 Ben Finney <ben@benfinney.id.au> wrote:

> Roy Smith <roy@panix.com> writes:
> 
> > Stefan Behnel <stefan_ml@behnel.de> wrote:
> >
> > > And I don't really see why you would consider fabric a dependency
> > > that keeps you from switching to Py3. In many cases, you can just
> > > keep running it in Py2 as you did before.
> >
> > In theory, that's possible. In practice, it would mean having to
> > maintain two different versions of Python
> 
> Why would using Fabric – a build tool – require you to “maintain two
> different versions of Python”? You only need to maintain the build
> scripts, not Python itself.

Because to run these tools, we need have both versions installed on 
every machine.  So, we don't need to maintain Python in the sense of 
building it from source, but we do need to have our deployment scripts 
install it everyplace it's needed (or, at least, make sure it's 
installed as part of some base deployment package)

> > and test everything against both.
> 
> That makes even less sense. The build system runs under whatever version
> of Python it needs, and your code runs under whatever version of Python
> you like. The two don't affect each other at run time, and don't affect
> each other's testing dependencies.

The are tightly integrated, and share code.

> At least one of us seems to be misunderstanding what is required.

Yes :-)

When you start working with large systems, reducing complexity becomes 
important.  Every time you add a component, it comes with its own set of 
dependencies and constraints.  Those things come back to bite you when 
you least expect it.

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

#72097 — Re: Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward)

On Mon, 26 May 2014 08:44:51 -0400, Roy Smith wrote:

>> That makes even less sense. The build system runs under whatever
>> version of Python it needs, and your code runs under whatever version
>> of Python you like. The two don't affect each other at run time, and
>> don't affect each other's testing dependencies.
> 
> The are tightly integrated, and share code.

Well there's your problem, right there. Tight coupling is a *bad* thing, 
you're supposed to minimize it, not maximize it :-)

I'm having trouble understanding why your build system should be 
integrated with your production code. You should, in principle, be able 
to replace your build system with one written in Perl or bash without 
having to touch a single line of your application. If what you say is 
correct, your design tends towards the sort of perplexing errors like "We 
added extra debugging code to the build script, and now the application 
won't print!"

The programmer's attitude towards tightly coupled code ought to be like 
Batman's attitude towards crime: something to be stamped out, at any 
cost, unless it is absolutely for the purpose of a higher cause.

In Batman's case that higher cause is justice and the good of Gotham 
City. What's your higher cause?




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#72099 — Re: Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward)

On Tuesday, May 27, 2014 8:29:13 AM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 26 May 2014 08:44:51 -0400, Roy Smith wrote:
> 
> 
> 
> >> That makes even less sense. The build system runs under whatever
> 
> >> version of Python it needs, and your code runs under whatever version
> 
> >> of Python you like. The two don't affect each other at run time, and
> 
> >> don't affect each other's testing dependencies.
> 
> > 
> 
> > The are tightly integrated, and share code.
> 
> 
> 
> Well there's your problem, right there. Tight coupling is a *bad* thing, 
> 
> you're supposed to minimize it, not maximize it :-)
> 
> 
> 
> I'm having trouble understanding why your build system should be 
> integrated with your production code. You should, in principle, be able 
> to replace your build system with one written in Perl or bash without 
> having to touch a single line of your application. If what you say is 

In theory, theory and practice are the same. In practice, they are not. s/theory/principle

[Whether thats Einsten or Yogi Berra I am not sure. I guess they
are the same in principle :D ]

Somewhat more seriously, I see this as a problem with all the super-kewl languages.  I know it most closely with python and haskell but I think its true across the board. It goes something like this:
- Language L is super-kewl
- Its so kewl it spawns its own ecosystem
- The ecosystem grows
- World domination is almost in sight -- everything to be done with
language L
- Unfortunately super-kewl ≠ omnipotent
- Things start crumbling at the edges

Case(s) in point: debian's apt is a mishmash of perl,shell etc
However it is more powerful than python's pip or Haskell's cabal.

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

#72098 — Re: Build tools, and Python 3 dependencies (was: How keep Python 3 moving forward)

Oh, I was a bit trigger-happy with my earlier post.

On Mon, 26 May 2014 08:44:51 -0400, Roy Smith wrote about his build 
system and production code:

> The are tightly integrated, and share code.

[...]

> When you start working with large systems, reducing complexity becomes
> important.  Every time you add a component, it comes with its own set of
> dependencies and constraints.  Those things come back to bite you when
> you least expect it.

How ironic that you have now got *more* constraints, *stronger* 
dependencies and *more* complexity than if you had written a less tightly 
coupled system.

Complexity is not, in and of itself, the most serious problem. But 
coupling is. You're now constrained that you cannot make changes to your 
application without simultaneously changing your build system. Although 
you have *fewer* dependencies, they've locked you in to a single course 
of action even more tightly than if you had more.

At least that's the impression that you have given.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#71958

Le vendredi 23 mai 2014 22:16:10 UTC+2, Mark Lawrence a écrit :
> An article by Brett Cannon that I thought might be of interest 
> 
> http://nothingbutsnark.svbtle.com/my-view-on-the-current-state-of-python-3
> 
> 
> 
> -- 
> 
> My fellow Pythonistas, ask not what our language can do for you, ask 
> 
> what you can do for our language.
> 
> 
> 
> Mark Lawrence
> 
> 
> 
> ---
> 
> This email is free from viruses and malware because avast! Antivirus protection is active.
> 
> http://www.avast.com

=========
=========

Quote:
""" And with Python 3.4 I really have not heard anyone complain that they wouldn't like to use Python 3 instead of Python 2. """

Or the devs do not wish to listen.

Python 3 will never work.

jmf

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

#71959

On 24/05/2014 08:13, wxjmfauth@gmail.com wrote:
> Le vendredi 23 mai 2014 22:16:10 UTC+2, Mark Lawrence a écrit :
>> An article by Brett Cannon that I thought might be of interest 
>>
>> http://nothingbutsnark.svbtle.com/my-view-on-the-current-state-of-python-3
>>
>>
>>
>> -- 
>>
>> My fellow Pythonistas, ask not what our language can do for you, ask 
>>
>> what you can do for our language.
>>
>>
>>
>> Mark Lawrence
>>
>>
>>
>> ---
>>
>> This email is free from viruses and malware because avast! Antivirus protection is active.
>>
>> http://www.avast.com
> 
> =========
> =========
> 
> Quote:
> """ And with Python 3.4 I really have not heard anyone complain that they wouldn't like to use Python 3 instead of Python 2. """
> 
> Or the devs do not wish to listen.
> 
> Python 3 will never work.

It works for me.

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

#71961

blindanagram <noone@nowhere.net>:

>> Quote:
>> """ And with Python 3.4 I really have not heard anyone complain that
>> they wouldn't like to use Python 3 instead of Python 2. """
>> 
>> Or the devs do not wish to listen.
>> 
>> Python 3 will never work.
>
> It works for me.

Instead of focusing on bringing legacy libraries to Python3 (for which
there never seems to be a critical need), Python3 needs a brand new
killer module/application/library that is only available on Python3.

Asyncio is a baby step in that direction.


Marko

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

#71962

On Saturday, May 24, 2014 3:29:01 PM UTC+5:30, Marko Rauhamaa wrote:
> 
> 
> 
> Instead of focusing on bringing legacy libraries to Python3 (for which
> there never seems to be a critical need), Python3 needs a brand new
> killer module/application/library that is only available on Python3.
> 

I think those times are over
http://en.wikipedia.org/wiki/Long_tail
 
> 
> Asyncio is a baby step in that direction.
> 
No issue with that

> 
> 
> 
> 
> Marko

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

#71965

On Sat, May 24, 2014 at 2:59 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> blindanagram <noone@nowhere.net>:
> Instead of focusing on bringing legacy libraries to Python3 (for which
> there never seems to be a critical need), Python3 needs a brand new
> killer module/application/library that is only available on Python3.
>
> Asyncio is a baby step in that direction.

Yikes! Backwards incompatibility is a poor excuse for NIH syndrome.

Don't reinvent the wheel, please. If there's an existing
implementation of a thing, that can save you a lot of work. Even if it
ties you to Python 2, that's worth it, most of the time. If you want
to migrate to Python 3, help that library forward, rather than trying
to make some bespoke replacement you think will be a killer app.

-- Devin

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

#71969

Devin Jeanpierre <jeanpierreda@gmail.com>:

> If you want to migrate to Python 3, help that library forward, rather
> than trying to make some bespoke replacement you think will be a
> killer app.

Few people have Python 3 as an objective. What I'm saying is that if
Python 3 had something everybody wants and nothing else provides, the
people will come, even the legacy libraries will be ported then.


Marko

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

#71970

On 24/05/2014 20:49, Marko Rauhamaa wrote:
> Devin Jeanpierre <jeanpierreda@gmail.com>:
>
>> If you want to migrate to Python 3, help that library forward, rather
>> than trying to make some bespoke replacement you think will be a
>> killer app.
>
> Few people have Python 3 as an objective. What I'm saying is that if
> Python 3 had something everybody wants and nothing else provides, the
> people will come, even the legacy libraries will be ported then.
>

Legacy libraries are being ported, as shown by the green on the Python 
Wall of Superpowers here https://python3wos.appspot.com/ (remember this 
used to be called the Python Wall of Shame, or something like that). 
What makes you think that they're not being ported?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web