Re: "CPython"

[Avi Gross via Python-list]

David,
I understand now. As a project for your own edification I can understand it, 
albeit it is a more substantial effort than many people might choose, LOL!
So unless it starts being used heavily and adopted by some organization, the 
result of your effort will not necessarily be compatible with many modules now 
available or keep up with changes as python adds features or fixes bugs.
I am curious about why something like numpy could not be integrated into what 
you do. Of course, if you are the only user, ...
My hobbies to spend my time may not be as ambitious, but are quite a bit more 
varied! LOL!



-Original Message-
From: David J W 
To: Avi Gross 
Cc: python-list@python.org 
Sent: Fri, Jun 24, 2022 11:57 am
Subject: Re: "CPython"

The main motivation for a Python virtual machine in Rust is to strengthen my 
knowledge with Rust which currently has some gnarly bits to it but otherwise is 
an impressive low level language.   Rust's future is looking very bright as 
even Linus Torvalds agrees with most of its design choices and is allowing it 
to be used as a linux kernel module language.   
Skipping ahead to the subject of names, Rython was chosen because "Python" is 
trademarked by the PSF so anything with the complete word Python in it is out.  
 A close runner up would have been Camelot but that is already taken.
Going backward to the issue of use and audience.  Making Rython a real virtual 
machine that passes the CPython unit-tests is the only goal.   I am actively 
following the faster CPython fork that Mike Shannon, GVR, and others are 
working on with the intention to try and incorporate what they discover into my 
project but I don't think Rython will be dramatically faster than Cpython 
because I am going to implement the same PyObject reference counting garbage 
collector and unless faster CPython creates a JIT component, Rython won't have 
one either.  Additionally Ryhon won't have the must have killer libraries like 
numpy so it's a moot point if my project turns out to be dramatically faster.
To sum things up, I've been retired for over a decade so I have plenty of free 
time.   Initially I thought I might invest time into becoming a core python 
developer but looking into it further, all I will say is that doesn't feel like 
a very appealing use of my time.


On Thu, Jun 23, 2022 at 9:42 AM Avi Gross  wrote:

David,
I am curious why you are undertaking the effort to take a language already 
decades old and showing signs of being a tad rusty into a language that 
suggests further oxidation.
More seriously, I am interested in what this can gain and the intended user 
base. I studied Rust for a while and it has it's features but have had no 
opportunity to use it. Is it expected to make a faster version of Python, or 
enable better connections to libraries and so on? 
What I mean is that if you are planning on making it pass all tests for python 
functionality, are you also adding unique features or ... ?
My preference is to have names that fully include what they are about. So the 
name "python" would be left intact rather than mangled, even if the name itself 
happens to be totally meaningless. So may I suggest something like 
"""rustic-python""" ?


-Original Message-
From: David J W 
To: python-list@python.org
Sent: Thu, Jun 23, 2022 10:29 am
Subject: Re: "CPython"

>> Let's say they reimplement "reference python" CPython in Rust. What is
>> better? Change the "reference python" CPython name to RPython, for
>> example, or let it as CPython?

>The C implementation would still be called CPython, and the new
>implementation might be called RPython, or RustyPython, or whatever.
>The names are independent of which one is currently blessed as the
>reference implementation.

I am at the pre planning stages of making a Rust implementation of the
Python virtual machine and to avoid ambiguity I've been working with Rython
as the name.  I tried looking for a Monty Python themed name but the good
ones seem to be taken.

Otherwise as for a timeline, solo I figure it's going to take me a couple
years to get something that actually passes cpython's python unit-tests.
-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[David J W]

The main motivation for a Python virtual machine in Rust is to strengthen
my knowledge with Rust which currently has some gnarly bits to it but
otherwise is an impressive low level language.   Rust's future is looking
very bright as even Linus Torvalds agrees with most of its design choices
and is allowing it to be used as a linux kernel module language.

Skipping ahead to the subject of names, Rython was chosen because "Python"
is trademarked by the PSF so anything with the complete word Python in it
is out.   A close runner up would have been Camelot but that is already
taken.

Going backward to the issue of use and audience.  Making Rython a real
virtual machine that passes the CPython unit-tests is the only goal.   I am
actively following the faster CPython fork that Mike Shannon, GVR, and
others are working on with the intention to try and incorporate what they
discover into my project but I don't think Rython will be dramatically
faster than Cpython because I am going to implement the same PyObject
reference counting garbage collector and unless faster CPython creates a
JIT component, Rython won't have one either.  Additionally Ryhon won't have
the must have killer libraries like numpy so it's a moot point if my
project turns out to be dramatically faster.

To sum things up, I've been retired for over a decade so I have plenty of
free time.   Initially I thought I might invest time into becoming a core
python developer but looking into it further, all I will say is that
doesn't feel like a very appealing use of my time.



On Thu, Jun 23, 2022 at 9:42 AM Avi Gross  wrote:

> David,
>
> I am curious why you are undertaking the effort to take a language already
> decades old and showing signs of being a tad rusty into a language
> that suggests further oxidation.
>
> More seriously, I am interested in what this can gain and the intended
> user
> base. I studied Rust for a while and it has it's features but have had no
> opportunity to use it. Is it expected to make a faster version of Python,
> or enable better connections to libraries and so on?
>
> What I mean is that if you are planning on making it pass all tests for
> python functionality, are you also adding unique features or ... ?
>
> My preference is to have names that fully include what they are about.
> So the name "python" would be left intact rather than mangled, even if
> the name itself happens to be totally meaningless. So may I suggest
> something like """rustic-python""" ?
>
>
>
> -----Original Message-
> From: David J W 
> To: python-list@python.org
> Sent: Thu, Jun 23, 2022 10:29 am
> Subject: Re: "CPython"
>
> >> Let's say they reimplement "reference python" CPython in Rust. What is
> >> better? Change the "reference python" CPython name to RPython, for
> >> example, or let it as CPython?
>
> >The C implementation would still be called CPython, and the new
> >implementation might be called RPython, or RustyPython, or whatever.
> >The names are independent of which one is currently blessed as the
> >reference implementation.
>
> I am at the pre planning stages of making a Rust implementation of the
> Python virtual machine and to avoid ambiguity I've been working with Rython
> as the name.  I tried looking for a Monty Python themed name but the good
> ones seem to be taken.
>
> Otherwise as for a timeline, solo I figure it's going to take me a couple
> years to get something that actually passes cpython's python unit-tests.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Avi Gross via Python-list]

David,
I am curious why you are undertaking the effort to take a language already 
decades old and showing signs of being a tad rusty into a language that 
suggests further oxidation.
More seriously, I am interested in what this can gain and the intended user 
base. I studied Rust for a while and it has it's features but have had no 
opportunity to use it. Is it expected to make a faster version of Python, or 
enable better connections to libraries and so on? 
What I mean is that if you are planning on making it pass all tests for python 
functionality, are you also adding unique features or ... ?
My preference is to have names that fully include what they are about. So the 
name "python" would be left intact rather than mangled, even if the name itself 
happens to be totally meaningless. So may I suggest something like 
"""rustic-python""" ?


-Original Message-
From: David J W 
To: python-list@python.org
Sent: Thu, Jun 23, 2022 10:29 am
Subject: Re: "CPython"

>> Let's say they reimplement "reference python" CPython in Rust. What is
>> better? Change the "reference python" CPython name to RPython, for
>> example, or let it as CPython?

>The C implementation would still be called CPython, and the new
>implementation might be called RPython, or RustyPython, or whatever.
>The names are independent of which one is currently blessed as the
>reference implementation.

I am at the pre planning stages of making a Rust implementation of the
Python virtual machine and to avoid ambiguity I've been working with Rython
as the name.  I tried looking for a Monty Python themed name but the good
ones seem to be taken.

Otherwise as for a timeline, solo I figure it's going to take me a couple
years to get something that actually passes cpython's python unit-tests.
-- 
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[David J W]

>> Let's say they reimplement "reference python" CPython in Rust. What is
>> better? Change the "reference python" CPython name to RPython, for
>> example, or let it as CPython?

>The C implementation would still be called CPython, and the new
>implementation might be called RPython, or RustyPython, or whatever.
>The names are independent of which one is currently blessed as the
>reference implementation.

I am at the pre planning stages of making a Rust implementation of the
Python virtual machine and to avoid ambiguity I've been working with Rython
as the name.   I tried looking for a Monty Python themed name but the good
ones seem to be taken.

Otherwise as for a timeline, solo I figure it's going to take me a couple
years to get something that actually passes cpython's python unit-tests.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Greg Ewing]

On 22/06/22 4:42 am, MRAB wrote:

On 2022-06-21 03:52, Avi Gross via Python-list wrote:


This leads to the extremely important question of what would an 
implementation of Python, written completely in C++, be called?

C++Python
CPython++
C+Python+
DPython
SeaPython?
SeeSeaSiPython


CincPython?


Python+=1

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[jkn]

On Tuesday, June 21, 2022 at 2:09:27 PM UTC+1, Grant Edwards wrote:
> On 2022-06-21, Chris Angelico  wrote: 
> 
> > Not sure why it's strange. The point is to distinguish "CPython" from 
> > "Jython" or "Brython" or "PyPy" or any of the other implementations. 
> > Yes, CPython has a special place because it's the reference 
> > implementation and the most popular, but the one thing that makes it 
> > distinct from all the others is that it's implemented in C.
> I've been using CPython (and reading this list) for over 20 years, and 
> there's no doubt in my mind that the C in CPython has always been 
> interpreted by 99+ percent of the Python community as meaning the 
> implementation language. 
> 
> Sort of like ckermit  was the original 
> implementation of Kermit written in C. At the time, the other popular 
> implementations (for DOS, IBM, etc.) were written in assembly. 
> 

Same here, on both counts (20+ years on this Usenet group,
 and CPython == "the canonical C implementation of Python")

Actually, on all three counts - I remember ckermit as well ;-)

Fourthly...

J^n
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[2QdxY4RzWzUUiLuE]

On 2022-06-21 at 17:04:45 +,
Avi Gross via Python-list  wrote:

> My problem with that idea is, believe it or not, that it is too negative. 
> What you meant to be seen as a dash is a minus sign to me. And both C and C++ 
> not only have both a pre and post autoincrement variable using ++x and x++, 
> they also have autodecrement operators using a minus sign such as --x and x-- 
> and it can get pretty weird trying to figure out if some code is legal, let 
> alone what it does, without parentheses. I mean what the heck does this do?
> 
> y = x++-++x

That code evokes (or at least can evoke) nasal demons.

https://en.wikipedia.org/wiki/Undefined_behavior
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Avi Gross via Python-list]

If we want to be humorous, RPython would obviously either be written in R, 
which really is not designed well for such purposes, or would be some kind of 
synthesis that already exists that allows you to run R and python code 
interchangeably on sort of shared data that I sometimes do in RSTUDIO.

I like the way you think Greg. I did not consider how the ++ in C++ is a bit 
like stuttering and since python also starts with a P the effect would be 
something like C-p-p-python.

My problem with that idea is, believe it or not, that it is too negative. What 
you meant to be seen as a dash is a minus sign to me. And both C and C++ not 
only have both a pre and post autoincrement variable using ++x and x++, they 
also have autodecrement operators using a minus sign such as --x and x-- and it 
can get pretty weird trying to figure out if some code is legal, let alone what 
it does, without parentheses. I mean what the heck does this do?

y = x++-++x

The truth is that although I remember Bjarne trying to figure out a good name 
for his somewhat improved language and his choice of C++ rather than D or some 
other gimmick, you could argue he also removed a bit from C. But who would call 
a language C-- ??
Back to serious. This discussion is more about names but is it?
Some of the implementations of Python are not just written in some computer 
language but also in a sort of environment. Arguably some core of functionality 
has to be pretty much consistent to the language definition. But each may add 
interesting twists on its own and that can include the ability to easily link 
in code and libraries written in that language or used in that environment. You 
can have different supersets of a language.
And it can impact where you might use the language as one reason people may not 
understand for using C is that a compiler was available for just about anywhere 
that either ran in that environment or could be run on another to produce 
lower-level code to copy to it. It was also possible to embed code in C that 
was evaluated differently in each environment for some level of fine-tuning.
Some of that may eventually have been true for other implementations but I 
suspect not for some deliberately designed to fit what one party wants and with 
no care that it be shared elsewhere especially as the C version was already 
available there.
Or am I wrong? After all, others who kept improving C thought the ++ concept 
was best removed!


-Original Message-
From: Greg Ewing 
To: python-list@python.org
Sent: Tue, Jun 21, 2022 3:53 am
Subject: Re: "CPython"

On 21/06/22 2:56 pm, Paulo da Silva wrote:
> Let's say they reimplement "reference python" CPython in Rust. What is 
> better? Change the "reference python" CPython name to RPython, for 
> example, or let it as CPython?

The C implementation would still be called CPython, and the new
implementation might be called RPython, or RustyPython, or whatever.
The names are independent of which one is currently blessed as the
reference implementation.

Although if it were called RPython, no doubt a new debate would
flare up over whether the "R" stands for "Rust" or "Reference"...

-- 
Greg
-- 
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[MRAB]

On 2022-06-21 03:38, Paulo da Silva wrote:

Às 02:33 de 21/06/22, Chris Angelico escreveu:

On Tue, 21 Jun 2022 at 11:13, Paulo da Silva
 wrote:


Às 20:01 de 20/06/22, Paulo da Silva escreveu:

Às 18:19 de 20/06/22, Stefan Ram escreveu:

The same personality traits that make people react
to troll postings might make them spread unconfirmed
ideas about the meaning of "C" in "CPython".

The /core/ of CPython is written in C.

CPython is the /canonical/ implementation of Python.

The "C" in "CPython" stands for C.




Not so "unconfirmed"!
Look at this article, I recently read:
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/


There is a sentence in ther that begins with "CPython, short for Core
Python, a reference implementation that other Python distributions are
derived from, ...".

Anyway, I wrote "IMHO".

Do you have any credible reference to your assertion "The "C" in
"CPython" stands for C."?

Thank you.


Well ... I read the responses and they are not touching the point!
I just answered, with my opinion based on articles I have read in the
past. Certainly I could not be sure. That's why I responded as an
opinion (IMHO) and not as an assertion.
Stefan Ram responded with a, at least, not very polite post.
That's why I needed to somehow "defend" why I posted that response, and,
BTW, trying to learn why he said that the C in CPython means "written in C".

I still find very strange, to not say weird, that a compiler or
interpreter has a name based in the language it was written. But, again,
is just my opinion and nothing more.



Not sure why it's strange. The point is to distinguish "CPython" from
"Jython" or "Brython" or "PyPy" or any of the other implementations.

Notice that they are, for example, Jython and not JPython.
There is also Cython that is a different thing.

And YES. You have the right to not feel that as strange.


Jython was originally called JPython.
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Dennis Lee Bieber]

On Tue, 21 Jun 2022 19:53:51 +1200, Greg Ewing
 declaimed the following:

>Although if it were called RPython, no doubt a new debate would
>flare up over whether the "R" stands for "Rust" or "Reference"...

Or does RPython refer to a Python integrated into the R statistics
system? 

Actually -- RPython is already taken...
https://rpython.readthedocs.io/en/latest/

"""
RPython is a translation and support framework for producing
implementations of dynamic languages, emphasizing a clean separation
between language specification and implementation aspects.

By separating concerns in this way, our implementation of Python - and
other dynamic languages - is able to automatically generate a Just-in-Time
compiler for any dynamic language. It also allows a mix-and-match approach
to implementation decisions, including many that have historically been
outside of a user’s control, such as target platform, memory and threading
models, garbage collection strategies, and optimizations applied, including
whether or not to have a JIT in the first place.
"""


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Dennis Lee Bieber]

On Tue, 21 Jun 2022 01:53:38 +0100, Paulo da Silva
 declaimed the following:


>I still find very strange, to not say weird, that a compiler or 
>interpreter has a name based in the language it was written. But, again, 
>is just my opinion and nothing more.
>

The whole purpose for that was to differentiate from Python /language/
implemented in OTHER languages. IronPython is a M$ .NET/C# implementation,
Jython is a JVM/Java implementation.

When you just say "Python" you are referring to ALL of those
implementations.


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[MRAB]

On 2022-06-21 03:52, Avi Gross via Python-list wrote:


This leads to the extremely important question of what would an implementation 
of Python, written completely in C++, be called?
C++Python
CPython++
C+Python+
DPython
SeaPython?
SeeSeaSiPython


CincPython?

FYI, there's a language called D, so DPython would be written in that.


I don't even want to think fo what sound a C# Python would make.
OK, my apologies to all. Being an interpreted language, it makes sense for a 
good part of the interpreter to include parts made in other languages and also 
add-on libraries in even older languages like FORTRAN.  Quite a few languages, 
including some like R, are also partially based on C in similar ways.

[snip]
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Greg Ewing]

On 21/06/22 8:37 pm, Christian Gollwitzer wrote:

Am 20.06.22 um 22:47 schrieb Roel Schroeven:
"CPython is a descendant of Pyscript built on Pyodide, a port of 
CPython, or a Python distribution for the browser and Node.js that is 
based on Webassembly and Emscripten."


To me, this sentence is so badly cobbled together that it could be the 
output of a KI of some sort (GPT-3) trying to summarize stuff from the 
web.


It looks to me like the output of a Markov chain that's been fed
with all the latest programming buzzwords.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Christian Gollwitzer]

Am 20.06.22 um 22:47 schrieb Roel Schroeven:
indication that www.analyticsinsight.net is wrong on that point. Frankly 
that website seems very low quality in general. In that same article 
they say:


"CPython is a descendant of Pyscript built on Pyodide, a port of 
CPython, or a Python distribution for the browser and Node.js that is 
based on Webassembly and Emscripten."


CPython is definitely not a descendant of Pyscript! Looks like someone 
found something (semi-) interesting and tried to write something 
insightful about it, but without really understanding any of it. Other 
articles don't seem to be any better.


To me, this sentence is so badly cobbled together that it could be the 
output of a KI of some sort (GPT-3) trying to summarize stuff from the 
web. It doesn't make any sense at all on a semantic level.


Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Dennis Lee Bieber]

tOn Tue, 21 Jun 2022 02:52:28 + (UTC), Avi Gross 
declaimed the following:

>
>I don't even want to think fo what sound a C# Python would make.

A musical hiss on a frequency of 277.183Hz (for the C# above middle-C)


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Greg Ewing]

On 21/06/22 9:27 pm, Paul Rubin wrote:

What?  I never heard of such a dispute.  The PSF got after someone about
it?  Sheesh.


Upon further research, it seems it wasn't the *Python* trademark that
was at issue. From the Jython FAQ page:


1.2   How does Jython relate to JPython?

Jython is the successor to JPython. The Jython project was created in 
accordance with the CNRI JPython 1.1.x license, in order to ensure the 
continued existence and development of this important piece of Python 
software. The intent is to manage this project with the same open 
policies that are serving CPython so well.


The name had to be changed to something other than JPython, because of 
paragraph 4 in the JPython-1.1 license:


4. Licensee may not use CNRI trademarks or trade name, including
   JPython [...] to endorse or promote products [...]


So there was no dispute, they were just following the terms of a
licence.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[jak]

Il 21/06/2022 04:56, Paulo da Silva ha scritto:

Às 03:20 de 21/06/22, MRAB escreveu:

On 2022-06-21 02:33, Chris Angelico wrote:

On Tue, 21 Jun 2022 at 11:13, Paulo da Silva
 wrote:


Às 20:01 de 20/06/22, Paulo da Silva escreveu:
> Às 18:19 de 20/06/22, Stefan Ram escreveu:


[snip]


After all who cares in which language it is implemented?

Regards.
Paulo



Why are you asking this? The Facebook platform which is mainly developed
in Rust are converting it to C to make it faster and lighter. If as
often happens, many people complain about the speed of python, what
would be the purpose of translating python using a slower language?

--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Greg Ewing]

On 21/06/22 2:56 pm, Paulo da Silva wrote:
Let's say they reimplement "reference python" CPython in Rust. What is 
better? Change the "reference python" CPython name to RPython, for 
example, or let it as CPython?


The C implementation would still be called CPython, and the new
implementation might be called RPython, or RustyPython, or whatever.
The names are independent of which one is currently blessed as the
reference implementation.

Although if it were called RPython, no doubt a new debate would
flare up over whether the "R" stands for "Rust" or "Reference"...

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Greg Ewing]

On 21/06/22 2:52 pm, Avi Gross wrote:


This leads to the extremely important question of what would an implementation 
of Python, written completely in C++, be called?


(Pronounced with a comical stutter) "C-p-p-python!")

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Greg Ewing]

On 21/06/22 2:38 pm, Paulo da Silva wrote:

Notice that they are, for example, Jython and not JPython.


Jython *was* originally called JPython, but that was judged to be
a trademark violation and they were made to change it.

I don't know how MicroPython has escaped the same fate to date.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Eryk Sun]

On 6/20/22, Paulo da Silva  wrote:
>
> Yes, but that does not necessarily means that the C has to refer to the
> language of implementation. It may well be a "core" reference to
> distinguish that implementation from others with different behaviors.

If the reference implementation and API ever switched to a different
programming language, I'd personally be fine with changing the 'C" in
"CPython" to mean "canonical", but not "core". The term "core" is used
for building the interpreter core with access to internals (i.e.
Py_BUILD_CORE, Py_BUILD_CORE_BUILTIN, Py_BUILD_CORE_MODULE, and
Include/internal/pycore*.h). It does not refer to the overall
implementation and API for embedding and extension modules.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Grant Edwards]

On 2022-06-21, Chris Angelico  wrote:

> Not sure why it's strange. The point is to distinguish "CPython" from
> "Jython" or "Brython" or "PyPy" or any of the other implementations.
> Yes, CPython has a special place because it's the reference
> implementation and the most popular, but the one thing that makes it
> distinct from all the others is that it's implemented in C.

I've been using CPython (and reading this list) for over 20 years, and
there's no doubt in my mind that the C in CPython has always been
interpreted by 99+ percent of the Python community as meaning the
implementation language.

Sort of like ckermit  was the original
implementation of Kermit written in C. At the time, the other popular
implementations (for DOS, IBM, etc.) were written in assembly.

--
Grant


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Chris Angelico]

On Tue, 21 Jun 2022 at 13:12, Paulo da Silva
 wrote:
>
> Às 03:20 de 21/06/22, MRAB escreveu:
> > On 2022-06-21 02:33, Chris Angelico wrote:
> >> On Tue, 21 Jun 2022 at 11:13, Paulo da Silva
> >>  wrote:
> >>>
> >>> Às 20:01 de 20/06/22, Paulo da Silva escreveu:
> >>> > Às 18:19 de 20/06/22, Stefan Ram escreveu:
> >>> >>The same personality traits that make people react
> >>> >>to troll postings might make them spread unconfirmed
> >>> >>ideas about the meaning of "C" in "CPython".
> >>> >>
> >>> >>The /core/ of CPython is written in C.
> >>> >>
> >>> >>CPython is the /canonical/ implementation of Python.
> >>> >>
> >>> >>The "C" in "CPython" stands for C.
> >>> >>
> >>> >>
> >>> >
> >>> > Not so "unconfirmed"!
> >>> > Look at this article, I recently read:
> >>> >
> >>> https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/
> >>>
> >>> >
> >>> >
> >>> > There is a sentence in ther that begins with "CPython, short for Core
> >>> > Python, a reference implementation that other Python distributions are
> >>> > derived from, ...".
> >>> >
> >>> > Anyway, I wrote "IMHO".
> >>> >
> >>> > Do you have any credible reference to your assertion "The "C" in
> >>> > "CPython" stands for C."?
> >>> >
> >>> > Thank you.
> >>>
> >>> Well ... I read the responses and they are not touching the point!
> >>> I just answered, with my opinion based on articles I have read in the
> >>> past. Certainly I could not be sure. That's why I responded as an
> >>> opinion (IMHO) and not as an assertion.
> >>> Stefan Ram responded with a, at least, not very polite post.
> >>> That's why I needed to somehow "defend" why I posted that response, and,
> >>> BTW, trying to learn why he said that the C in CPython means "written
> >>> in C".
> >>>
> >>> I still find very strange, to not say weird, that a compiler or
> >>> interpreter has a name based in the language it was written. But, again,
> >>> is just my opinion and nothing more.
> >>>
> >>
> >> Not sure why it's strange. The point is to distinguish "CPython" from
> >> "Jython" or "Brython" or "PyPy" or any of the other implementations.
> >> Yes, CPython has a special place because it's the reference
> >> implementation and the most popular, but the one thing that makes it
> >> distinct from all the others is that it's implemented in C.
> >>
> > And just to make it clear, the interpreter/compiler _itself_ is still
> > called "python". "CPython" is a name/term that was applied retroactively
> > to that particular implementation when another implementation appeared.
> Yes, but that does not necessarily means that the C has to refer to the
> language of implementation. It may well be a "core" reference to
> distinguish that implementation from others with different behaviors.
>
> Let's say they reimplement "reference python" CPython in Rust. What is
> better? Change the "reference python" CPython name to RPython, for
> example, or let it as CPython?
> It's my opinion that it should stay as CPython.
> After all who cares in which language it is implemented?
>

It is HIGHLY unlikely that the reference implementation would change
overnight. Far far more likely, if the reference implementation were
to change, would be that the new interpreter is built for a number of
years as an alternative, and then eventually becomes the more popular
implementation, and finally, the core devs begin using that more than
CPython, and perhaps deprecating CPython altogether. If that were to
happen, the other implementation would have its own name for all those
years, and would keep it after being promoted to reference
implementation.

Also, "PyPy" is a perfectly fine name and doesn't need to be changed.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Chris Angelico]

On Tue, 21 Jun 2022 at 12:53, Avi Gross via Python-list
 wrote:
>
> I don't even want to think fo what sound a C# Python would make.

Probably about 277 Hz...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Paulo da Silva]

Às 03:20 de 21/06/22, MRAB escreveu:

On 2022-06-21 02:33, Chris Angelico wrote:

On Tue, 21 Jun 2022 at 11:13, Paulo da Silva
 wrote:


Às 20:01 de 20/06/22, Paulo da Silva escreveu:
> Às 18:19 de 20/06/22, Stefan Ram escreveu:
>>    The same personality traits that make people react
>>    to troll postings might make them spread unconfirmed
>>    ideas about the meaning of "C" in "CPython".
>>
>>    The /core/ of CPython is written in C.
>>
>>    CPython is the /canonical/ implementation of Python.
>>
>>    The "C" in "CPython" stands for C.
>>
>>
>
> Not so "unconfirmed"!
> Look at this article, I recently read:
> 
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/ 


>
>
> There is a sentence in ther that begins with "CPython, short for Core
> Python, a reference implementation that other Python distributions are
> derived from, ...".
>
> Anyway, I wrote "IMHO".
>
> Do you have any credible reference to your assertion "The "C" in
> "CPython" stands for C."?
>
> Thank you.

Well ... I read the responses and they are not touching the point!
I just answered, with my opinion based on articles I have read in the
past. Certainly I could not be sure. That's why I responded as an
opinion (IMHO) and not as an assertion.
Stefan Ram responded with a, at least, not very polite post.
That's why I needed to somehow "defend" why I posted that response, and,
BTW, trying to learn why he said that the C in CPython means "written 
in C".


I still find very strange, to not say weird, that a compiler or
interpreter has a name based in the language it was written. But, again,
is just my opinion and nothing more.



Not sure why it's strange. The point is to distinguish "CPython" from
"Jython" or "Brython" or "PyPy" or any of the other implementations.
Yes, CPython has a special place because it's the reference
implementation and the most popular, but the one thing that makes it
distinct from all the others is that it's implemented in C.

And just to make it clear, the interpreter/compiler _itself_ is still 
called "python". "CPython" is a name/term that was applied retroactively 
to that particular implementation when another implementation appeared.
Yes, but that does not necessarily means that the C has to refer to the 
language of implementation. It may well be a "core" reference to 
distinguish that implementation from others with different behaviors.


Let's say they reimplement "reference python" CPython in Rust. What is 
better? Change the "reference python" CPython name to RPython, for 
example, or let it as CPython?

It's my opinion that it should stay as CPython.
After all who cares in which language it is implemented?

Regards.
Paulo
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Paulo da Silva]

Às 02:33 de 21/06/22, Chris Angelico escreveu:

On Tue, 21 Jun 2022 at 11:13, Paulo da Silva
 wrote:


Às 20:01 de 20/06/22, Paulo da Silva escreveu:

Às 18:19 de 20/06/22, Stefan Ram escreveu:

The same personality traits that make people react
to troll postings might make them spread unconfirmed
ideas about the meaning of "C" in "CPython".

The /core/ of CPython is written in C.

CPython is the /canonical/ implementation of Python.

The "C" in "CPython" stands for C.




Not so "unconfirmed"!
Look at this article, I recently read:
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/


There is a sentence in ther that begins with "CPython, short for Core
Python, a reference implementation that other Python distributions are
derived from, ...".

Anyway, I wrote "IMHO".

Do you have any credible reference to your assertion "The "C" in
"CPython" stands for C."?

Thank you.


Well ... I read the responses and they are not touching the point!
I just answered, with my opinion based on articles I have read in the
past. Certainly I could not be sure. That's why I responded as an
opinion (IMHO) and not as an assertion.
Stefan Ram responded with a, at least, not very polite post.
That's why I needed to somehow "defend" why I posted that response, and,
BTW, trying to learn why he said that the C in CPython means "written in C".

I still find very strange, to not say weird, that a compiler or
interpreter has a name based in the language it was written. But, again,
is just my opinion and nothing more.



Not sure why it's strange. The point is to distinguish "CPython" from
"Jython" or "Brython" or "PyPy" or any of the other implementations.

Notice that they are, for example, Jython and not JPython.
There is also Cython that is a different thing.

And YES. You have the right to not feel that as strange.

Regards
Paulo
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Avi Gross via Python-list]

This leads to the extremely important question of what would an implementation 
of Python, written completely in C++, be called?
C++Python
CPython++
C+Python+
DPython
SeaPython?
SeeSeaSiPython

I don't even want to think fo what sound a C# Python would make.
OK, my apologies to all. Being an interpreted language, it makes sense for a 
good part of the interpreter to include parts made in other languages and also 
add-on libraries in even older languages like FORTRAN.  Quite a few languages, 
including some like R, are also partially based on C in similar ways. 

-Original Message-
From: Paulo da Silva 
To: python-list@python.org
Sent: Mon, Jun 20, 2022 8:53 pm
Subject: Re: "CPython"

Às 20:01 de 20/06/22, Paulo da Silva escreveu:
> Às 18:19 de 20/06/22, Stefan Ram escreveu:
>>    The same personality traits that make people react
>>    to troll postings might make them spread unconfirmed
>>    ideas about the meaning of "C" in "CPython".
>>
>>    The /core/ of CPython is written in C.
>>
>>    CPython is the /canonical/ implementation of Python.
>>
>>    The "C" in "CPython" stands for C.
>>
>>
> 
> Not so "unconfirmed"!
> Look at this article, I recently read:
> https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/
>  
> 
> 
> There is a sentence in ther that begins with "CPython, short for Core 
> Python, a reference implementation that other Python distributions are 
> derived from, ...".
> 
> Anyway, I wrote "IMHO".
> 
> Do you have any credible reference to your assertion "The "C" in 
> "CPython" stands for C."?
> 
> Thank you.

Well ... I read the responses and they are not touching the point!
I just answered, with my opinion based on articles I have read in the 
past. Certainly I could not be sure. That's why I responded as an 
opinion (IMHO) and not as an assertion.
Stefan Ram responded with a, at least, not very polite post.
That's why I needed to somehow "defend" why I posted that response, and, 
BTW, trying to learn why he said that the C in CPython means "written in C".

I still find very strange, to not say weird, that a compiler or 
interpreter has a name based in the language it was written. But, again, 
is just my opinion and nothing more.

I rest my case.
Thank you all.
-- 
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[MRAB]

On 2022-06-21 02:33, Chris Angelico wrote:

On Tue, 21 Jun 2022 at 11:13, Paulo da Silva
 wrote:


Às 20:01 de 20/06/22, Paulo da Silva escreveu:
> Às 18:19 de 20/06/22, Stefan Ram escreveu:
>>The same personality traits that make people react
>>to troll postings might make them spread unconfirmed
>>ideas about the meaning of "C" in "CPython".
>>
>>The /core/ of CPython is written in C.
>>
>>CPython is the /canonical/ implementation of Python.
>>
>>The "C" in "CPython" stands for C.
>>
>>
>
> Not so "unconfirmed"!
> Look at this article, I recently read:
> 
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/
>
>
> There is a sentence in ther that begins with "CPython, short for Core
> Python, a reference implementation that other Python distributions are
> derived from, ...".
>
> Anyway, I wrote "IMHO".
>
> Do you have any credible reference to your assertion "The "C" in
> "CPython" stands for C."?
>
> Thank you.

Well ... I read the responses and they are not touching the point!
I just answered, with my opinion based on articles I have read in the
past. Certainly I could not be sure. That's why I responded as an
opinion (IMHO) and not as an assertion.
Stefan Ram responded with a, at least, not very polite post.
That's why I needed to somehow "defend" why I posted that response, and,
BTW, trying to learn why he said that the C in CPython means "written in C".

I still find very strange, to not say weird, that a compiler or
interpreter has a name based in the language it was written. But, again,
is just my opinion and nothing more.



Not sure why it's strange. The point is to distinguish "CPython" from
"Jython" or "Brython" or "PyPy" or any of the other implementations.
Yes, CPython has a special place because it's the reference
implementation and the most popular, but the one thing that makes it
distinct from all the others is that it's implemented in C.

And just to make it clear, the interpreter/compiler _itself_ is still 
called "python". "CPython" is a name/term that was applied retroactively 
to that particular implementation when another implementation appeared.



I could, perhaps, create my own interpreter and name it "RosuavPython"
after myself, but when something's made by a team, it's usually more
useful to pick something that is fundamental to it (Brython is
designed to be run in a browser, Jython is written in Python to make
it easy to call on Java classes, etc).

ChrisA


--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Chris Angelico]

On Tue, 21 Jun 2022 at 11:13, Paulo da Silva
 wrote:
>
> Às 20:01 de 20/06/22, Paulo da Silva escreveu:
> > Às 18:19 de 20/06/22, Stefan Ram escreveu:
> >>The same personality traits that make people react
> >>to troll postings might make them spread unconfirmed
> >>ideas about the meaning of "C" in "CPython".
> >>
> >>The /core/ of CPython is written in C.
> >>
> >>CPython is the /canonical/ implementation of Python.
> >>
> >>The "C" in "CPython" stands for C.
> >>
> >>
> >
> > Not so "unconfirmed"!
> > Look at this article, I recently read:
> > https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/
> >
> >
> > There is a sentence in ther that begins with "CPython, short for Core
> > Python, a reference implementation that other Python distributions are
> > derived from, ...".
> >
> > Anyway, I wrote "IMHO".
> >
> > Do you have any credible reference to your assertion "The "C" in
> > "CPython" stands for C."?
> >
> > Thank you.
>
> Well ... I read the responses and they are not touching the point!
> I just answered, with my opinion based on articles I have read in the
> past. Certainly I could not be sure. That's why I responded as an
> opinion (IMHO) and not as an assertion.
> Stefan Ram responded with a, at least, not very polite post.
> That's why I needed to somehow "defend" why I posted that response, and,
> BTW, trying to learn why he said that the C in CPython means "written in C".
>
> I still find very strange, to not say weird, that a compiler or
> interpreter has a name based in the language it was written. But, again,
> is just my opinion and nothing more.
>

Not sure why it's strange. The point is to distinguish "CPython" from
"Jython" or "Brython" or "PyPy" or any of the other implementations.
Yes, CPython has a special place because it's the reference
implementation and the most popular, but the one thing that makes it
distinct from all the others is that it's implemented in C.

I could, perhaps, create my own interpreter and name it "RosuavPython"
after myself, but when something's made by a team, it's usually more
useful to pick something that is fundamental to it (Brython is
designed to be run in a browser, Jython is written in Python to make
it easy to call on Java classes, etc).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Paulo da Silva]

Às 20:01 de 20/06/22, Paulo da Silva escreveu:

Às 18:19 de 20/06/22, Stefan Ram escreveu:

   The same personality traits that make people react
   to troll postings might make them spread unconfirmed
   ideas about the meaning of "C" in "CPython".

   The /core/ of CPython is written in C.

   CPython is the /canonical/ implementation of Python.

   The "C" in "CPython" stands for C.




Not so "unconfirmed"!
Look at this article, I recently read:
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/ 



There is a sentence in ther that begins with "CPython, short for Core 
Python, a reference implementation that other Python distributions are 
derived from, ...".


Anyway, I wrote "IMHO".

Do you have any credible reference to your assertion "The "C" in 
"CPython" stands for C."?


Thank you.


Well ... I read the responses and they are not touching the point!
I just answered, with my opinion based on articles I have read in the 
past. Certainly I could not be sure. That's why I responded as an 
opinion (IMHO) and not as an assertion.

Stefan Ram responded with a, at least, not very polite post.
That's why I needed to somehow "defend" why I posted that response, and, 
BTW, trying to learn why he said that the C in CPython means "written in C".


I still find very strange, to not say weird, that a compiler or 
interpreter has a name based in the language it was written. But, again, 
is just my opinion and nothing more.


I rest my case.
Thank you all.
--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[dn]

On 21/06/2022 10.02, Chris Angelico wrote:
> On Tue, 21 Jun 2022 at 08:01, dn  wrote:
>>
>> On 21/06/2022 09.47, Roel Schroeven wrote:
>> ...
>>
>>> So we have an untrustworthy site that's the only one to claim that
>>> CPython is short for Core Python, and we have an official site that says
>>> CPython is so named because it's written in C. Hm, which one to believe?
>>
>>
>> ...and so you can C that the only important part is the Python!
> 
> I should have cn that coming.


Which is a terribly OT invitation to make the (these days non-PC) Monty
Python joke: "No-one expects the Spanish Inquisition"
(https://www.youtube.com/watch?v=Cj8n4MfhjUc)
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Chris Angelico]

On Tue, 21 Jun 2022 at 08:01, dn  wrote:
>
> On 21/06/2022 09.47, Roel Schroeven wrote:
> ...
>
> > So we have an untrustworthy site that's the only one to claim that
> > CPython is short for Core Python, and we have an official site that says
> > CPython is so named because it's written in C. Hm, which one to believe?
>
>
> ...and so you can C that the only important part is the Python!

I should have cn that coming.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Chris Angelico]

On Tue, 21 Jun 2022 at 07:48, Roel Schroeven  wrote:
>
> Paulo da Silva schreef op 20/06/2022 om 21:01:
> > Às 18:19 de 20/06/22, Stefan Ram escreveu:
> > >The same personality traits that make people react
> > >to troll postings might make them spread unconfirmed
> > >ideas about the meaning of "C" in "CPython".
> > >
> > >The /core/ of CPython is written in C.
> > >
> > >CPython is the /canonical/ implementation of Python.
> > >
> > >The "C" in "CPython" stands for C.
> > >
> > >
> >
> > Not so "unconfirmed"!
> > Look at this article, I recently read:
> > https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/
> >
> > There is a sentence in ther that begins with "CPython, short for Core
> > Python, a reference implementation that other Python distributions are
> > derived from, ...".
>
> Counterpoint: https://wiki.python.org/moin/SummerOfCode/2017/python-core
> says "The reference implementation of Python is CPython, so named
> because it's written in C." Even in the absence of other evidence I'd
> much rather trust a python.org page than a www.analyticsinsight.net page
> on the subject of Python implementations.

Be aware that this is a wiki, so anyone can edit it. But that also
means you can check the "Info" link to see the history of the page,
and in this case, the text in question was added by user TerriOda, who
- as can be confirmed in various places - is heavily involved in GSOC
Python projects and the like, so I would consider this to be fairly
good information.

(Though I can't honestly say whether many of the core Python devs read
that wiki, so it's always possible that false information stays there
untouched.)

> But there's more.
>
> Apart from www.analyticsinsight.net I can't find any website that
> mentions "Core Python" as a Python implementation. That's a strong
> indication that www.analyticsinsight.net is wrong on that point. Frankly
> that website seems very low quality in general. In that same article
> they say:
>
> "CPython is a descendant of Pyscript built on Pyodide, a port of
> CPython, or a Python distribution for the browser and Node.js that is
> based on Webassembly and Emscripten."
>
> CPython is definitely not a descendant of Pyscript! Looks like someone
> found something (semi-) interesting and tried to write something
> insightful about it, but without really understanding any of it. Other
> articles don't seem to be any better.
>
> So we have an untrustworthy site that's the only one to claim that
> CPython is short for Core Python, and we have an official site that says
> CPython is so named because it's written in C. Hm, which one to believe?
>

I think that's about as settled as it'll ever be. Like many things, it
doesn't necessarily have any stronger origin than "someone started
using the term, and it stuck". Reminds me of trying to research the
origin of the name "Idle" (or "IDLE" - the Integrated Development and
Learning Environment") and being unable to find any proof that it was
named after a certain Eric, but nothing to disprove it either...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[dn]

On 21/06/2022 09.47, Roel Schroeven wrote:
...

> So we have an untrustworthy site that's the only one to claim that
> CPython is short for Core Python, and we have an official site that says
> CPython is so named because it's written in C. Hm, which one to believe?


...and so you can C that the only important part is the Python!
-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Roel Schroeven]

Paulo da Silva schreef op 20/06/2022 om 21:01:

Às 18:19 de 20/06/22, Stefan Ram escreveu:
>The same personality traits that make people react
>to troll postings might make them spread unconfirmed
>ideas about the meaning of "C" in "CPython".
> 
>The /core/ of CPython is written in C.
> 
>CPython is the /canonical/ implementation of Python.
> 
>The "C" in "CPython" stands for C.
> 
> 


Not so "unconfirmed"!
Look at this article, I recently read:
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/

There is a sentence in ther that begins with "CPython, short for Core
Python, a reference implementation that other Python distributions are
derived from, ...".


Counterpoint: https://wiki.python.org/moin/SummerOfCode/2017/python-core 
says "The reference implementation of Python is CPython, so named 
because it's written in C." Even in the absence of other evidence I'd 
much rather trust a python.org page than a www.analyticsinsight.net page 
on the subject of Python implementations.


But there's more.

Apart from www.analyticsinsight.net I can't find any website that 
mentions "Core Python" as a Python implementation. That's a strong 
indication that www.analyticsinsight.net is wrong on that point. Frankly 
that website seems very low quality in general. In that same article 
they say:


"CPython is a descendant of Pyscript built on Pyodide, a port of 
CPython, or a Python distribution for the browser and Node.js that is 
based on Webassembly and Emscripten."


CPython is definitely not a descendant of Pyscript! Looks like someone 
found something (semi-) interesting and tried to write something 
insightful about it, but without really understanding any of it. Other 
articles don't seem to be any better.


So we have an untrustworthy site that's the only one to claim that 
CPython is short for Core Python, and we have an official site that says 
CPython is so named because it's written in C. Hm, which one to believe?


--
"In the old days, writers used to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Chris Angelico]

On Tue, 21 Jun 2022 at 06:31, Stefan Ram  wrote:
>
> Paulo da Silva  writes:
> >Do you have any credible reference to your assertion "The "C" in
> >"CPython" stands for C."?
>
>   Whether a source is considered "credible" is something
>   everyone must decide for themselves.
>
>   I can say that the overwhelming majority of results of Web
>   searches about this topic yields expressions of the view
>   that the "C" in "CPython" stands for C, "overwhelming
>   majority" when compared to expressions of other interpretations
>   of that "C", and "overwhelming majority" meaning something
>   like more than 90 percent.
>
>   For one example, there seems to be a book "CPython Internals"
>   which seems to say, according to one Web search engine:
>
> |The C in CPython is a reference to the C programming
> |language, indicating that this Python distribution is
> |written in the C language.
>

Does python.org count as "credible"?

https://docs.python.org/3/reference/introduction.html

CPython: This is the original and most-maintained implementation of
Python, written in C.

I think that's about as close as you're going to get to an answer.
Given that it is, in that page, being distinguished from Jython
(implemented in Python), PyPy (implemented in Python), Python for .NET
(implemented for the .NET runtime), and IronPython (one of these is
not like the others, whatever, but it's the one originally implemented
for .NET), it seems fairly safe to say that the C in CPython means the
implementation language.

If someone wants to contradict this, they'll need a strong source,
like a post from a core dev back when Jython was brand new.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Dennis Lee Bieber]

On Mon, 20 Jun 2022 20:01:51 +0100, Paulo da Silva
 declaimed the following:


>Not so "unconfirmed"!
>Look at this article, I recently read:
>https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/
>
>There is a sentence in ther that begins with "CPython, short for Core 
>Python, a reference implementation that other Python distributions are 
>derived from, ...".
>
>Anyway, I wrote "IMHO".
>
>Do you have any credible reference to your assertion "The "C" in 
>"CPython" stands for C."?
>

Well, let's start at the top...

https://www.python.org/download/alternatives/ ("traditional" implying
implemented in C).
https://en.wikipedia.org/wiki/CPython

https://stackoverflow.com/questions/17130975/python-vs-cpython
https://www.c-sharpcorner.com/article/why-learn-python-an-introduction-to-python/
https://www.geeksforgeeks.org/difference-various-implementations-python/

There is some plagiarism between a number of web-sites, but they all
emphasize the "CPython" is a reference implementation and that it is
written in C vs Java (Jython), C# (IronPython -- which M$ may be
deprecating these days, based on some stuff in my last Visual Studio
update), or other


-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "CPython"

[Paulo da Silva]

Às 18:19 de 20/06/22, Stefan Ram escreveu:

   The same personality traits that make people react
   to troll postings might make them spread unconfirmed
   ideas about the meaning of "C" in "CPython".

   The /core/ of CPython is written in C.

   CPython is the /canonical/ implementation of Python.

   The "C" in "CPython" stands for C.




Not so "unconfirmed"!
Look at this article, I recently read:
https://www.analyticsinsight.net/cpython-to-step-over-javascript-in-developing-web-applications/

There is a sentence in ther that begins with "CPython, short for Core 
Python, a reference implementation that other Python distributions are 
derived from, ...".


Anyway, I wrote "IMHO".

Do you have any credible reference to your assertion "The "C" in 
"CPython" stands for C."?


Thank you.
--
https://mail.python.org/mailman/listinfo/python-list

RE: cpython and python and visual studio 2019

[jschwar]

Never mind.  I figured it out myself.  It's not documented very well.  

 

From: jsch...@sbcglobal.net  
Sent: Thursday, June 9, 2022 11:17 AM
To: 'python-list@python.org' 
Subject: cpython and python and visual studio 2019

 

I contacted Visual Studio 2019 support about this and they referred me to
this site, but I'm not sure this is a bug or not
(https://github.com/python/cpython/issues/new?assignees=
 =type-bug=bug.md).  If I should open a bug
request, please let me know and I will.  

 

I'm not new to python, but I'm new to cpython and visual studio.  I need to
install Visual Studio 2019 and get the PCBuild/get_external.bat file up and
running.  I have python 3.10.4 installed.  I tried installing the Community
version of Visual Studio 2019 version 16.11, but from what I understand,
it's supposed to create a folder in my python directory called PCBuild with
that bat file in it and it doesn't.  I've searched my C drive for PCBuild
and get_external.bat and nothing is found.  

 

I've executed this command and from what I can tell, I have installed the
correct version of Visual Studio:

 

python -c "import sys; print(sys.version)"

3.10.4 (tags/v3.10.4:9d38120, Mar 23 2022, 23:13:41) [MSC v.1929 64 bit
(AMD64)]

 

This website says to install version 16.11:
https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B

 

I did select the following options when installing Visual Studio 2019:

 

Workloads:

 

Python Development

Desktop Development with C++

 

Under python development I have selected the following:

 

Python native development tools

Python web support

Live Share

Python 3 64-bit (3.9.7)

 

Under Desktop Development with C++ I have selected the following:

 

Included:

C++ Core Desktop features

 

Optional:

MSVC v142 VS 2019 C++ x64/x86 build

Windows 10 SDK (10.0.19041.0)

Just-In-Time debugger

C++ Profiling tools

C++ CMake tools for Windows

C++ ATL for latest v142 build tools

Test Adapter for Boost.Test

Test adapter for Google Test

Live Share

IntelliCode

C++ AddressSanitizer

Windows 10 SDK (10.0.18362.0)

 

Can someone please help me on this?  Like I said, if I should open a bug
report, please let me know and I will.

 

 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Cpython: when to incref before insertdict

[Marco Sulla]

On Sun, 6 Mar 2022 at 03:20, Inada Naoki  wrote:
> In general, when reference is borrowed from a caller, the reference is
> available during the API.
> But merge_dict borrows reference of key/value from other dict, not caller.
> [...]
> Again, insertdict takes the reference. So _PyDict_FromKeys() **does**
> INCREF before calling insertdict, when key/value is borrowed
> reference.
> https://github.com/python/cpython/blob/6927632492cbad86a250aa006c1847e03b03e70b/Objects/dictobject.c#L2287-L2290
> https://github.com/python/cpython/blob/6927632492cbad86a250aa006c1847e03b03e70b/Objects/dictobject.c#L2309-L2311
>
> On the other hand, slow path uses PyIter_Next() which returns strong
> reference. So no need to INCREF it.

Thank you Inada, these points make me things clear now.
(PS: dictobject will change a lot in 3.11... sigh :D)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Cpython: when to incref before insertdict

[Inada Naoki]

On Sat, Mar 5, 2022 at 11:22 PM Marco Sulla
 wrote:
>
> I noticed that some functions inside dictobject.c that call insertdict
> or PyDict_SetItem do an incref of key and value before the call, and a
> decref after it. An example is dict_merge.

First of all, insertdict and PyDict is totally different about
reference ownership handling.

* PyDict_SetItem borrows reference of key and value from the caller as
usual Python/C APIs. And it INCREF them before calling the
insertdict().
* insertdict() takes the reference from its caller. In other words,
insertdict() moves the owner of reference from its caller to the dict.

merge_dict is very special and complex case.
I assume you are talking about this part.
https://github.com/python/cpython/blob/6927632492cbad86a250aa006c1847e03b03e70b/Objects/dictobject.c#L2885-L2912

In general, when reference is borrowed from a caller, the reference is
available during the API.
But merge_dict borrows reference of key/value from other dict, not caller.
So dict_merge must have strong reference of key/value by INCREF before
calling any APIs (e.g. _PyDict_Contains_KnownHash).
That's why dict_merge calls INCREF key/value **twice** before calling
insertdict, and DECREF key/value **once** after it.

> Other functions, such as
> _PyDict_FromKeys, don't do an incref before.
>

Again, insertdict takes the reference. So _PyDict_FromKeys() **does**
INCREF before calling insertdict, when key/value is borrowed
reference.
https://github.com/python/cpython/blob/6927632492cbad86a250aa006c1847e03b03e70b/Objects/dictobject.c#L2287-L2290
https://github.com/python/cpython/blob/6927632492cbad86a250aa006c1847e03b03e70b/Objects/dictobject.c#L2309-L2311

On the other hand, slow path uses PyIter_Next() which returns strong
reference. So no need to INCREF it.
Additionally, the slow path uses PyDict_SetItem(), not insertdict().
PyDict_SetItem() does INCREF key/value for insertdict.
So the slow path need to DECREF(key).
https://github.com/python/cpython/blob/6927632492cbad86a250aa006c1847e03b03e70b/Objects/dictobject.c#L2327-L2329

This is complete guide why/when INCREF/DECREF key/value.
-- 
Inada Naoki  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: CPython / Decimal and bit length of value.

[jak]

Il 03/09/2021 22:09, Nacnud Nac ha scritto:

Hi,
Is there a quick way to get the number of bits required to store the value in a 
Decimal class?
What obvious thing am I missing? I'm working with really large integers, say, 
in the order of 5_000_000 of ASCII base 10 digits.
It seems the function mpd_sizeinbase would be a nice thing to be able to 
call.
It'd be nice to just be able to tell the "size of data", or something like that, that was 
stored in the *data? I note there is len "field" in the structure mpd_t
Sorry for the dumb question
Thanks,Duncan


to semplfy the example I'll use the value 100:

value="100"

exponent in base 10 is len(value) - 1 # (1 * 10^6)

now need change from base 10 to base 2: newexp = 6 / log(2) # 19 (more 
or less)


you will need newexp + 1 bits to represent the number: 2^20 = 1.048.576

hope helps


--
https://mail.python.org/mailman/listinfo/python-list

Re: CPython compiled failed in macOS

[Inada Naoki]

You may need to clean your source tree.  "make distclean" or "git clean -fx".

2019年5月22日(水) 13:34 Windson Yang :
>
> version: macOS 10.14.4, Apple LLVM version 10.0.1 (clang-1001.0.46.4).
>
> I cloned the CPython source code from GitHub then compiled it which used to
> work quite well. However, I messed up my terminal a few days ago for
> installing gdb. Now when I try to compile the latest CPython source code
> with ./configure --with-pydebug && make -j I always get the error messages:
>
> ld: warning: ld: warning: ignoring file libpython3.8d.a, file was
> built for archive which is not the architecture being linked (x86_64):
> libpython3.8d.aignoring file libpython3.8d.a, file was built for
> archive which is not the architecture being linked (x86_64):
> libpython3.8d.a
> Undefined symbols for architecture x86_64:
>   "__Py_UnixMain", referenced from:
>   _main in python.o
> ld: symbol(s) not found for architecture x86_64Undefined symbols for
> architecture x86_64:
>   "_PyEval_InitThreads", referenced from:
>   _test_repeated_init_and_subinterpreters in _testembed.o
>   "_PyEval_ReleaseThread", referenced from:
>   _test_repeated_init_and_subinterpreters in _testembed.o
>   "_PyEval_RestoreThread", referenced from:
>   _test_repeated_init_and_subinterpreters in _testembed.o
>   _test_bpo20891 in _testembed.o
>   "_PyEval_SaveThread", referenced from:
>   _test_bpo20891 in _testembed.o
>   "_PyGILState_Check", referenced from:
>   _bpo20891_thread in _testembed.o
>   "_PyGILState_Ensure", referenced from:
>   _test_repeated_init_and_subinterpreters in _testembed.o
>   _bpo20891_thread in _testembed.o
>   "_PyGILState_Release", referenced from:
>   _test_repeated_init_and_subinterpreters in _testembed.o
>   _bpo20891_thread in _testembed.o
>   "_PyInterpreterState_GetID", referenced from:
>   _print_subinterp in _testembed.o
>   "_PyMem_RawFree", referenced from:
>   _test_pre_initialization_api in _testembed.o
>   "_PyRun_SimpleStringFlags", referenced from:
>   _test_pre_initialization_api in _testembed.o
>   _test_pre_initialization_sys_options in _testembed.o
>   _test_init_main in _testembed.o
>   _check_stdio_details in _testembed.o
>   _print_subinterp in _testembed.o
>   _dump_config in _testembed.o
>   "_PySys_AddWarnOption", referenced from:
>   _test_pre_initialization_sys_options in _testembed.o
>   "_PySys_AddXOption", referenced from:
>   _test_pre_initialization_sys_options in _testembed.o
>   "_PySys_ResetWarnOptions", referenced from:
>   _test_pre_initialization_sys_options in _testembed.o
>   "_PyThreadState_Get", referenced from:
>   _test_repeated_init_and_subinterpreters in _testembed.o
>   _print_subinterp in _testembed.o
>   "_PyThreadState_Swap", referenced from:
>   _test_repeated_init_and_subinterpreters in _testembed.o
>   "_PyThread_acquire_lock", referenced from:
>   _test_bpo20891 in _testembed.o
>   "_PyThread_allocate_lock", referenced from:
>   _test_bpo20891 in _testembed.o
>   "_PyThread_exit_thread", referenced from:
>   _bpo20891_thread in _testembed.o
>   "_PyThread_free_lock", referenced from:
>   _test_bpo20891 in _testembed.o
>   "_PyThread_release_lock", referenced from:
>   _bpo20891_thread in _testembed.o
>   "_PyThread_start_new_thread", referenced from:
>   _test_bpo20891 in _testembed.o
>   "_Py_BytesWarningFlag", referenced from:
>   _test_init_global_config in _testembed.o
>   _test_init_from_config in _testembed.o
>   _set_all_global_config_variables in _testembed.o
>   "_Py_DebugFlag", referenced from:
>   _set_all_global_config_variables in _testembed.o
>   "_Py_DecodeLocale", referenced from:
>   _test_pre_initialization_api in _testembed.o
>   "_Py_DontWriteBytecodeFlag", referenced from:
>   _test_init_global_config in _testembed.o
>   _test_init_from_config in _testembed.o
>   _set_all_global_config_variables in _testembed.o
>   _check_init_python_config in _testembed.o
>   "_Py_EndInterpreter", referenced from:
>   _test_repeated_init_and_subinterpreters in _testembed.o
>   "_Py_Finalize", referenced from:
>   _test_forced_io_encoding in _testembed.o
>   _test_repeated_init_and_subinterpreters in _testembed.o
>   _test_pre_initialization_api in _testembed.o
>   _test_pre_initialization_sys_options in _testembed.o
>   _test_initialize_twice in _testembed.o
>   _test_initialize_pymain in _testembed.o
>   _test_init_default_config in _testembed.o
>   ...
>   "_Py_FrozenFlag", referenced from:
>   _test_init_global_config in _testembed.o
>   _test_init_from_config in _testembed.o
>   _set_all_global_config_variables in _testembed.o
>   _check_init_python_config in _testembed.o
>   "_Py_IgnoreEnvironmentFlag", referenced from:
>   _test_init_env in _testembed.o
>   _test_init_env_dev_mode in _testembed.o
>   

Re: cpython version

[Larry Martell]

On Sun, Aug 13, 2017 at 10:59 PM, Gilmeh Serda
 wrote:
> On Sat, 12 Aug 2017 10:24:06 -0400, Larry Martell wrote:
>
>> now I have prospective client that refuses to run linux, even in a VM.
>> So I am tying to get my app running on Windows Server 2016, piece by
>> painful piece.
>
> I hope you charge them an arm and a leg for it! :)

Both arms and both legs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: cpython version

[Larry Martell]

On Sat, Aug 12, 2017 at 10:09 AM, Chris Angelico  wrote:
> On Sat, Aug 12, 2017 at 10:24 PM, Larry Martell  
> wrote:
>> On Sat, Aug 12, 2017 at 8:22 AM, Larry Martell  
>> wrote:
>>> For the first time in my 30+ year career I am, unfortunately, working
>>> on Windows.  A package I need, rpy2, comes in various flavors for
>>> different cpython versions:
>>>
>>> rpy2‑2.7.8‑cp27‑none‑win32.whl
>>> rpy2‑2.7.8‑cp27‑none‑win_amd64.whl
>>> rpy2‑2.7.8‑cp34‑none‑win32.whl
>>> rpy2‑2.7.8‑cp34‑none‑win_amd64.whl
>>> rpy2‑2.7.8‑cp35‑none‑win32.whl
>>> rpy2‑2.7.8‑cp35‑none‑win_amd64.whl
>>> rpy2‑2.8.6‑cp35‑cp35m‑win32.whl
>>> rpy2‑2.8.6‑cp35‑cp35m‑win_amd64.whl
>>> rpy2‑2.8.6‑cp36‑cp36m‑win32.whl
>>> rpy2‑2.8.6‑cp36‑cp36m‑win_amd64.whl
>>>
>>> I am running python version 2.7.13. How can I find out my cpython version?
>>
>> Never mind - not enough sleep or coffee. Obviously cp27 for python 2.7.
>
> Correct. I'd take it one further, though, and suggest that you
> shouldn't need to match it yourself; just use pip to download and
> install the right wheel. It'll match versions, architectures, and
> anything else it needs to match.

Problem is that rpy2 will not install with pip. It gets:

Error: Tried to guess R's HOME but no command 'R' in the PATH.

Even though R's HOME is in the PATH.

Googling this I found it's a very common problem, with no solution I
could find. I finally found a post by the author of rpy that says
"There is no official support for Windows,". and he refers people to
this site http://www.lfd.uci.edu/~gohlke/pythonlibs/#rpy2 that has
'unofficial and unstable' prebuilt windows binaries for it.

If anyone is interested as to why I am embarking on this very
unpleasant task, I have a django app that runs in linux. I have
successfully deployed it with Docker, vagrant/VirtualBox, VMware, kvm,
and on bare metal. But now I have prospective client that refuses to
run linux, even in a VM. So I am tying to get my app running on
Windows Server 2016, piece by painful piece.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: cpython version

[Chris Angelico]

On Sat, Aug 12, 2017 at 10:24 PM, Larry Martell  wrote:
> On Sat, Aug 12, 2017 at 8:22 AM, Larry Martell  
> wrote:
>> For the first time in my 30+ year career I am, unfortunately, working
>> on Windows.  A package I need, rpy2, comes in various flavors for
>> different cpython versions:
>>
>> rpy2‑2.7.8‑cp27‑none‑win32.whl
>> rpy2‑2.7.8‑cp27‑none‑win_amd64.whl
>> rpy2‑2.7.8‑cp34‑none‑win32.whl
>> rpy2‑2.7.8‑cp34‑none‑win_amd64.whl
>> rpy2‑2.7.8‑cp35‑none‑win32.whl
>> rpy2‑2.7.8‑cp35‑none‑win_amd64.whl
>> rpy2‑2.8.6‑cp35‑cp35m‑win32.whl
>> rpy2‑2.8.6‑cp35‑cp35m‑win_amd64.whl
>> rpy2‑2.8.6‑cp36‑cp36m‑win32.whl
>> rpy2‑2.8.6‑cp36‑cp36m‑win_amd64.whl
>>
>> I am running python version 2.7.13. How can I find out my cpython version?
>
> Never mind - not enough sleep or coffee. Obviously cp27 for python 2.7.

Correct. I'd take it one further, though, and suggest that you
shouldn't need to match it yourself; just use pip to download and
install the right wheel. It'll match versions, architectures, and
anything else it needs to match.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: cpython version

[Larry Martell]

On Sat, Aug 12, 2017 at 8:22 AM, Larry Martell  wrote:
> For the first time in my 30+ year career I am, unfortunately, working
> on Windows.  A package I need, rpy2, comes in various flavors for
> different cpython versions:
>
> rpy2‑2.7.8‑cp27‑none‑win32.whl
> rpy2‑2.7.8‑cp27‑none‑win_amd64.whl
> rpy2‑2.7.8‑cp34‑none‑win32.whl
> rpy2‑2.7.8‑cp34‑none‑win_amd64.whl
> rpy2‑2.7.8‑cp35‑none‑win32.whl
> rpy2‑2.7.8‑cp35‑none‑win_amd64.whl
> rpy2‑2.8.6‑cp35‑cp35m‑win32.whl
> rpy2‑2.8.6‑cp35‑cp35m‑win_amd64.whl
> rpy2‑2.8.6‑cp36‑cp36m‑win32.whl
> rpy2‑2.8.6‑cp36‑cp36m‑win_amd64.whl
>
> I am running python version 2.7.13. How can I find out my cpython version?

Never mind - not enough sleep or coffee. Obviously cp27 for python 2.7.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: CPython Class variable exposed to Python is altered.

[Vincent Vande Vyvre]

Le 12/04/17 à 11:47, Peter Otten a écrit :

Vincent Vande Vyvre wrote:



No, no warning.


For the truth, this code is copy-pasted from the doc.

https://docs.python.org/3.5//extending/newtypes.html#adding-data-and-methods-to-the-basic-example

But the example expects objects (the big O), not strings. Following the
example you need

  if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|", kwlist, ))
  return -1;

and also

static PyMemberDef Test_members[] = {
  {"name", T_OBJECT_EX, offsetof(Test, name), 0,
   "The object name"},
  {NULL}  /* Sentinel */
};

If you want a string instead of an object you must not apply Py_INCREF(),
you probably have to manage its lifetime yourself.



I've just installed a new venv with the 3.6.1 and tested your changes.

And now, that's all right.

I see the devil is into the details ...


Many thanks Peter


Vincent

--
https://mail.python.org/mailman/listinfo/python-list

Re: CPython Class variable exposed to Python is altered.

[Peter Otten]

Vincent Vande Vyvre wrote:

> Le 12/04/17 à 10:51, Peter Otten a écrit :
>> Vincent Vande Vyvre wrote:
>>
>>> Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit :
 Hi,

 Learning CPython, I've made this simple exercice, a module test which
 contains an object Test.

 The object Test has an attribute name, fixed at instanciation.

 So, I try my code with a script:

 ---
 from test import Test

 for n in ("The name", "Foo", "Spam"):
  t = Test(n)
  print("%s --> %s" %(n, t.name))
 ---

 And the return:

 Uhe name --> Uhe name
 Goo --> Goo
 Tpam --> Tpam

 As we can see, the first letter is changed with the next letter in
 alphabetical order, but not only for the attribute name, also for the
 reference n.
>>>   if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|", kwlist, ))
>>>   return -1;
>>>
>>>   if (name) {
>>>   tmp = self->name;
>>>   Py_INCREF(name);
>> While I don't know how to do this properly you seem to be applying
>> Py_INCREF() to a C string rather than a Python string object. C being C
>> you can cast anything to anything else...
>>
>> Aren't there any warnings at compile time?
>>
> 
> No, no warning.
> 
> 
> For the truth, this code is copy-pasted from the doc.
> 
> https://docs.python.org/3.5//extending/newtypes.html#adding-data-and-methods-to-the-basic-example

But the example expects objects (the big O), not strings. Following the 
example you need

 if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|", kwlist, ))
 return -1;

and also

static PyMemberDef Test_members[] = {
 {"name", T_OBJECT_EX, offsetof(Test, name), 0,
  "The object name"},
 {NULL}  /* Sentinel */
};

If you want a string instead of an object you must not apply Py_INCREF(), 
you probably have to manage its lifetime yourself.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: CPython Class variable exposed to Python is altered.

[Vincent Vande Vyvre]

Le 12/04/17 à 10:51, Peter Otten a écrit :

Vincent Vande Vyvre wrote:


Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit :

Hi,

Learning CPython, I've made this simple exercice, a module test which
contains an object Test.

The object Test has an attribute name, fixed at instanciation.

So, I try my code with a script:

---
from test import Test

for n in ("The name", "Foo", "Spam"):
 t = Test(n)
 print("%s --> %s" %(n, t.name))
---

And the return:

Uhe name --> Uhe name
Goo --> Goo
Tpam --> Tpam

As we can see, the first letter is changed with the next letter in
alphabetical order, but not only for the attribute name, also for the
reference n.

  if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|", kwlist, ))
  return -1;

  if (name) {
  tmp = self->name;
  Py_INCREF(name);

While I don't know how to do this properly you seem to be applying
Py_INCREF() to a C string rather than a Python string object. C being C you
can cast anything to anything else...

Aren't there any warnings at compile time?



No, no warning.


For the truth, this code is copy-pasted from the doc.

https://docs.python.org/3.5//extending/newtypes.html#adding-data-and-methods-to-the-basic-example


Vincent

--
https://mail.python.org/mailman/listinfo/python-list

Re: CPython Class variable exposed to Python is altered.

[Peter Otten]

Vincent Vande Vyvre wrote:

> Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit :
>> Hi,
>>
>> Learning CPython, I've made this simple exercice, a module test which
>> contains an object Test.
>>
>> The object Test has an attribute name, fixed at instanciation.
>>
>> So, I try my code with a script:
>>
>> ---
>> from test import Test
>>
>> for n in ("The name", "Foo", "Spam"):
>> t = Test(n)
>> print("%s --> %s" %(n, t.name))
>> ---
>>
>> And the return:
>>
>> Uhe name --> Uhe name
>> Goo --> Goo
>> Tpam --> Tpam
>>
>> As we can see, the first letter is changed with the next letter in
>> alphabetical order, but not only for the attribute name, also for the
>> reference n.

>  if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|", kwlist, ))
>  return -1;
> 
>  if (name) {
>  tmp = self->name;
>  Py_INCREF(name);

While I don't know how to do this properly you seem to be applying 
Py_INCREF() to a C string rather than a Python string object. C being C you 
can cast anything to anything else...

Aren't there any warnings at compile time?

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: CPython Class variable exposed to Python is altered.

[Vincent Vande Vyvre]

Le 12/04/17 à 08:57, Vincent Vande Vyvre a écrit :

Hi,

Learning CPython, I've made this simple exercice, a module test which 
contains an object Test.


The object Test has an attribute name, fixed at instanciation.

So, I try my code with a script:

---
from test import Test

for n in ("The name", "Foo", "Spam"):
t = Test(n)
print("%s --> %s" %(n, t.name))
---

And the return:

Uhe name --> Uhe name
Goo --> Goo
Tpam --> Tpam

As we can see, the first letter is changed with the next letter in 
alphabetical order, but not only for the attribute name, also for the 
reference n.


Same into a console:

(py352_venv) vincent@djoliba:~/CPython/py352_venv/pydcraw$ python
Python 3.5.2 (default, Dec 19 2016, 11:46:33)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from test import Test
>>> for n in ("The name", "Foo", "Spam"):
... t = Test(n)
... print("%s --> %s" %(n, t.name))
...
Uhe name --> Uhe name
Goo --> Goo
Tpam --> Tpam


I'm working in a venv.

The testmodule.c is attached.


The setup.py

from distutils.core import setup, Extension
setup(name="test", version="1.0",
  ext_modules=[
 Extension("test", ["testmodule.c"],
   libraries=[])
 ])



Best,


Vincent


I see the attachement is rejected.


This is the testmodule.c

---

#include 
#include "structmember.h"


typedef struct {
PyObject_HEAD
PyObject *name;
} Test;

static void
Test_dealloc(Test* self)
{
Py_XDECREF(self->name);
}

static PyObject *
Test_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
Test *self;

self = (Test *)type->tp_alloc(type, 0);
if (self != NULL){
self->name = PyUnicode_FromString("");
if (self->name == NULL){
Py_DECREF(self);
return NULL;
}
}

return (PyObject *)self;
}

static int
Test_init(Test *self, PyObject *args, PyObject *kwds)
{
PyObject *name, *tmp;
static char *kwlist[] = {"name", NULL};

if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|", kwlist, ))
return -1;

if (name) {
tmp = self->name;
Py_INCREF(name);
self->name = name;
Py_XDECREF(tmp);
}

return 0;
}

static PyMemberDef Test_members[] = {
{"name", T_STRING, offsetof(Test, name), 0,
 "The object name"},
{NULL}  /* Sentinel */
};

static PyMethodDef Test_methods[] = {
{NULL} /* sentinel */
};

static PyTypeObject TestType = {
PyVarObject_HEAD_INIT(NULL, 0)
"test.Test",  /* tp_name */
sizeof(Test), /* tp_basicsize */
0,/* tp_itemsize */
(destructor)Test_dealloc, /* tp_dealloc */
0,/* tp_print */
0,/* tp_getattr */
0,/* tp_setattr */
0,/* tp_reserved */
0,/* tp_repr */
0,/* tp_as_number */
0,/* tp_as_sequence */
0,/* tp_as_mapping */
0,/* tp_hash  */
0,/* tp_call */
0,/* tp_str */
0,/* tp_getattro */
0,/* tp_setattro */
0,/* tp_as_buffer */
Py_TPFLAGS_DEFAULT |
Py_TPFLAGS_BASETYPE,  /* tp_flags */
"Test object",/* tp_doc */
0,/* tp_traverse */
0,/* tp_clear */
0,/* tp_richcompare */
0,/* tp_weaklistoffset */
0,/* tp_iter */
0,/* tp_iternext */
Test_methods, /* tp_methods */
Test_members, /* tp_members */
0,/* tp_getset */
0,/* tp_base */
0,/* tp_dict */
0,/* tp_descr_get */
0,/* tp_descr_set */
0,/* tp_dictoffset */
(initproc)Test_init,  /* tp_init */
0,/* tp_alloc */
Test_new, /* tp_new */
};

static PyModuleDef testmodule = {
PyModuleDef_HEAD_INIT,
"test",
"Example module.",
-1,
NULL, NULL, NULL, NULL, NULL
};

PyMODINIT_FUNC
PyInit_test(void)
{
PyObject* m;

if (PyType_Ready() < 0)
return NULL;

m = PyModule_Create();
if (m == NULL)
return NULL;

Py_INCREF();

Re: CPython 2.7: Weakset data changing size during internal iteration

[Steven D'Aprano]

On Fri, 01 Jun 2012 20:24:30 -0700, Temia Eszteri wrote:

 On 02 Jun 2012 03:05:01 GMT, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 
I doubt that very much. If you are using threads, it is more likely your
code has a race condition where you are modifying a weak set at the same
time another thread is trying to iterate over it (in this case, to
determine it's length), and because it's a race condition, it only
happens when conditions are *just right*. Since race conditions hitting
are usually rare, you only notice it when there's a lot of data.
 
 Except that the few threads I use don't modify that data at all 
[...]

And should I have known this from your initial post?


[...]
 Don't be so fast to dismiss things when the situation would not have
 made a race condition possible to begin with.

If you have been part of this newsgroup and mailing list as long as I 
have, you should realise that there is no shortage of people who come 
here and make grand claims that they have discovered a bug in Python 
(either the language, or the standard library). Nine times out of ten, 
they have not, and the bug is in their code, or their understanding.

Perhaps you are one of the few who has actually found a bug in the 
standard library rather than one in your own code. But your initial post 
showed no sign that you had done any investigation beyond reading the 
traceback and immediately jumping to the conclusion that it was a bug in 
the standard library.

Frankly, I still doubt that your analysis of the problem is correct:

[quote]
Problem is that for certain high-frequency operations, it 
seems there's too much data going in and out for it to handle
[end quote]


I still can't see any way for this bug to occur due to too much data, 
as you suggest, or in the absence of one thread modifying the set while 
another is iterating over it. But I could be wrong.

In any case, it appears that this bug has already been reported and fixed:

http://bugs.python.org/issue14159


Consider updating to the latest bug fix of 2.7.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython 2.7: Weakset data changing size during internal iteration

[Temia Eszteri]

On 03 Jun 2012 16:20:11 GMT, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:

And should I have known this from your initial post?

I did discuss the matter with Terry Reedy, actually, but I guess since
the newsgroup-to-mailing list mirror is one-way, there's no actual way
you could've known. :/ Sigh, another problem out of my hands to deal
with. I do apologize for the snippy attitude, if it means anything.

Frankly, I still doubt that your analysis of the problem is correct:

[quote]
Problem is that for certain high-frequency operations, it 
seems there's too much data going in and out for it to handle
[end quote]


I still can't see any way for this bug to occur due to too much data, 
as you suggest, or in the absence of one thread modifying the set while 
another is iterating over it. But I could be wrong.

Well, in this case, I'd consider it more reasonable to look at it from
a different angle, but it was rather poorly-phrased at the beginning.
When you've got dozens of objects being garbage-collected from the set
every 16 miliseconds or so though, that's certainly high-frequency
enough to trigger the bug, is it not?

In any case, it appears that this bug has already been reported and fixed:

http://bugs.python.org/issue14159

Consider updating to the latest bug fix of 2.7.

Alas, I'm already on the latest official release, which doesn't have
the patch yet. I'll just apply it manually.

Though now I'm now curious about how regular sets get their truth
value, since weaksets internally performing a length check every time
a texture was being referenced or de-referenced, for simple lack of a
faster explicit __bool__ value, is going to be rather costly when
things'll be flying around and out of the screen area in large
quantities. Hoo boy.

~Temia
-- 
The amazing programming device: fuelled entirely by coffee, it codes while
awake and tests while asleep!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython 2.7: Weakset data changing size during internal iteration

[Terry Reedy]

On 6/1/2012 7:40 PM, Temia Eszteri wrote:


Given that len(weakset) is defined (sensibly) as the number of currently
active members, it must count. weakset should really have .__bool__
method that uses any() instead of sum(). That might reduce, but not
necessarily eliminate your problem.


Think it might be worth looking into submitting a patch for the next
minor releases for Python if it turns out to solve the problem?


I think a patch would be worthwhile even if this is not the source of 
your problem. If bool is defined as 'if any ...', that should be the code.



I can think of two reasons:

1. You are using multiple threads and another thread does something to
change the size of the set during the iteration. Solution? put a lock
around the if-statement so no other thread can change self.data during
the iteration.

2. Weakset members remove themselves from the set before returning None.
(Just a thought, in case you are not using threads).


In other words, it is possible that weakset.__len__ is buggy. Since you 
are sure that 1) is not your problem, that seems more likely now.



If the weak references removing themselves is the case, it seems like
a kind of silly problem - one would imagine they'd wrap the data check
in _IterationGuard in the _weakrefset.py file like they do for calls
to __iter__(). Very strange.


While looking into the weakset code, you might check the tracker for 
weakset issues. And also check the test code. I have *no* idea how well 
that class has been exercised and tested. Please do submit a patch if 
you can if one is needed.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: CPython 2.7: Weakset data changing size during internal iteration

[Terry Reedy]

On 6/1/2012 11:23 AM, Temia Eszteri wrote:

I've got a bit of a problem - my project uses weak sets in multiple
areas, the problem case in particular being to indicate what objects
are using a particular texture, if any, so that its priority in OpenGL
can be adjusted to match at the same time as it being (de)referenced
by any explicit calls.

Problem is that for certain high-frequency operations, it seems
there's too much data going in and out for it to handle - the
following traceback is given to me (project path changed to protect
the innocent):

Traceback (most recent call last):
   File C:\foo\bar\game.py, line 279, in update
 self.player.update()
   File C:\foo\bar\player.py, line 87, in update
 PlayerBullet((self.x + 8, self.y + 9), 0, self.parent)
   File C:\foo\bar\player.py, line 96, in __init__
 self.sprite = video.Sprite(testbullet, 0)
   File C:\foo\bar\video.py, line 95, in __init__
 self.opengl_id = reference_texture(self, target)
   File C:\foo\bar\video.py, line 310, in reference_texture
 if not video_handler.textures[target].references:


I gather that the .references attribute is sometimes/always a weakset. 
To determine its boolean value, it computes its length. For regular 
sets, this is sensible as .__len__() returns a pre-computed value.



   File C:\Python27\lib\_weakrefset.py, line 66, in __len__
 return sum(x() is not None for x in self.data)


Given that len(weakset) is defined (sensibly) as the number of currently 
active members, it must count. weakset should really have .__bool__ 
method that uses any() instead of sum(). That might reduce, but not 
necessarily eliminate your problem.



   File C:\Python27\lib\_weakrefset.py, line 66, ingenexpr
 return sum(x() is not None for x in self.data)
RuntimeError: Set changed size during iteration


I can think of two reasons:

1. You are using multiple threads and another thread does something to 
change the size of the set during the iteration. Solution? put a lock 
around the if-statement so no other thread can change self.data during 
the iteration.


2. Weakset members remove themselves from the set before returning None. 
(Just a thought, in case you are not using threads).


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: CPython 2.7: Weakset data changing size during internal iteration

[Temia Eszteri]

On Fri, 01 Jun 2012 18:42:22 -0400, Terry Reedy tjre...@udel.edu
wrote:

I gather that the .references attribute is sometimes/always a weakset. 
To determine its boolean value, it computes its length. For regular 
sets, this is sensible as .__len__() returns a pre-computed value.

Indeed. Back when I was using 2.6 to develop, it was simply an integer
counter, but that led to some difficulties in maintaining it in case
some sprite objects hadn't been explicitly killed.

Given that len(weakset) is defined (sensibly) as the number of currently 
active members, it must count. weakset should really have .__bool__ 
method that uses any() instead of sum(). That might reduce, but not 
necessarily eliminate your problem.

Think it might be worth looking into submitting a patch for the next
minor releases for Python if it turns out to solve the problem?
Failing that, I might just have to check the truth value of the data
attribute inside the weak set manually...

I can think of two reasons:

1. You are using multiple threads and another thread does something to 
change the size of the set during the iteration. Solution? put a lock 
around the if-statement so no other thread can change self.data during 
the iteration.

2. Weakset members remove themselves from the set before returning None. 
(Just a thought, in case you are not using threads).

It's a multithreaded program to a small extent - I offload I/O
operations, music handling, and a basic, optional debugger console
(which I really wish I could set up to use the real interactive
interpreter instead of the shoddy setup I've got now) to seperate
threads, while the main logic operates in one thread due to OpenGL's
issues with multiple Python threads.

Since the sprite object calls to reference a texture in __init__(),
that means no other thread could even safely reference the texture due
to the potential of making OpenGL calls without the relevant context
kept by the main thread (this has made the loading thread kind of
useless, but the texture strings themselves can still be loaded into
temporary memory, and other data like music still works).

If the weak references removing themselves is the case, it seems like
a kind of silly problem - one would imagine they'd wrap the data check
in _IterationGuard in the _weakrefset.py file like they do for calls
to __iter__(). Very strange.

Anyway, I truly appreciate your input and suggestions. I'll see if
they have any results, and if so, we can work out submitting a patch.
If not, at least reading through this gave me the idea to just call
the data set inside it, so I can use it as an imperfect but functional
solution within the scope of my project.

~Temia
--
When on earth, do as the earthlings do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython 2.7: Weakset data changing size during internal iteration

[Steven D'Aprano]

On Fri, 01 Jun 2012 08:23:44 -0700, Temia Eszteri wrote:

 I've got a bit of a problem - my project uses weak sets in multiple
 areas, the problem case in particular being to indicate what objects are
 using a particular texture, if any, so that its priority in OpenGL can
 be adjusted to match at the same time as it being (de)referenced by any
 explicit calls.
 
 Problem is that for certain high-frequency operations, it seems there's
 too much data going in and out for it to handle

I doubt that very much. If you are using threads, it is more likely your 
code has a race condition where you are modifying a weak set at the same 
time another thread is trying to iterate over it (in this case, to 
determine it's length), and because it's a race condition, it only 
happens when conditions are *just right*. Since race conditions hitting 
are usually rare, you only notice it when there's a lot of data.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython 2.7: Weakset data changing size during internal iteration

[Temia Eszteri]

On 02 Jun 2012 03:05:01 GMT, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:

I doubt that very much. If you are using threads, it is more likely your 
code has a race condition where you are modifying a weak set at the same 
time another thread is trying to iterate over it (in this case, to 
determine it's length), and because it's a race condition, it only 
happens when conditions are *just right*. Since race conditions hitting 
are usually rare, you only notice it when there's a lot of data.

Except that the few threads I use don't modify that data at all
because the functions that even touch the references set rely on
OpenGL contexts along with it which are thread-bound, ergo, impossible
to call without stopping the code in its tracks to begin with unless
the context's explicitly shifted (which it very much isn't).

And I've done some looking through the weak set's code in the
intervening time; it does easily have the potential to cause this kind
of problem because the weak references made are set to a callback to
remove them from the data set when garbage is collected. See for
yourself.:

Lines 81-84, _weakrefset.py:

def add(self, item):
if self._pending_removals:
self._commit_removals()
self.data.add(ref(item, self._remove)) --

Lines 38-44, likewise: (for some reason called in __init__ rather than
at the class level, but likely to deal with a memory management issue)

def _remove(item, selfref=ref(self)):
self = selfref()
if self is not None:
if self._iterating: --
self._pending_removals.append(item)
else:
self.data.discard(item) --
self._remove = _remove

The thing is, as Terry pointed out, its truth value is tested based on
__len__(), which as shown does NOT set the _iterating protection:

def __len__(self):
return sum(x() is not None for x in self.data)

Don't be so fast to dismiss things when the situation would not have
made a race condition possible to begin with.

~Temia
--
When on earth, do as the earthlings do.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

[Adam Tauno Williams]

On Thu, 2012-05-17 at 11:13 +1000, Chris Angelico wrote: 
 On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote:
  A record is an interesting critter -- it is given life either from the user
  or from the disk-bound data;  its fields can then change, but those changes
  are not reflected on disk until .write_record() is called;  I do this
  because I am frequently moving data from one table to another, making
  changes to the old record contents before creating the new record with the
  changes -- since I do not call .write_record() on the old record those
  changes do not get backed up to disk.
 I strongly recommend being more explicit about usage and when it gets
 written and re-read, 

You need to define a 'session' that tracks records and manages flushing.
Potentially it can hold a pool of weak references to record objects that
have been read from disk.  Record what records are 'dirty' and flush
those to disk explicitly or drop all records ('essentially rollback').
That is the only sane way to manage this.

 rather than relying on garbage collection.

+1 +1 Do *not* rely on implementation details as features.  Sooner or
later doing so will always blow-up.

 Databasing should not be tied to a language's garbage collection.
 Imagine you were to reimplement the equivalent logic in some other
 language - could you describe it clearly? If so, then that's your
 algorithm. If not, you have a problem.


signature.asc
Description: This is a digitally signed message part
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

[Ian Kelly]

On Wed, May 16, 2012 at 3:33 PM, Ethan Furman et...@stoneleaf.us wrote:
 Just hit a snag:

 In cPython the deterministic garbage collection allows me a particular
 optimization when retrieving records from a dbf file -- namely, by using
 weakrefs I can tell if the record is still in memory and active, and if so
 not hit the disk to get the data;  with PyPy (and probably the others) this
 doesn't work because the record may still be around even when it is no
 longer active because it hasn't been garbage collected yet.

 For PyPy I can use `'PyPy' in sys.version` to set a constant
 (REFRESH_FROM_DISK in this case) to disable the cPython optimization; does
 anyone know what strings to look for for the other implementations?

Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)] on win32
Type help, copyright, credits or license for more information.
 import sys
 sys.subversion
('CPython', 'tags/r271', '86832')

Jython 2.5.2 (Release_2_5_2:7206, Mar 2 2011, 23:12:06)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_31
Type help, copyright, credits or license for more information.
 import sys
 sys.subversion
('Jython', 'tags/Release_2_5_2', '7206')

I don't know what IronPython or PyPy return, but it should be
something other than 'CPython'.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

[Tim Delaney]

On 17 May 2012 07:33, Ethan Furman et...@stoneleaf.us wrote:

 Just hit a snag:

 In cPython the deterministic garbage collection allows me a particular
 optimization when retrieving records from a dbf file -- namely, by using
 weakrefs I can tell if the record is still in memory and active, and if so
 not hit the disk to get the data;  with PyPy (and probably the others) this
 doesn't work because the record may still be around even when it is no
 longer active because it hasn't been garbage collected yet.


What is the distinguishing feature of an active record? What is the
problem if you get back a reference to an inactive record? And if there is
indeed a problem, don't you already have a race condition on CPython?

1. Record is active;
2. Get reference to record through weak ref;
3. Record becomes inactive;
4. Start trying to use the (now inactive) record.

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

[Ethan Furman]

Ian Kelly wrote:

On Wed, May 16, 2012 at 3:33 PM, Ethan Furman et...@stoneleaf.us wrote:

Just hit a snag:

In cPython the deterministic garbage collection allows me a particular
optimization when retrieving records from a dbf file -- namely, by using
weakrefs I can tell if the record is still in memory and active, and if so
not hit the disk to get the data;  with PyPy (and probably the others) this
doesn't work because the record may still be around even when it is no
longer active because it hasn't been garbage collected yet.

For PyPy I can use `'PyPy' in sys.version` to set a constant
(REFRESH_FROM_DISK in this case) to disable the cPython optimization; does
anyone know what strings to look for for the other implementations?


Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)] on win32
Type help, copyright, credits or license for more information.

import sys
sys.subversion

('CPython', 'tags/r271', '86832')

Jython 2.5.2 (Release_2_5_2:7206, Mar 2 2011, 23:12:06)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_31
Type help, copyright, credits or license for more information.

import sys
sys.subversion

('Jython', 'tags/Release_2_5_2', '7206')

I don't know what IronPython or PyPy return, but it should be
something other than 'CPython'.


Thanks!  That will do the trick.  On CPython 2.4 .subversion does not 
exist, so I'll use:


subversion = getattr(sys, 'subversion', None)
if subversion is not None and subversion[0] != 'CPython':
...

Hopefully all the others do have it defined (PyPy does, at least as of 1.8).

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

[Ethan Furman]

Tim Delaney wrote:

On 17 May 2012 07:33, Ethan Furman wrote:

Just hit a snag:

In cPython the deterministic garbage collection allows me a
particular optimization when retrieving records from a dbf file --
namely, by using weakrefs I can tell if the record is still in
memory and active, and if so not hit the disk to get the data;  with
PyPy (and probably the others) this doesn't work because the record
may still be around even when it is no longer active because it
hasn't been garbage collected yet.



What is the distinguishing feature of an active record? What is the 
problem if you get back a reference to an inactive record? And if there 
is indeed a problem, don't you already have a race condition on CPython?


1. Record is active;
2. Get reference to record through weak ref;
3. Record becomes inactive;
4. Start trying to use the (now inactive) record.


A record is an interesting critter -- it is given life either from the 
user or from the disk-bound data;  its fields can then change, but those 
changes are not reflected on disk until .write_record() is called;  I do 
this because I am frequently moving data from one table to another, 
making changes to the old record contents before creating the new record 
with the changes -- since I do not call .write_record() on the old 
record those changes do not get backed up to disk.


With CPython as soon as a record goes out of scope it dies, and the next 
time I try to access that record I will get the disk version, without 
the temporary changes I had made earlier (this is good).  However, with 
PyPy (and others) not all records are destroyed before I try to access 
them again, and I end up seeing the temp data instead of the disk data.


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

[Chris Angelico]

On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote:
 A record is an interesting critter -- it is given life either from the user
 or from the disk-bound data;  its fields can then change, but those changes
 are not reflected on disk until .write_record() is called;  I do this
 because I am frequently moving data from one table to another, making
 changes to the old record contents before creating the new record with the
 changes -- since I do not call .write_record() on the old record those
 changes do not get backed up to disk.

I strongly recommend being more explicit about usage and when it gets
written and re-read, rather than relying on garbage collection.
Databasing should not be tied to a language's garbage collection.
Imagine you were to reimplement the equivalent logic in some other
language - could you describe it clearly? If so, then that's your
algorithm. If not, you have a problem.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

[Tim Delaney]

On 17 May 2012 11:13, Chris Angelico ros...@gmail.com wrote:

 On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote:
  A record is an interesting critter -- it is given life either from the
 user
  or from the disk-bound data;  its fields can then change, but those
 changes
  are not reflected on disk until .write_record() is called;  I do this
  because I am frequently moving data from one table to another, making
  changes to the old record contents before creating the new record with
 the
  changes -- since I do not call .write_record() on the old record those
  changes do not get backed up to disk.

 I strongly recommend being more explicit about usage and when it gets
 written and re-read, rather than relying on garbage collection.
 Databasing should not be tied to a language's garbage collection.
 Imagine you were to reimplement the equivalent logic in some other
 language - could you describe it clearly? If so, then that's your
 algorithm. If not, you have a problem.


Agreed. To me, this sounds like a perfect case for with: blocks and
explicit reference counting.  Something like (pseudo-python - not runnable):

class Record:
def __init__(self):
self.refs = 0
self.lock = threading.Lock()

def __enter__(self):
with self.lock:
self.refs += 1

def __exit__(self):
with self.lock:
self.refs -=1

if self.refs == 0:
self.write_record()

rest of Record class

rec = record_weakrefs.get('record_name')

if rec is None:
rec = load_record()
record_weakrefs.put('record_name', rec)

with rec:
do_stuff

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

[Ethan Furman]

Chris Angelico wrote:

On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote:

A record is an interesting critter -- it is given life either from the user
or from the disk-bound data;  its fields can then change, but those changes
are not reflected on disk until .write_record() is called;  I do this
because I am frequently moving data from one table to another, making
changes to the old record contents before creating the new record with the
changes -- since I do not call .write_record() on the old record those
changes do not get backed up to disk.


I strongly recommend being more explicit about usage and when it gets
written and re-read, rather than relying on garbage collection.
Databasing should not be tied to a language's garbage collection.
Imagine you were to reimplement the equivalent logic in some other
language - could you describe it clearly? If so, then that's your
algorithm. If not, you have a problem.


Yeah, I've been thinking about this for a couple hours now;  initially 
(way back when) I didn't want to keep hitting the disk unnecessarily 
-- but all my other supporting data structures go to great lengths to 
not keep records in memory unless the user has them explicitly named or 
contained... I think I've been fighting against myself!  Good news is 
I'm winning.  ;)


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[John Nagle]

On 4/28/2012 1:04 PM, Paul Rubin wrote:

Roy Smithr...@panix.com  writes:

I agree that application-level name cacheing is wrong, but sometimes
doing it the wrong way just makes sense.  I could whip up a simple
cacheing wrapper around getaddrinfo() in 5 minutes.  Depending on the
environment (both technology and bureaucracy), getting a cacheing
nameserver installed might take anywhere from 5 minutes to a few days to ...


IMHO this really isn't one of those times.  The in-app wrapper would
only be usable to just that process, and we already know that the OP has
multiple processes running the same app on the same machine.  They would
benefit from being able to share the cache, so now your wrapper gets
more complicated.  If it's not a nameserver then it's something that
fills in for one.  And then, since the application appears to be a large
scale web spider, it probably wants to run on a cluster, and the cache
should be shared across all the machines.  So you really probably want
an industrial strength nameserver with a big persistent cache, and maybe
a smaller local cache because of high locality when crawling specific
sites, etc.


Each process is analyzing one web site, and has its own cache.
Once the site is analyzed, which usually takes about a minute,
the cache disappears.  Multiple threads are reading multiple pages
from the web site during that time.

A local cache is enough to fix the huge overhead problem of
doing a DNS lookup for every link found.  One site with a vast
number of links took over 10 hours to analyze before this fix;
now it takes about four minutes.  That solved the problem.
We can probably get an additional minor performance boost with a real
local DNS daemon, and will probably configure one.

We recently changed servers from Red Hat to CentOS, and management
from CPanel to Webmin.  Before the change, we had a local DNS daemon
with cacheing, so we didn't have this problem.  Webmin's defaults
tend to be on the minimal side.

The DNS information is used mostly to help decide whether two URLs
actually point to the same IP address, as part of deciding whether a
link is on-site or off-site.  Most of those links will never be read.
We're not crawling the entire site, just looking at likely pages to
find the name and address of the business behind the site.  (It's
part of our Know who you're dealing with system, SiteTruth.)

John Nagle

--
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Roy Smith]

In article 7xipgj8vxh@ruckus.brouhaha.com,
 Paul Rubin no.email@nospam.invalid wrote:

 Roy Smith r...@panix.com writes:
  I agree that application-level name cacheing is wrong, but sometimes 
  doing it the wrong way just makes sense.  I could whip up a simple 
  cacheing wrapper around getaddrinfo() in 5 minutes.  Depending on the 
  environment (both technology and bureaucracy), getting a cacheing 
  nameserver installed might take anywhere from 5 minutes to a few days to ...
 
 IMHO this really isn't one of those times.  The in-app wrapper would
 only be usable to just that process, and we already know that the OP has
 multiple processes running the same app on the same machine.  They would
 benefit from being able to share the cache, so now your wrapper gets
 more complicated.

So, use memcache.  Trivial to set up, easy Python integration, and it 
has the expiration mechanism built in.  Not to mention it has a really 
cute web site (http://memcached.org/).

 Also, since this is a production application, doing something in 5
 minutes is less important than making it solid and configurable.

Maybe.  On the other hand, the time you save with a 5 minute solution 
can be spent solving other, harder, problems.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Roy Smith]

In article 7xy5pgqwto@ruckus.brouhaha.com,
 Paul Rubin no.email@nospam.invalid wrote:

 John Nagle na...@animats.com writes:
 I may do that to prevent the stall.  But the real problem was all
  those DNS requests.  Parallizing them wouldn't help much when it took
  hours to grind through them all.
 
 True dat.  But building a DNS cache into the application seems like a
 kludge.  Unless the number of requests is insane, running a caching
 nameserver on the local box seems cleaner.

I agree that application-level name cacheing is wrong, but sometimes 
doing it the wrong way just makes sense.  I could whip up a simple 
cacheing wrapper around getaddrinfo() in 5 minutes.  Depending on the 
environment (both technology and bureaucracy), getting a cacheing 
nameserver installed might take anywhere from 5 minutes to a few days to 
kicking a dead whale down the beach (if you need to involve your 
corporate IT department) to it just ain't happening (if you need to 
involve your corporate IT department).

Doing DNS cacheing correctly is non-trivial.  In fact, if you're 
building it on top of getaddrinfo(), it may be impossible, since I don't 
think getaddrinfo() exposes all the data you need (i.e. TTL values).  
But, doing a half-assed job of cache expiration is better than not 
expiring your cache at all.  I would suggest (from experience) that if 
you build a getaddrinfo() wrapper, you have cache entries time out after 
a fairly short time.  From the problem description, it sounds like using 
a 1-minute timeout would get 99% of the benefit and might keep you from 
doing some bizarre things.

PS -- I've also learned by experience that nscd can mess up.  If DNS 
starts doing stuff that doesn't make sense, my first line of attack is 
usually killing and restarting the local nscd.  Often enough, that 
solves the problem, and it rarely causes any problems that anybody would 
notice.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Danyel Lawson]

Sprinkle time.sleep(0) liberally throughout your code where you think
natural processing breaks should be.  Even in while loops. It's lame
but is the only way to make Python multithreading task switch fairly.
Your compute intensive tasks need a time.sleep(0) in their loops. This
prevents starvation and makes overall processing and responsiveness
seem properly multithreaded. This is a hand optimization so you have
to play with the location and amount of time.sleep(0)s. You'll know
when you've found a problematic spot when the queues stop
growing/overflowing.

Put the dns lookup on a separate thread pool with it's own growing
queue with lots of time.sleep(0)s sprinkled in. The dns lookups don't
have to be real time and you can easily cache them with a timestamp
attached. This is the thread pool where more is better and threads
should be aggressively terminated for having a long running process
time. This also requires lots of hand tuning for dynamically managing
the number of threads needed to process the queue in a reasonable time
if you find it hard to aggressively kill threads. I think there is a
way to launch threads that only give them a maximum lifetime. The
problem you will hit while tuning may require allocating more file
handles for all the hung sockets.

The DNS lookup is one of those things that may make sense to run as a
separate daemon process that listens on a socket. You make one
connection that feeds in the ip addresses. The daemon process feeds
back ip address/host name combinations out of order. Your main
process/connection thread builds a serialized access dict with
timestamps. The main processes threads make their requests
asynchronously and sleep while waiting for the response to appear in
the dict. They terminate after a certain time if they don't see their
response. Requires hand/algorithmic tweaking for this to work
correctly across different machines.

On Fri, Apr 27, 2012 at 2:54 PM, John Nagle na...@animats.com wrote:
    I have a multi-threaded CPython program, which has up to four
 threads.  One thread is simply a wait loop monitoring the other
 three and waiting for them to finish, so it can give them more
 work to do.  When the work threads, which read web pages and
 then parse them, are compute-bound, I've had the monitoring thread
 starved of CPU time for as long as 120 seconds.
 It's sleeping for 0.5 seconds, then checking on the other threads
 and for new work do to, so the work thread isn't using much
 compute time.

   I know that the CPython thread dispatcher sucks, but I didn't
 realize it sucked that bad.  Is there a preference for running
 threads at the head of the list (like UNIX, circa 1979) or
 something like that?

   (And yes, I know about multiprocessing.  These threads are already
 in one of several service processes.  I don't want to launch even more
 copies of the Python interpreter.  The threads are usually I/O bound,
 but when they hit unusually long web pages, they go compute-bound
 during parsing.)

   Setting sys.setcheckinterval from the default to 1 seems
 to have little effect.  This is on Windows 7.

                                John Nagle
 --
 http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Chris Angelico]

On Sat, Apr 28, 2012 at 11:46 PM, Danyel Lawson danyellaw...@gmail.com wrote:
 The DNS lookup is one of those things that may make sense to run as a
 separate daemon process that listens on a socket.

Yeah, it does. One that listens on port 53, TCP and UDP, perhaps. :)

You've just recommended installing a separate caching resolver.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Danyel Lawson]

I'm glad I thought of it. ;) But the trick is to use port 5353 and set
a really short timeout on responses in the config for the DNS cache.

On Sat, Apr 28, 2012 at 10:15 AM, Chris Angelico ros...@gmail.com wrote:
 On Sat, Apr 28, 2012 at 11:46 PM, Danyel Lawson danyellaw...@gmail.com 
 wrote:
 The DNS lookup is one of those things that may make sense to run as a
 separate daemon process that listens on a socket.

 Yeah, it does. One that listens on port 53, TCP and UDP, perhaps. :)

 You've just recommended installing a separate caching resolver.

 ChrisA
 --
 http://mail.python.org/mailman/listinfo/python-list
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Chris Angelico]

On Sun, Apr 29, 2012 at 12:27 AM, Danyel Lawson danyellaw...@gmail.com wrote:
 I'm glad I thought of it. ;) But the trick is to use port 5353 and set
 a really short timeout on responses in the config for the DNS cache.

I don't think false timeouts are any better than true ones, if you
actually know the true ones. But sure, whatever you need.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Paul Rubin]

Roy Smith r...@panix.com writes:
 I agree that application-level name cacheing is wrong, but sometimes 
 doing it the wrong way just makes sense.  I could whip up a simple 
 cacheing wrapper around getaddrinfo() in 5 minutes.  Depending on the 
 environment (both technology and bureaucracy), getting a cacheing 
 nameserver installed might take anywhere from 5 minutes to a few days to ...

IMHO this really isn't one of those times.  The in-app wrapper would
only be usable to just that process, and we already know that the OP has
multiple processes running the same app on the same machine.  They would
benefit from being able to share the cache, so now your wrapper gets
more complicated.  If it's not a nameserver then it's something that
fills in for one.  And then, since the application appears to be a large
scale web spider, it probably wants to run on a cluster, and the cache
should be shared across all the machines.  So you really probably want
an industrial strength nameserver with a big persistent cache, and maybe
a smaller local cache because of high locality when crawling specific
sites, etc.

Also, since this is a production application, doing something in 5
minutes is less important than making it solid and configurable.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Kiuhnm]

On 4/27/2012 20:54, John Nagle wrote:

I have a multi-threaded CPython program, which has up to four
threads. One thread is simply a wait loop monitoring the other
three and waiting for them to finish, so it can give them more
work to do. When the work threads, which read web pages and
then parse them, are compute-bound, I've had the monitoring thread
starved of CPU time for as long as 120 seconds.
It's sleeping for 0.5 seconds, then checking on the other threads
and for new work do to, so the work thread isn't using much
compute time.


How exactly are these waiting and checking performed?

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Paul Rubin]

John Nagle na...@animats.com writes:
I know that the CPython thread dispatcher sucks, but I didn't
 realize it sucked that bad.  Is there a preference for running
 threads at the head of the list (like UNIX, circa 1979) or
 something like that?

I think it's left up to the OS thread scheduler, Windows in your case.
See  http://www.dabeaz.com/python/NewGIL.pdf  starting around slide 18.

One idea that comes to mind is putting a periodic interrupt and signal
handler into your main thread, to make sure the GIL gets released every
so often.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[MRAB]

On 27/04/2012 23:30, Dennis Lee Bieber wrote:


Oh, continuation thought...

If the workers are calling into C-language operations, unless those
operations release the GIL, it doesn't matter what the OS or Python
thread switch timings are. The OS may interrupt the thread (running
C-language code), pass control to the Python interpreter which finds the
GIL is locked, and just blocks -- control passes back to the interrupted
thread.

Any long-running C-language function should release the GIL while
doing things with local data -- and reacquire the GIL when it needs to
manipulate Python data structures or returning...


The OP mentioned parsing webpages. If that involves the re module at
some point, it doesn't release the GIL while it's looking for matches.
--
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Adam Skutt]

On Apr 27, 2:54 pm, John Nagle na...@animats.com wrote:
      I have a multi-threaded CPython program, which has up to four
 threads.  One thread is simply a wait loop monitoring the other
 three and waiting for them to finish, so it can give them more
 work to do.  When the work threads, which read web pages and
 then parse them, are compute-bound, I've had the monitoring thread
 starved of CPU time for as long as 120 seconds.

How exactly are you determining that this is the case?

     I know that the CPython thread dispatcher sucks, but I didn't
 realize it sucked that bad.  Is there a preference for running
 threads at the head of the list (like UNIX, circa 1979) or
 something like that?

Not in CPython, which is at the mercy of what the operating system
does.  Under the covers, CPython uses a semaphore on Windows, which do
not have FIFO ordering as per 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms685129(v=vs.85).aspx.
As a result, I think your thread is succumbing to the same issues that
impact signal delivery as described on 22-24 and 35-41 of
http://www.dabeaz.com/python/GIL.pdf.

I'm not sure there's any easy or reliable way to fix that from your
code.  I am not a WinAPI programmer though, and I'd suggest finding
one to help you out.  It doesn't appear possible to change the
scheduling policy for semaphore programatically, and I don't know
closely they pay any attention to thread priority.

That's just a guess though, and finding out for sure would take some
low-level debugging.  However, it seems to be the most probable
situation assuming your code is correct.


     (And yes, I know about multiprocessing.  These threads are already
 in one of several service processes.  I don't want to launch even more
 copies of the Python interpreter.

Why? There's little harm in launching more instances.  Processes have
some additional startup and memory overhead compared to threads, but I
can't imagine it woudl be an issue.  Given what you're trying to do,
I'd expect to run out of other resources long before I ran out of
memory because I created too many processes or threads.

 The threads are usually I/O bound,
 but when they hit unusually long web pages, they go compute-bound
 during parsing.)

If your concern is being CPU oversubscribed by using lots of
processes, I suspect it's probably misplaced.  A whole mess of CPU-
bound tasks is pretty much the easiest case for a scheduler to
handle.

Adam
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[John Nagle]

On 4/27/2012 6:25 PM, Adam Skutt wrote:

On Apr 27, 2:54 pm, John Naglena...@animats.com  wrote:

  I have a multi-threaded CPython program, which has up to four
threads.  One thread is simply a wait loop monitoring the other
three and waiting for them to finish, so it can give them more
work to do.  When the work threads, which read web pages and
then parse them, are compute-bound, I've had the monitoring thread
starved of CPU time for as long as 120 seconds.


How exactly are you determining that this is the case?


   Found the problem.  The threads, after doing their compute
intensive work of examining pages, stored some URLs they'd found.
The code that stored them looked them up with getaddrinfo(), and
did this while a lock was set.  On CentOS, getaddrinfo() at the
glibc level doesn't always cache locally (ref
https://bugzilla.redhat.com/show_bug.cgi?id=576801).  Python
doesn't cache either.  So huge numbers of DNS requests were being
made.  For some pages being scanned, many of the domains required
accessing a rather slow  DNS server.  The combination of thousands
of instances of the same domain, a slow DNS server, and no caching
slowed the crawler down severely.

   Added a local cache in the program to prevent this.
Performance much improved.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Chris Angelico]

On Sat, Apr 28, 2012 at 1:35 PM, John Nagle na...@animats.com wrote:
 On CentOS, getaddrinfo() at the
 glibc level doesn't always cache locally (ref
 https://bugzilla.redhat.com/show_bug.cgi?id=576801).  Python
 doesn't cache either.

How do you manage your local cache? The Python getaddrinfo function
doesn't return a positive TTL (much less a negative one). Do you pick
an arbitrary TTL, or cache indefinitely?

I had the same issue in a PHP server (yeah I know, but I was
maintaining a project that someone else started) - fortunately there
is a PHP function that gives a TTL on all successful lookups, though
it still won't for failures. I couldn't find anything on cache control
anywhere in the Python socket module docs.

Perhaps the simplest option is to throw down a local BIND to manage
the caching for you, but that does seem a little like overkill.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Paul Rubin]

John Nagle na...@animats.com writes:

 The code that stored them looked them up with getaddrinfo(), and
 did this while a lock was set.

Don't do that!!

Added a local cache in the program to prevent this.
 Performance much improved.

Better to release the lock while the getaddrinfo is running, if you can.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[John Nagle]

On 4/27/2012 9:20 PM, Paul Rubin wrote:

John Naglena...@animats.com  writes:


The code that stored them looked them up with getaddrinfo(), and
did this while a lock was set.


Don't do that!!


Added a local cache in the program to prevent this.
Performance much improved.


Better to release the lock while the getaddrinfo is running, if you can.


   I may do that to prevent the stall.  But the real problem was all
those DNS requests.  Parallizing them wouldn't help much when it took
hours to grind through them all.

John Nagle

--
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[Paul Rubin]

John Nagle na...@animats.com writes:
I may do that to prevent the stall.  But the real problem was all
 those DNS requests.  Parallizing them wouldn't help much when it took
 hours to grind through them all.

True dat.  But building a DNS cache into the application seems like a
kludge.  Unless the number of requests is insane, running a caching
nameserver on the local box seems cleaner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython thread starvation

[John Nagle]

On 4/27/2012 9:55 PM, Paul Rubin wrote:

John Naglena...@animats.com  writes:

I may do that to prevent the stall.  But the real problem was all
those DNS requests.  Parallizing them wouldn't help much when it took
hours to grind through them all.


True dat.  But building a DNS cache into the application seems like a
kludge.  Unless the number of requests is insane, running a caching
nameserver on the local box seems cleaner.


   I know.  When I have a bit more time, I'll figure out why
CentOS 5 and Webmin didn't set up a caching DNS resolver by
default.

   Sometimes the number of requests IS insane.  When the
system hits a page with a thousand links, it has to resolve
all of them.  (Beyond a thousand links, we classify it as
link spam and stop.  The record so far is a page with over
10,000 links.)

John Nagle

--
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[John Nagle]

On 1/3/2011 11:13 PM, azakai wrote:

On Jan 3, 10:11 pm, John Naglena...@animats.com  wrote:

On 1/1/2011 11:26 PM, azakai wrote:


Hello, I hope this will be interesting to people here: CPython running
on the web,



http://syntensity.com/static/python.html



That isn't a new implementation of Python, but rather CPython 2.7.1,
compiled from C to JavaScript using Emscripten and LLVM. For more
details on the conversion process, seehttp://emscripten.org


 It's a cute hack, but it's about 1000 times slower than CPython.




Yes, as I said, the code isn't optimized (so
don't expect good performance) :)

It can get much faster with more work.


Yea, right.

You're three deep in interpreters.  Performance is going
to suck.

John Nagle

--
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[Carl Banks]

On Jan 3, 4:55 pm, azakai alonmozi...@gmail.com wrote:
 But through a combination of optimizations on the side of Emscripten
 (getting all LLVM optimizations to work when compiling to JS) and on
 the side of the browsers (optimizing accesses on typed arrays in JS,
 etc.), then I hope the code will eventually run quite fast, even
 comparably to C.

This is a very cool idea.  It's quite fascinating to view the
Javascript machine code for a complete CPython interpreter.

I'm sure with a little work you'll be able to improve its performance,
but I think comparably to C is going to be a tall order.

If you can get this to work reasonably well, and manage to get it
successfully deployed it somewhere, I'd recommend petitioning to have
this be considered an official platform.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[gry]

On Jan 4, 1:11 am, John Nagle na...@animats.com wrote:
 On 1/1/2011 11:26 PM, azakai wrote:

  Hello, I hope this will be interesting to people here: CPython running
  on the web,

 http://syntensity.com/static/python.html

  That isn't a new implementation of Python, but rather CPython 2.7.1,
  compiled from C to JavaScript using Emscripten and LLVM. For more
  details on the conversion process, seehttp://emscripten.org

On loading, I get script stack space quota is exhausted under
firefox 3.5.12, under linux.
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907
Fedora/3.5.12-1.fc12 Firefox/3.5.12
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[Gerry Reno]

On 01/04/2011 12:38 PM, gry wrote:
 On Jan 4, 1:11 am, John Nagle na...@animats.com wrote:
   
 On 1/1/2011 11:26 PM, azakai wrote:

 
 Hello, I hope this will be interesting to people here: CPython running
 on the web,
   
 
 http://syntensity.com/static/python.html
   
 
 That isn't a new implementation of Python, but rather CPython 2.7.1,
 compiled from C to JavaScript using Emscripten and LLVM. For more
 details on the conversion process, seehttp://emscripten.org
   
 On loading, I get script stack space quota is exhausted under
 firefox 3.5.12, under linux.
 Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907
 Fedora/3.5.12-1.fc12 Firefox/3.5.12
   


It's a Firefox bug apparently fixed in Firefox 4.x.

Some versions of Firefox 3.6.x do work but most do not.


Regards,
Gerry

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[azakai]

On Jan 2, 5:55 pm, Gerry Reno gr...@verizon.net wrote:
 I tried printing sys.path and here is the output:

 ['', '/usr/local/lib/python27.zip', '/usr/local/lib/python2.7/',
 '/usr/local/lib/python2.7/plat-linux2',
 '/usr/local/lib/python2.7/lib-tk', '/usr/local/lib/python2.7/lib-old',
 '/usr/local/lib/lib-dynload']

 Now, those paths must be on your machine because they are not on my
 client machine.  But the interpreter is now running on MY machine.  Well
 in a sandbox really.  So how is that going to work?


Yeah, those are the paths on the machine where the binary was compiled
(so, they are the standard paths on ubuntu).

Anyhow the filesystem can't (and shouldn't) be accessed from inside a
browser page. I think we will implement a minimal virtual filesystem
here, just enough for stuff to work. The actual implementation would
use HTML5 features like local storage etc.

- azakai
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[Diez B. Roggisch]

azakai alonmozi...@gmail.com writes:

 Hello, I hope this will be interesting to people here: CPython running
 on the web,

 http://syntensity.com/static/python.html

 That isn't a new implementation of Python, but rather CPython 2.7.1,
 compiled from C to JavaScript using Emscripten and LLVM. For more
 details on the conversion process, see http://emscripten.org

A fun hack. Have you bothered to compare it to the PyPy javascript
backend - perfomance-wise, that is?

Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[Gerry Reno]

On 01/03/2011 03:10 PM, azakai wrote:
 On Jan 2, 5:55 pm, Gerry Reno gr...@verizon.net wrote:
   
 I tried printing sys.path and here is the output:

 ['', '/usr/local/lib/python27.zip', '/usr/local/lib/python2.7/',
 '/usr/local/lib/python2.7/plat-linux2',
 '/usr/local/lib/python2.7/lib-tk', '/usr/local/lib/python2.7/lib-old',
 '/usr/local/lib/lib-dynload']

 Now, those paths must be on your machine because they are not on my
 client machine.  But the interpreter is now running on MY machine.  Well
 in a sandbox really.  So how is that going to work?

 
 Yeah, those are the paths on the machine where the binary was compiled
 (so, they are the standard paths on ubuntu).

 Anyhow the filesystem can't (and shouldn't) be accessed from inside a
 browser page. 

Well, the local filesystem could be accessible with the user's
permission and this should be an option.


Regards,
Gerry

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[Gerry Reno]

On 01/03/2011 03:13 PM, Diez B. Roggisch wrote:

 A fun hack. Have you bothered to compare it to the PyPy javascript
 backend - perfomance-wise, that is?

 Diez
   

I don't think that exists anymore.  Didn't that get removed from PyPy
about 2 years ago?


Regards,
Gerry

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[Diez B. Roggisch]

Gerry Reno gr...@verizon.net writes:

 On 01/03/2011 03:13 PM, Diez B. Roggisch wrote:

 A fun hack. Have you bothered to compare it to the PyPy javascript
 backend - perfomance-wise, that is?

 Diez
   

 I don't think that exists anymore.  Didn't that get removed from PyPy
 about 2 years ago?

Ah, didn't know that. I was under the impression pyjamas was done with
it. Apparently, that's wrong:

 http://pyjs.org/

But then I re-phrase my question: how does this relate to pyjamas/pyjs?

Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[Gerry Reno]

On 01/03/2011 05:55 PM, Diez B. Roggisch wrote:
 Gerry Reno gr...@verizon.net writes:

   
 On 01/03/2011 03:13 PM, Diez B. Roggisch wrote:
 
 A fun hack. Have you bothered to compare it to the PyPy javascript
 backend - perfomance-wise, that is?

 Diez
   
   
 I don't think that exists anymore.  Didn't that get removed from PyPy
 about 2 years ago?
 
 Ah, didn't know that. I was under the impression pyjamas was done with
 it. Apparently, that's wrong:

  http://pyjs.org/

 But then I re-phrase my question: how does this relate to pyjamas/pyjs?

 Diez
   

From what I've seen so far:

Pyjamas is taking your python code and converting it into javascript so
that your python code (converted to javascript) can run in a browser.

CPotW is taking the whole python interpreter and converting the
interpreter into javascript so that the python interpreter runs in the
browser.  Your python code remains as python code.


Regards,
Gerry

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[astar]

On Jan 2, 4:58 pm, pyt...@bdurham.com wrote:
 Azakai/Gerry,

  Errors when using Firefox 3.6.3:



firefox 3.6.13 openbsd i386 4.8 -current
error console has some errors:

editor not defined
module not define
too much recursion

nothing interested happened on the web page, but wonderful project
anyway

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[azakai]

On Jan 3, 12:13 pm, de...@web.de (Diez B. Roggisch) wrote:
 A fun hack. Have you bothered to compare it to the PyPy javascript
 backend - perfomance-wise, that is?


Gerry already gave a complete and accurate answer to the status of
this project in comparison to PyPy and pyjamas. Regarding performance,
this hack is not currently fast, primarily because the code is not
optimized yet.

But through a combination of optimizations on the side of Emscripten
(getting all LLVM optimizations to work when compiling to JS) and on
the side of the browsers (optimizing accesses on typed arrays in JS,
etc.), then I hope the code will eventually run quite fast, even
comparably to C.

- azakai
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[azakai]

On Jan 3, 12:23 pm, Gerry Reno gr...@verizon.net wrote:
 On 01/03/2011 03:10 PM, azakai wrote:









  On Jan 2, 5:55 pm, Gerry Reno gr...@verizon.net wrote:

  I tried printing sys.path and here is the output:

  ['', '/usr/local/lib/python27.zip', '/usr/local/lib/python2.7/',
  '/usr/local/lib/python2.7/plat-linux2',
  '/usr/local/lib/python2.7/lib-tk', '/usr/local/lib/python2.7/lib-old',
  '/usr/local/lib/lib-dynload']

  Now, those paths must be on your machine because they are not on my
  client machine.  But the interpreter is now running on MY machine.  Well
  in a sandbox really.  So how is that going to work?

  Yeah, those are the paths on the machine where the binary was compiled
  (so, they are the standard paths on ubuntu).

  Anyhow the filesystem can't (and shouldn't) be accessed from inside a
  browser page.

 Well, the local filesystem could be accessible with the user's
 permission and this should be an option.


Hmm, I think this might be possible with the HTML5 File API. Would
definitely be useful here.

- azakai
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[MrJean1]

FireFox 3.6.13 on MacOS X Tiger (10.4.11) fails:

  Error: too much recursion
  Error: Modules is not defined
  Source File: http://synthensity.com/static/python.html

/Jean

On Jan 2, 11:26 pm, Wolfgang Strobl ne...@mystrobl.de wrote:
 azakai alonmozi...@gmail.com:

 On Jan 2, 4:58 pm, pyt...@bdurham.com wrote:
  Azakai/Gerry,

   Errors when using Firefox 3.6.3:

  I'm running Firefox 3.6.1.3 and the interpreter is running fine.

 I guess that meant FIrefox 3.6.13 (without the last dot), the current
 stable version.

 I'm using Firefox 3.6.13 (german) on Windowx XP (32bit, german) here,
 and the interpreter is running fine, too.  Same for Chrome 8.0.552.224.

 --
 Wir danken f r die Beachtung aller Sicherheitsbestimmungen

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: CPython on the Web

[MrJean1]

FYI,

The example

  http://syntensity.com/static/python.html

works fine in Safari 4.1.3 on MacOS X Tiger (10.4.11).

/Jean


On Jan 3, 5:59 pm, azakai alonmozi...@gmail.com wrote:
 On Jan 3, 12:23 pm, Gerry Reno gr...@verizon.net wrote:





  On 01/03/2011 03:10 PM, azakai wrote:

   On Jan 2, 5:55 pm, Gerry Reno gr...@verizon.net wrote:

   I tried printing sys.path and here is the output:

   ['', '/usr/local/lib/python27.zip', '/usr/local/lib/python2.7/',
   '/usr/local/lib/python2.7/plat-linux2',
   '/usr/local/lib/python2.7/lib-tk', '/usr/local/lib/python2.7/lib-old',
   '/usr/local/lib/lib-dynload']

   Now, those paths must be on your machine because they are not on my
   client machine.  But the interpreter is now running on MY machine.  Well
   in a sandbox really.  So how is that going to work?

   Yeah, those are the paths on the machine where the binary was compiled
   (so, they are the standard paths on ubuntu).

   Anyhow the filesystem can't (and shouldn't) be accessed from inside a
   browser page.

  Well, the local filesystem could be accessible with the user's
  permission and this should be an option.

 Hmm, I think this might be possible with the HTML5 File API. Would
 definitely be useful here.

 - azakai

-- 
http://mail.python.org/mailman/listinfo/python-list