2.6, 3.0, and truly independent intepreters

[Rhamphoryncus]

On Oct 22, 10:31 pm, Andy <and... at gmail.com> wrote:
> > You seem confused.  PEP 3121 is for isolated interpreters (ie emulated
> > processes), not threading.
>
> Please reread my points--inherently isolated interpreters (ie. the top
> level object) are indirectly linked to thread independence.  I don't
> want to argue, but you seem hell-bent on not hearing what I'm trying
> to say here.

I think the confusion is a matter of context.  Your app, written in C
or some other non-python language, shares data between the threads and
thus treats them as real threads.  However, from python's perspective
nothing is shared, and thus it is processes.

Although this contradiction is fine for embedding purposes, python is
a general purpose language, and needs to be capable of directly
sharing objects.  Imagine you wanted to rewrite the bulk of your app
in python, with only a relatively small portion left in a C extension
module.


> > Got some real benchmarks to back that up?  How about testing it on a
> > 16 core (or more) box and seeing how it scales?
>
> I don't care to argue with you, and you'll have to take it on faith
> that I'm not spouting hot air.  But just to put this to rest, I'll
> make it clear in this Jython case:
>
> You can't sell software to end users and expect them have a recent,
> working java distro.  Look around you: no real commercial software
> title that sells to soccer moms and gamers use java.  There's method
> to commercial software production, so please don't presume that you
> know my job, product line, and customers better than me, ok?
>
> Just to put things in perspective, I already have exposed my company
> to more support and design liability than I knew I was getting into by
> going with python (as a result of all this thread safety and
> interpreter independence business).  I love to go into that one, but
> it's frankly just not a good use of my time right now.  Please just
> accept that when someone says an option is a deal breaker, then it's a
> deal breaker.  This isn't some dude's masters thesis project here--we
> pay our RENT and put our KIDS through school because we sell and ship
> software that works is meant to entertain people happy.

Consider it accepted.  I understand that PyPy/Jython/IronPython don't
fit your needs.  Likewise though, CPython cannot fit my needs.  What
we both need simply does not exist today.


> > I'd like to see python used more, but fixing these things properly is
> > not as easy as believed.  Those in the user community see only their
> > immediate problem (threads don't use multicore).  People like me see
> > much bigger problems.  We need consensus on the problems, and how to
> > solve it, and a commitment to invest what's required.
>
> Well, you seem to come down pretty hard on people that at your
> doorstep saying their WILLING and INTERESTED in supporting python
> development.  And, you're exactly right:  users see only their
> immediate problem--but that's the definition of being a user.  If
> users saw the whole picture from the dev side, then they be
> developers, not users.
>
> Please consider that you're representing the python dev community
> here; I'm you're friend here, not your enemy.

I'm sorry if I came across harshly.  My intent was merely to push you
towards supporting long-term solutions, rather than short-term ones.