Re: Contributing to cpython
On 12/6/2022 11:18 PM, ramvikram singh wrote: the issue is that after reading the issue I am not able to think how to modify the code, this is where I am stuck On Wed, Dec 7, 2022 at 1:54 AM ramvikram singh wrote: Greetings, I learnt python this year and visiting the python issue tab for the last two months, but there is a problem which I am facing I understand the issue after reading the few times but I can't think about how to modify the code as per the issue. Could you please help me with this? No one can help you because you have said nothing about the issue. It is as if I were to write "I am having a problem with my car. Can you help me?". And before you can think about modifying the code, you need to understand what the issue is, why it is happening, how that could be changed, and why that would be a safe kind of change to make. After that, you would be prepared to think about details of the code. And that thinking would need to include ways in which you could verify that you can make the problem occur and how you can test to make sure that it is fixed after changes to the code. -- https://mail.python.org/mailman/listinfo/python-list
Re: Contributing to cpython
the issue is that after reading the issue I am not able to think how to modify the code, this is where I am stuck On Wed, Dec 7, 2022 at 1:54 AM ramvikram singh wrote: > Greetings, > I learnt python this year and visiting the python issue tab for the last > two months, but there is a problem which I am facing I understand the issue > after reading the few times but I can't think about how to modify the code > as per the issue. Could you please help me with this? > -- https://mail.python.org/mailman/listinfo/python-list
Re: Contributing to cpython
On 12/6/2022 3:24 PM, ramvikram singh wrote: Greetings, I learnt python this year and visiting the python issue tab for the last two months, but there is a problem which I am facing I understand the issue after reading the few times but I can't think about how to modify the code as per the issue. Could you please help me with this? There is a page about contributing work on code to Python at https://devguide.python.org It starts out: "This guide is a comprehensive resource for contributing to Python – for both new and experienced contributors." You should study this guide carefully. If you don't know how to use git, clone a repo, work with git branches, what a pull request is, and so forth, you need to get some basic familiarity with working with those tools and concepts.You should be able to file new issues on GitHub and contribute to their discussion thread. If you want to actually contribute code, you should be able to build Python yourself, as covered in the guide. After that, you should remember that while help is welcome, the Python code base has a long history and a change that seems obvious to you may not work because of other constraints on that part of the codebase. I once suggested a change in a particular function for finding executable files so that it would look in some other locations too. I learnt that this function was intended for internal use by distutils, and that it needed its quirks to work properly in its intended use. No one wanted to take a chance on changing it. I'm not saying you cannot or should not try to contribute useful changes. I'm only saying that you need to get prepared - do your homework - first, and to not be discouraged if your first efforts are not accepted. -- https://mail.python.org/mailman/listinfo/python-list
Re: Contributing to cpython
> On 6 Dec 2022, at 20:55, ramvikram singh wrote: > > Greetings, > I learnt python this year and visiting the python issue tab for the last > two months, but there is a problem which I am facing I understand the issue > after reading the few times but I can't think about how to modify the code > as per the issue. Could you please help me with this? no one can help as you have not explained what the issue is. Barry > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Contributing to cpython
Greetings, I learnt python this year and visiting the python issue tab for the last two months, but there is a problem which I am facing I understand the issue after reading the few times but I can't think about how to modify the code as per the issue. Could you please help me with this? -- https://mail.python.org/mailman/listinfo/python-list
Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)
> On 8 Oct 2022, at 11:50, Weatherby,Gerard wrote: > > Logging does support passing a callable, if indirectly. It only calls __str__ > on the object passed if debugging is enabled. > > class Defer: > > def __init__(self,fn): > self.fn = fn > > def __str__(self): > return self.fn() > > def some_expensive_function(): > return "hello" > > logging.basicConfig() > logging.debug(Defer(some_expensive_function)) Oh what a clever hack. Took a few minutes of code reading to see why this works. You are exploiting the str(msg) that is in class LogRecords getMessage(). ``` def getMessage(self): """ Return the message for this LogRecord. Return the message for this LogRecord after merging any user-supplied arguments with the message. """ msg = str(self.msg) if self.args: msg = msg % self.args return msg ``` Barry > > > From: Python-list <mailto:python-list-bounces+gweatherby=uchc@python.org>> on behalf of > Barry mailto:ba...@barrys-emacs.org>> > Date: Friday, October 7, 2022 at 1:30 PM > To: MRAB mailto:pyt...@mrabarnett.plus.com>> > Cc: python-list@python.org <mailto:python-list@python.org> > mailto:python-list@python.org>> > Subject: Re: Ref-strings in logging messages (was: Performance issue with > CPython 3.10 + Cython) > > *** Attention: This is an external email. Use caution responding, opening > attachments or clicking on links. *** > > > On 7 Oct 2022, at 18:16, MRAB wrote: > > > > On 2022-10-07 16:45, Skip Montanaro wrote: > >>> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames > >>> > >>> wrote: > >>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the > >>> place in calls to `logging.logger.debug()` and friends, evaluating all > >>> arguments regardless of whether the logger was enabled or not. > >>> > >> I thought there was some discussion about whether and how to efficiently > >> admit f-strings to the logging package. I'm guessing that's not gone > >> anywhere (yet). > > Letting you pass in a callable to call might help because that you could > > use lambda. > > Yep, that’s the obvious way to avoid expensive log data generation. > Would need logging module to support that use case. > > Barry > > > -- > > https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$ > > > > <https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$> > > > > -- > https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$ > > <https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$> -- https://mail.python.org/mailman/listinfo/python-list
Re: Quick question about CPython interpreter
On Tue, 18 Oct 2022 at 03:51, Stefan Ram wrote: > > MRAB writes: > >It can't optimise that because, say, 'print' could've been bound to a > >function that rebinds 'str'. > > It would be possible to find out whether a call of a function > named "print" is to the standard function, but the overhead > to do this in the end might slow down the execution. > > In general, it can be possible that there could be optimizer > stages after compilation. So, one might write a small micro- > benchmark to be sure. > You'd also have to ensure that the stringification of the ID doesn't change (which it can it it isn't a core data type), and the easiest way to do THAT is to call str() on the ID every time and see if it's the same... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Quick question about CPython interpreter
On 2022-10-17 16:43, David Lowry-Duda wrote:
One can use the `dis` module and investigate the generated python
bytecode. For me, I get
# file "dis1.py"
thing = 123
for i in range(10):
if "hi" == str(thing):
print("found")
break
The bytecode is then
1 0 LOAD_CONST 0 (123)
2 STORE_NAME 0 (thing)
2 4 LOAD_NAME1 (range)
6 LOAD_CONST 1 (10)
8 CALL_FUNCTION1
10 GET_ITER
>> 12 FOR_ITER28 (to 42)
14 STORE_NAME 2 (i)
3 16 LOAD_CONST 2 ('hi')
18 LOAD_NAME3 (str)
20 LOAD_NAME0 (thing)
22 CALL_FUNCTION1
24 COMPARE_OP 2 (==)
26 POP_JUMP_IF_FALSE 12
4 28 LOAD_NAME4 (print)
30 LOAD_CONST 3 ('found')
32 CALL_FUNCTION1
34 POP_TOP
5 36 POP_TOP
38 JUMP_ABSOLUTE 42
40 JUMP_ABSOLUTE 12
>> 42 LOAD_CONST 4 (None)
44 RETURN_VALUE
I note that line 22 calls the function str repeatedly, and no
optimization is done here.
# file "dis2.py"
thing = 123
strthing = str(thing)
for i in range(10):
if "hi" == strthing:
print("found")
break
This generates bytecode
1 0 LOAD_CONST 0 (123)
2 STORE_NAME 0 (thing)
2 4 LOAD_NAME1 (str)
6 LOAD_NAME0 (thing)
8 CALL_FUNCTION1
10 STORE_NAME 2 (strthing)
3 12 LOAD_NAME3 (range)
14 LOAD_CONST 1 (10)
16 CALL_FUNCTION1
18 GET_ITER
>> 20 FOR_ITER24 (to 46)
22 STORE_NAME 4 (i)
4 24 LOAD_CONST 2 ('hi')
26 LOAD_NAME2 (strthing)
28 COMPARE_OP 2 (==)
30 POP_JUMP_IF_FALSE 20
5 32 LOAD_NAME5 (print)
34 LOAD_CONST 3 ('found')
36 CALL_FUNCTION1
38 POP_TOP
6 40 POP_TOP
42 JUMP_ABSOLUTE 46
44 JUMP_ABSOLUTE 20
>> 46 LOAD_CONST 4 (None)
48 RETURN_VALUE
In short, it seems the cpython interpreter doesn't (currently) perform
this sort of optimization.
It can't optimise that because, say, 'print' could've been bound to a
function that rebinds 'str'.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Quick question about CPython interpreter
One can use the `dis` module and investigate the generated python
bytecode. For me, I get
# file "dis1.py"
thing = 123
for i in range(10):
if "hi" == str(thing):
print("found")
break
The bytecode is then
1 0 LOAD_CONST 0 (123)
2 STORE_NAME 0 (thing)
2 4 LOAD_NAME1 (range)
6 LOAD_CONST 1 (10)
8 CALL_FUNCTION1
10 GET_ITER
>> 12 FOR_ITER28 (to 42)
14 STORE_NAME 2 (i)
3 16 LOAD_CONST 2 ('hi')
18 LOAD_NAME3 (str)
20 LOAD_NAME0 (thing)
22 CALL_FUNCTION1
24 COMPARE_OP 2 (==)
26 POP_JUMP_IF_FALSE 12
4 28 LOAD_NAME4 (print)
30 LOAD_CONST 3 ('found')
32 CALL_FUNCTION1
34 POP_TOP
5 36 POP_TOP
38 JUMP_ABSOLUTE 42
40 JUMP_ABSOLUTE 12
>> 42 LOAD_CONST 4 (None)
44 RETURN_VALUE
I note that line 22 calls the function str repeatedly, and no
optimization is done here.
# file "dis2.py"
thing = 123
strthing = str(thing)
for i in range(10):
if "hi" == strthing:
print("found")
break
This generates bytecode
1 0 LOAD_CONST 0 (123)
2 STORE_NAME 0 (thing)
2 4 LOAD_NAME1 (str)
6 LOAD_NAME0 (thing)
8 CALL_FUNCTION1
10 STORE_NAME 2 (strthing)
3 12 LOAD_NAME3 (range)
14 LOAD_CONST 1 (10)
16 CALL_FUNCTION1
18 GET_ITER
>> 20 FOR_ITER24 (to 46)
22 STORE_NAME 4 (i)
4 24 LOAD_CONST 2 ('hi')
26 LOAD_NAME2 (strthing)
28 COMPARE_OP 2 (==)
30 POP_JUMP_IF_FALSE 20
5 32 LOAD_NAME5 (print)
34 LOAD_CONST 3 ('found')
36 CALL_FUNCTION1
38 POP_TOP
6 40 POP_TOP
42 JUMP_ABSOLUTE 46
44 JUMP_ABSOLUTE 20
>> 46 LOAD_CONST 4 (None)
48 RETURN_VALUE
In short, it seems the cpython interpreter doesn't (currently) perform
this sort of optimization.
- DLD
--
https://mail.python.org/mailman/listinfo/python-list
Re: Quick question about CPython interpreter
On 10/14/22 16:25, DFS wrote: > - > this does a str() conversion in the loop > - > for i in range(cells.count()): >if text == str(ID): > break > > > - > this does one str() conversion before the loop > - > strID = str(ID) > for i in range(cells.count()): >if text == strID: > break > > > But does CPython interpret the str() conversion away and essentially do > it for me in the first example? No. You can use the dis module to show you what CPython is doing under the hood. -- https://mail.python.org/mailman/listinfo/python-list
Quick question about CPython interpreter
- this does a str() conversion in the loop - for i in range(cells.count()): if text == str(ID): break - this does one str() conversion before the loop - strID = str(ID) for i in range(cells.count()): if text == strID: break But does CPython interpret the str() conversion away and essentially do it for me in the first example? -- https://mail.python.org/mailman/listinfo/python-list
Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)
Logging does support passing a callable, if indirectly. It only calls __str__ on the object passed if debugging is enabled. class Defer: def __init__(self,fn): self.fn = fn def __str__(self): return self.fn() def some_expensive_function(): return "hello" logging.basicConfig() logging.debug(Defer(some_expensive_function)) From: Python-list on behalf of Barry Date: Friday, October 7, 2022 at 1:30 PM To: MRAB Cc: python-list@python.org Subject: Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython) *** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. *** > On 7 Oct 2022, at 18:16, MRAB wrote: > > On 2022-10-07 16:45, Skip Montanaro wrote: >>> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames >>> wrote: >>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the >>> place in calls to `logging.logger.debug()` and friends, evaluating all >>> arguments regardless of whether the logger was enabled or not. >>> >> I thought there was some discussion about whether and how to efficiently >> admit f-strings to the logging package. I'm guessing that's not gone >> anywhere (yet). > Letting you pass in a callable to call might help because that you could use > lambda. Yep, that’s the obvious way to avoid expensive log data generation. Would need logging module to support that use case. Barry > -- > https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$> > -- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$> -- https://mail.python.org/mailman/listinfo/python-list
Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)
On Fri, 7 Oct 2022 18:28:06 +0100
Barry wrote:
> > On 7 Oct 2022, at 18:16, MRAB wrote:
> >
> > On 2022-10-07 16:45, Skip Montanaro wrote:
> >>> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames
> >>>
> >>> wrote:
> >>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the
> >>> place in calls to `logging.logger.debug()` and friends, evaluating all
> >>> arguments regardless of whether the logger was enabled or not.
> >>>
> >> I thought there was some discussion about whether and how to efficiently
> >> admit f-strings to the logging package. I'm guessing that's not gone
> >> anywhere (yet).
> > Letting you pass in a callable to call might help because that you could
> > use lambda.
>
> Yep, that’s the obvious way to avoid expensive log data generation.
> Would need logging module to support that use case.
I have some logging code that uses eval() to evaluate expressions using
locals and globals in a parent stack frame, together with a parser to
find `{...}` items in a string.
I guess this constitutes a (basic) runtime implementation of f-strings.
As such it can avoid expensive evaluation/parsing when disabled, though
it's probably slow when enabled compared to native f-strings. It seems
to work quite well in practise, and also allows one to add some extra
formatting features.
For details see:
https://git.ghostscript.com/?p=mupdf.git;a=blob;f=scripts/jlib.py;h=e85e9f2c4;hb=HEAD#l41
- Jules
--
http://op59.net
--
https://mail.python.org/mailman/listinfo/python-list
Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)
> On 7 Oct 2022, at 19:09, Weatherby,Gerard wrote: > The obvious way to avoid log generation is: > > if logger.isEnableFor(logging.DEBUG): >logger.debug( expensive processing ) > > > Of course, having logging alter program flow could lead to hard to debug bugs. Altered flow is less of an issue the the verbosity of the above. We discussed ways to improve this pattern a few years ago. That lead to no changes. What I have used is a class that defines __bool__ to report if logging is enabled and __call__ to log. Then you can do this: log_debug = logger_from(DEBUG) log_debug and log_debug(‘expensive %s’ % (complex(),)) Barry > > From: Python-list on > behalf of Barry > Date: Friday, October 7, 2022 at 1:30 PM > To: MRAB > Cc: python-list@python.org > Subject: Re: Ref-strings in logging messages (was: Performance issue with > CPython 3.10 + Cython) > *** Attention: This is an external email. Use caution responding, opening > attachments or clicking on links. *** > >> On 7 Oct 2022, at 18:16, MRAB wrote: >> >> On 2022-10-07 16:45, Skip Montanaro wrote: >>>> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames >>>> wrote: >>>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the >>>> place in calls to `logging.logger.debug()` and friends, evaluating all >>>> arguments regardless of whether the logger was enabled or not. >>> I thought there was some discussion about whether and how to efficiently >>> admit f-strings to the logging package. I'm guessing that's not gone >>> anywhere (yet). >> Letting you pass in a callable to call might help because that you could use >> lambda. > > Yep, that’s the obvious way to avoid expensive log data generation. > Would need logging module to support that use case. > > Barry > >> -- >> https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$> > > -- > https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$> > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)
The obvious way to avoid log generation is: if logger.isEnableFor(logging.DEBUG): logger.debug( expensive processing ) Of course, having logging alter program flow could lead to hard to debug bugs. From: Python-list on behalf of Barry Date: Friday, October 7, 2022 at 1:30 PM To: MRAB Cc: python-list@python.org Subject: Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython) *** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. *** > On 7 Oct 2022, at 18:16, MRAB wrote: > > On 2022-10-07 16:45, Skip Montanaro wrote: >>> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames >>> wrote: >>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the >>> place in calls to `logging.logger.debug()` and friends, evaluating all >>> arguments regardless of whether the logger was enabled or not. >>> >> I thought there was some discussion about whether and how to efficiently >> admit f-strings to the logging package. I'm guessing that's not gone >> anywhere (yet). > Letting you pass in a callable to call might help because that you could use > lambda. Yep, that’s the obvious way to avoid expensive log data generation. Would need logging module to support that use case. Barry > -- > https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$> > -- https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!mrESxAj9YCHsdtNAfkNiY-Zf6U3WTIqaNrgBmbw1ELlQy51ilob43dD0ONsqvg4a94MEdOdwomgyqfyABbvRnA$> -- https://mail.python.org/mailman/listinfo/python-list
Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)
> On 7 Oct 2022, at 18:16, MRAB wrote: > > On 2022-10-07 16:45, Skip Montanaro wrote: >>> On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames >>> wrote: >>> 1. The culprit was me. As lazy as I am, I have used f-strings all over the >>> place in calls to `logging.logger.debug()` and friends, evaluating all >>> arguments regardless of whether the logger was enabled or not. >>> >> I thought there was some discussion about whether and how to efficiently >> admit f-strings to the logging package. I'm guessing that's not gone >> anywhere (yet). > Letting you pass in a callable to call might help because that you could use > lambda. Yep, that’s the obvious way to avoid expensive log data generation. Would need logging module to support that use case. Barry > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)
On 2022-10-07 16:45, Skip Montanaro wrote: On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames wrote: 1. The culprit was me. As lazy as I am, I have used f-strings all over the place in calls to `logging.logger.debug()` and friends, evaluating all arguments regardless of whether the logger was enabled or not. I thought there was some discussion about whether and how to efficiently admit f-strings to the logging package. I'm guessing that's not gone anywhere (yet). Letting you pass in a callable to call might help because that you could use lambda. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)
> On 7 Oct 2022, at 16:48, Skip Montanaro wrote: > > On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames > wrote: > >> 1. The culprit was me. As lazy as I am, I have used f-strings all over the >> place in calls to `logging.logger.debug()` and friends, evaluating all >> arguments regardless of whether the logger was enabled or not. >> > > I thought there was some discussion about whether and how to efficiently > admit f-strings to the logging package. I'm guessing that's not gone > anywhere (yet). That cannot be done as the f-string is computed before the log call. Maybe you are thinking of the lazy expression idea for this. That idea seems to have got no where as its not clear how to implement it without performance issues. Barry > > Skip > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)
Dang autocorrect. Subject first word was supposed to be "f-strings" not "ref-strings." Sorry about that. S On Fri, Oct 7, 2022, 10:45 AM Skip Montanaro wrote: > > > On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames > wrote: > >> 1. The culprit was me. As lazy as I am, I have used f-strings all over the >> place in calls to `logging.logger.debug()` and friends, evaluating all >> arguments regardless of whether the logger was enabled or not. >> > > I thought there was some discussion about whether and how to efficiently > admit f-strings to the logging package. I'm guessing that's not gone > anywhere (yet). > > Skip > -- https://mail.python.org/mailman/listinfo/python-list
Ref-strings in logging messages (was: Performance issue with CPython 3.10 + Cython)
On Fri, Oct 7, 2022 at 9:42 AM Andreas Ames wrote: > 1. The culprit was me. As lazy as I am, I have used f-strings all over the > place in calls to `logging.logger.debug()` and friends, evaluating all > arguments regardless of whether the logger was enabled or not. > I thought there was some discussion about whether and how to efficiently admit f-strings to the logging package. I'm guessing that's not gone anywhere (yet). Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Performance issue with CPython 3.10 + Cython
Answering to myself, just for the records: 1. The culprit was me. As lazy as I am, I have used f-strings all over the place in calls to `logging.logger.debug()` and friends, evaluating all arguments regardless of whether the logger was enabled or not. Replacing these f-strings by regular printf-like format strings solved the issue. Now the application bowls happily along, consistently below 0.02 seconds per second application time. 2. Valgrind + callgrind is an awesome toolchain to spot performance issues, even on VMs. Am Di., 4. Okt. 2022 um 11:05 Uhr schrieb Andreas Ames < andreas.0815.qwe...@gmail.com>: > Hi all, > > I am wrapping an embedded application (, which does not use any dynamic > memory management,) using Cython to call it from CPython. The wrapped > application uses a cyclic executive, i.e. everything is done in the > input-logic-output design, typical for some real-time related domains. > Consequentially, every application cycle executes more or less the very > same code. As I am still in a prototyping stadium, the wrapped process is > completely CPU-bound, i.e. except of some logging output there is no I/O > whatsoever. > > During one second of "application time", I am doing exactly 120 calls into > the application through three Cython-wrapped API functions. The > application uses some platform-dependent APIs, which I have also wrapped > with Cython, so that there are numerous callbacks into the Python realm per > call into the application. What I am observing now, is that the performance > per "application second" decreases (remember: executing code that does the > same thing on every cycle) and extending the number of loop iterations does > not seem to cause any bound to this decrease. In the log ouput below, you > can see the GC counts, which look innocent to me. The "real time" is > measured using "time.time()". The "top" utility does not suggest any memory > leak either. I am developing on WSL2, but I have checked that this > performance effect also happens on physical machines. Right now, I am > staring at "kcachegrind", but I have no idea, how to determine time series > for the performance of functions (I am not looking for those functions, > which need the most time, but for those, which consume more and more > execution time). > > One more thing to look for could be memory fragmentation, but before that > I would like to ask the experts here for their ideas and experiences and/or > for tools, which could help to find the culprit. > > 2022-10-04 10:40:50|INFO|__main__ |Execution loop 0 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.06862711906433105 seconds real time. >> 2022-10-04 10:40:51|INFO|__main__ |Execution loop 100 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.08224177360534668 seconds real time. >> 2022-10-04 10:40:52|INFO|__main__ |Execution loop 200 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.08225250244140625 seconds real time. >> 2022-10-04 10:40:53|INFO|__main__ |Execution loop 300 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.10176873207092285 seconds real time. >> 2022-10-04 10:40:54|INFO|__main__ |Execution loop 400 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.10900592803955078 seconds real time. >> 2022-10-04 10:40:55|INFO|__main__ |Execution loop 500 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.12233948707580566 seconds real time. >> 2022-10-04 10:40:56|INFO|__main__ |Execution loop 600 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.14058256149291992 seconds real time. >> 2022-10-04 10:40:58|INFO|__main__ |Execution loop 700 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.14777183532714844 seconds real time. >> 2022-10-04 10:40:59|INFO|__main__ |Execution loop 800 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.15729451179504395 seconds real time. >> 2022-10-04 10:41:01|INFO|__main__ |Execution loop 900 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.17365813255310059 seconds real time. >> 2022-10-04 10:41:03|INFO|__main__ |Execution loop 1000 done. GC >> counts = (381, 9, 3); 1 second of application time corresponds to >> 0.17772984504699707 seconds real time. >> 2022-10-04 10:41:05|INFO|__main__ |Exec
Performance issue with CPython 3.10 + Cython
Hi all, I am wrapping an embedded application (, which does not use any dynamic memory management,) using Cython to call it from CPython. The wrapped application uses a cyclic executive, i.e. everything is done in the input-logic-output design, typical for some real-time related domains. Consequentially, every application cycle executes more or less the very same code. As I am still in a prototyping stadium, the wrapped process is completely CPU-bound, i.e. except of some logging output there is no I/O whatsoever. During one second of "application time", I am doing exactly 120 calls into the application through three Cython-wrapped API functions. The application uses some platform-dependent APIs, which I have also wrapped with Cython, so that there are numerous callbacks into the Python realm per call into the application. What I am observing now, is that the performance per "application second" decreases (remember: executing code that does the same thing on every cycle) and extending the number of loop iterations does not seem to cause any bound to this decrease. In the log ouput below, you can see the GC counts, which look innocent to me. The "real time" is measured using "time.time()". The "top" utility does not suggest any memory leak either. I am developing on WSL2, but I have checked that this performance effect also happens on physical machines. Right now, I am staring at "kcachegrind", but I have no idea, how to determine time series for the performance of functions (I am not looking for those functions, which need the most time, but for those, which consume more and more execution time). One more thing to look for could be memory fragmentation, but before that I would like to ask the experts here for their ideas and experiences and/or for tools, which could help to find the culprit. 2022-10-04 10:40:50|INFO|__main__ |Execution loop 0 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.06862711906433105 seconds real time. > 2022-10-04 10:40:51|INFO|__main__ |Execution loop 100 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.08224177360534668 seconds real time. > 2022-10-04 10:40:52|INFO|__main__ |Execution loop 200 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.08225250244140625 seconds real time. > 2022-10-04 10:40:53|INFO|__main__ |Execution loop 300 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.10176873207092285 seconds real time. > 2022-10-04 10:40:54|INFO|__main__ |Execution loop 400 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.10900592803955078 seconds real time. > 2022-10-04 10:40:55|INFO|__main__ |Execution loop 500 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.12233948707580566 seconds real time. > 2022-10-04 10:40:56|INFO|__main__ |Execution loop 600 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.14058256149291992 seconds real time. > 2022-10-04 10:40:58|INFO|__main__ |Execution loop 700 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.14777183532714844 seconds real time. > 2022-10-04 10:40:59|INFO|__main__ |Execution loop 800 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.15729451179504395 seconds real time. > 2022-10-04 10:41:01|INFO|__main__ |Execution loop 900 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.17365813255310059 seconds real time. > 2022-10-04 10:41:03|INFO|__main__ |Execution loop 1000 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.17772984504699707 seconds real time. > 2022-10-04 10:41:05|INFO|__main__ |Execution loop 1100 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.1955263614654541 seconds real time. > 2022-10-04 10:41:07|INFO|__main__ |Execution loop 1200 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.20046710968017578 seconds real time. > 2022-10-04 10:41:09|INFO|__main__ |Execution loop 1300 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.22513842582702637 seconds real time. > 2022-10-04 10:41:11|INFO|__main__ |Execution loop 1400 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.23578548431396484 seconds real time. > 2022-10-04 10:41:13|INFO|__main__ |Execution loop 1500 done. GC > counts = (381, 9, 3); 1 second of application time corresponds to > 0.24581527709960938 seconds real time. > 2022
Re: "CPython"
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"
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, 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"
>> 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"
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"
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 <https://www.kermitproject.org/> 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"
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"
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"
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"
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"
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"
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"
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"
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"
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"
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"
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"
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"
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"
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"
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"
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 <https://www.kermitproject.org/> 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"
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"
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"
À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"
À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"
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"
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"
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"
À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"
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"
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"
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"
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"
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"
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"
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"
À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
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= <https://github.com/python/cpython/issues/new?assignees=&labels=type-bug&tem plate=bug.md> &labels=type-bug&template=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
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= <https://github.com/python/cpython/issues/new?assignees=&labels=type-bug&tem plate=bug.md> &labels=type-bug&template=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
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
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
Cpython: when to incref before insertdict
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. Other functions, such as _PyDict_FromKeys, don't do an incref before. When an incref of key and value is needed before insertdict and when is not? And why is an incref needed? -- https://mail.python.org/mailman/listinfo/python-list
Re: CPython / Decimal and bit length of value.
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
CPython / Decimal and bit length of value.
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] Austin -- CPython frame stack sampler v3.0.0 is now available
Very nice. I used rbspy for Ruby programs https://rbspy.github.io/ and it can give you some insights about the running code that other profiling techniques may not give you. I'll use it in my next performance-bottleneck challenge. On Fri, Jul 02, 2021 at 04:04:24PM -0700, Gabriele Tornetta wrote: I am delighted to announce the release 3.0.0 of Austin. If you haven't heard of Austin before, it is an open-source frame stack sampler for CPython, distributed under the GPLv3 license. It can be used to obtain statistical profiling data out of a running Python application without a single line of instrumentation. This means that you can start profiling a Python application straight away, even while it's running in a production environment, with minimal impact on performance. The best way to leverage Austin is to use the new extension for VS Code, which brings interactive flame graphs straight into the text editor to allow you to quickly jump to the source code with a simple click. You can find the extension on the Visual Studio Marketplace and install it directly from VS Code: https://marketplace.visualstudio.com/items?itemName=p403n1x87.austin-vscode To see how to make the best of Austin with VS Code to find and fix performance issues, check out this blog post, which shows you the editor extension in action on a real Python project: https://p403n1x87.github.io/how-to-bust-python-performance-issues.html The latest release comes with many improvements, including a re-worked sleepless mode that now gives an estimate of CPU time, initial support for Python 3.10, better support for Python-based binaries like gunicorn, uWSGI, etc. on all supported platforms. Austin is a pure C application that has no dependencies other than the C standard library. Its source code is hosted on GitHub at https://github.com/P403n1x87/austin The README contains installation and usage details, as well as some examples of Austin in action. Details on how to contribute to Austin's development can be found at the bottom of the page. Austin can be installed easily on the following platforms and from the following sources: Linux: - Snap Store - Debian repositories macOS: - Homebrew Windows: - Chocolatey - Scoop An Austin image, based on Ubuntu 20.04, is also available from Docker Hub: https://hub.docker.com/r/p403n1x87/austin Austin is also simple to compile from sources as it only depends on the standard C library if you don't have access to the above-listed sources. You can stay up-to-date with the project's development by following Austin on Twitter (https://twitter.com/AustinSampler). All the best, Gabriele -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
[ANN] Austin -- CPython frame stack sampler v3.0.0 is now available
I am delighted to announce the release 3.0.0 of Austin. If you haven't heard of Austin before, it is an open-source frame stack sampler for CPython, distributed under the GPLv3 license. It can be used to obtain statistical profiling data out of a running Python application without a single line of instrumentation. This means that you can start profiling a Python application straight away, even while it's running in a production environment, with minimal impact on performance. The best way to leverage Austin is to use the new extension for VS Code, which brings interactive flame graphs straight into the text editor to allow you to quickly jump to the source code with a simple click. You can find the extension on the Visual Studio Marketplace and install it directly from VS Code: https://marketplace.visualstudio.com/items?itemName=p403n1x87.austin-vscode To see how to make the best of Austin with VS Code to find and fix performance issues, check out this blog post, which shows you the editor extension in action on a real Python project: https://p403n1x87.github.io/how-to-bust-python-performance-issues.html The latest release comes with many improvements, including a re-worked sleepless mode that now gives an estimate of CPU time, initial support for Python 3.10, better support for Python-based binaries like gunicorn, uWSGI, etc. on all supported platforms. Austin is a pure C application that has no dependencies other than the C standard library. Its source code is hosted on GitHub at https://github.com/P403n1x87/austin The README contains installation and usage details, as well as some examples of Austin in action. Details on how to contribute to Austin's development can be found at the bottom of the page. Austin can be installed easily on the following platforms and from the following sources: Linux: - Snap Store - Debian repositories macOS: - Homebrew Windows: - Chocolatey - Scoop An Austin image, based on Ubuntu 20.04, is also available from Docker Hub: https://hub.docker.com/r/p403n1x87/austin Austin is also simple to compile from sources as it only depends on the standard C library if you don't have access to the above-listed sources. You can stay up-to-date with the project's development by following Austin on Twitter (https://twitter.com/AustinSampler). All the best, Gabriele -- https://mail.python.org/mailman/listinfo/python-list
RE: How to build stable 3.9 branch from fork and clone of cpython
> -Original Message- > From: Chris Angelico > Sent: Tuesday, May 18, 2021 3:01 AM > To: Python > Subject: Re: How to build stable 3.9 branch from fork and clone of cpython > > On Tue, May 18, 2021 at 4:33 PM wrote: > > > > I am following the "Getting Started" section of the Python Developers > > Guide, but when I build the first version to verify everything builds, > > it builds branch 3.11. > > > > If I want to build and contribute to branch 3.9, how do I set that up > > please? > > > > git checkout 3.9 > > That should switch you to the branch, replacing all the (tracked) files in > the build > directory with the corresponding files from 3.9. > > Be aware that most development is going to happen on the master branch (or > the main branch, whichever one you have), and branches like 3.9 are going to > get backported patches; so any change you're planning to contribute to 3.9 is > going to need to work correctly on both branches. > > ChrisA Thanks Chris, that did work. Thinking over what you said though, perhaps I should change it back. Would "git checkout main" reverse the branch 3.9 checkout? As you can probably tell, I am very new to git, so please pardon my ignorance. Peter -- https://mail.python.org/mailman/listinfo/python-list
Re: How to build stable 3.9 branch from fork and clone of cpython
On Wed, May 19, 2021 at 1:37 PM wrote: > > > -Original Message- > > From: Chris Angelico > > Sent: Tuesday, May 18, 2021 3:01 AM > > To: Python > > Subject: Re: How to build stable 3.9 branch from fork and clone of cpython > > > > On Tue, May 18, 2021 at 4:33 PM wrote: > > > > > > I am following the "Getting Started" section of the Python Developers > > > Guide, but when I build the first version to verify everything builds, > > > it builds branch 3.11. > > > > > > If I want to build and contribute to branch 3.9, how do I set that up > > > please? > > > > > > > git checkout 3.9 > > > > That should switch you to the branch, replacing all the (tracked) files in > > the build > > directory with the corresponding files from 3.9. > > > > Be aware that most development is going to happen on the master branch (or > > the main branch, whichever one you have), and branches like 3.9 are going to > > get backported patches; so any change you're planning to contribute to 3.9 > > is > > going to need to work correctly on both branches. > > > > ChrisA > > Thanks Chris, that did work. Thinking over what you said though, perhaps I > should change it back. > > Would "git checkout main" reverse the branch 3.9 checkout? Yes, it would! > As you can probably tell, I am very new to git, so please pardon my ignorance. > Fortunately, git may be complex and immensely detailed, but it is also logical. Also, git works *very* hard to make sure that you don't lose anything, so it's usually safe to try things out (for instance, if that "git checkout" command would overwrite changes without being able to bring them back, it'll let you know). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to build stable 3.9 branch from fork and clone of cpython
On 5/18/2021 3:00 AM, Chris Angelico wrote: On Tue, May 18, 2021 at 4:33 PM wrote: I am following the "Getting Started" section of the Python Developers Guide, but when I build the first version to verify everything builds, it builds branch 3.11. If I want to build and contribute to branch 3.9, how do I set that up please? git checkout 3.9 That should switch you to the branch, replacing all the (tracked) files in the build directory with the corresponding files from 3.9. Be aware that most development is going to happen on the master branch (or the main branch, whichever one you have), It should be 'main' for any python/??? repository. If one forked and cloned before the switch, one should rename 'master' to 'main' both locally and on the fork. Github has directions somewhere. It might provide them if one attempts a PR against 'master'. There may also be something in the devguide. The only time an initial contribution would be for 3.9 would be for a bug that only exists in 3.9, which is very rare. and branches like 3.9 are going to get backported patches; so any change you're planning to contribute to 3.9 is going to need to work correctly on both branches. It must be 'main' for any python/??? repository. The only time an initial contribution would be for 3.9 would be for a bug that only exists in 3.9, which is very rare. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: How to build stable 3.9 branch from fork and clone of cpython
On Tue, May 18, 2021 at 4:33 PM wrote: > > I am following the "Getting Started" section of the Python Developers Guide, > but when I build the first version to verify everything builds, it builds > branch 3.11. > > > > If I want to build and contribute to branch 3.9, how do I set that up > please? > git checkout 3.9 That should switch you to the branch, replacing all the (tracked) files in the build directory with the corresponding files from 3.9. Be aware that most development is going to happen on the master branch (or the main branch, whichever one you have), and branches like 3.9 are going to get backported patches; so any change you're planning to contribute to 3.9 is going to need to work correctly on both branches. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
How to build stable 3.9 branch from fork and clone of cpython
I am following the "Getting Started" section of the Python Developers Guide, but when I build the first version to verify everything builds, it builds branch 3.11. If I want to build and contribute to branch 3.9, how do I set that up please? OS is Windows 10. I have, I believe, all the necessary tools for the build, since the 3.11 version did build and in a very minimal test does execute successfully after the build (responds to "-V" option with build information). TIA for your assistance. Peter -- https://mail.python.org/mailman/listinfo/python-list
[ANN] Austin -- CPython frame stack sampler v2.1.1 is now available
I am delighted to announce the release 2.1.1 of Austin. If you haven't heard of Austin before, it is an open-source frame stack sampler for CPython, distributed under the GPLv3 license. It can be used to obtain statistical profiling data out of a running Python application without a single line of instrumentation. This means that you can start profiling a Python application straight away, even while it's running on a production environment, with minimal impact on performance. The simplest way of using Austin is by piping its output to FlameGraph or uploading it to speedscope.app for a quick and detailed representation of the collected samples. Austin is a pure C application that has no other dependencies other than the C standard library. Its source code is hosted on GitHub at https://github.com/P403n1x87/austin The README contains installation and usage details, as well as some examples of Austin in action. Details on how to contribute to Austin's development can be found at the bottom of the page. Austin can be installed easily on the following platforms and from the following sources: Linux: - Snap Store - Debian repositories - Conda Forge macOS: - Homebrew - Conda Forge Windows: - Chocolatey - Scoop Austin is also simple to compile from sources as it only depends on the standard C library, if you don't have access to the above-listed repositories. This new release of Austin brings enhanced support for many Python binary distributions across all the supported platforms, as well as a bugfix for the line number reporting. If you rely on Austin 2, upgrading to the latest version is strongly recommended. Let me also remind you of some of the other existing Python tools powered by Austin, which have also seen new releases in the past few days, and that are easily available from PyPI: https://github.com/P403n1x87/austin-tui https://github.com/P403n1x87/austin-web https://github.com/P403n1x87/pytest-austin These tools are built using the austin-python library, which is also available from PyPI, with source code hosted at https://github.com/P403n1x87/austin-python For anyone wishing to build their own Austin-powered tools, the austin-python documentation is hosted on RTD at https://austin-python.readthedocs.io/en/latest/ You can stay up-to-date with the project's development by following Austin on Twitter (https://twitter.com/AustinSampler). All the best, Gabriele https://github.com/P403n1x87/austin";>Austin 2.1.1 - frame stack sampler for CPython. (12-Jan-21) -- https://mail.python.org/mailman/listinfo/python-list
How to create a C Extension that uses CPython internals (outside limited API)?
I'm working on a C extension for frozendict. To make it working, I had to: 1. add by hand the whole path of dictobject.c (/home/marco/sources/cpython/Objects/dictobject.c) 2. add -DPy_BUILD_CORE 3. add the whole path of CPython includes (/home/marco/sources/cpython/Include and so on) This works on my machine, but I suspect that nobody will download the whole CPython code and add the extra CFLAGS only to make it work. What do I have to do? I have to copy the CPython source code that I need inside my c extension folder? What if I also want to support CPython from 3.6 to 3.9? -- https://mail.python.org/mailman/listinfo/python-list
[ANN] Austin -- CPython frame stack sampler v2.0.0 is now available
I am delighted to announce the release 2.0.0 of Austin. If you haven't heard of Austin before, it is an open source frame stack sampler for CPython, distributed under the GPLv3 license. It can be used to obtain statistical profiling data out of a running Python application without a single line of instrumentation. This means that you can start profiling a Python application straightaway, even while it's running on a production environment, with minimal impact on performance. The simplest way of using Austin is by piping its output to FlameGraph for a quick and detailed representation of the collected samples. The latest release introduces a memory profiling mode which allows you to profile memory usage. Austin is a pure C application that has no other dependencies other than the C standard library. Its source code is hosted on GitHub at https://github.com/P403n1x87/austin The README contains installation and usage details, as well as some examples of Austin in action. Details on how to contribute to Austin's development can be found at the bottom of the page. Austin can be installed easily on the following platforms and from the following sources: Linux: - Snap Store - Debian repositories macOS: - Homebrew Windows: - Chocolatey - Scoop Austin is also simple to compile from sources as it only depends on the standard C library, if you don't have access to the above listed sources. Besides support for Python 3.9, this new release of Austin brings a considerable performance enhancement that allows it to sample up to 8 times faster than previous versions. But please do read on until the end to find out about some new tools that take advantage of all the key features of Austin. Due to increasing popularity, the sample Python applications that were included in the main repository have been moved to dedicated projects on GitHub. The TUI can now be found at https://github.com/P403n1x87/austin-tui while Austin Web is now available from https://github.com/P403n1x87/austin-web They can both be installed easily from PyPI, but in order to use them the Austin binary needs to be on the PATH environment variable. These projects now rely on the austin-python Python package that provides a Python wrapper around Austin. If you are considering making your own profiling tool based on Austin, this package can spare you from writing boilerplate code, so it's worth having a look at it at https://github.com/P403n1x87/austin-python The documentation is hosted on RTD at https://austin-python.readthedocs.io/en/latest/ Finally, I am happy to announce the release of pytest-austin, a plugin for pytest that allows you to set up performance regression testing by simply decorating your existing pytest test suite. The plugin launches Austin to profile your test runs, meaning that no further instrumentation is required. For more details, check out the project on GitHub https://github.com/P403n1x87/pytest-austin Like the other Austin tools, pytest-austin can be installed easily from PyPI. You can stay up-to-date with the project's development by following Austin on Twitter (https://twitter.com/AustinSampler). All the best, Gabriele https://github.com/P403n1x87/austin";>Austin 2.0.0 - frame stack sampler for CPython. (13-Oct-20) -- https://mail.python.org/mailman/listinfo/python-list
[ANN] Austin -- Python frame stack sampler for CPython v1.0.1 is now available
I am delighted to announce the release 1.0.1 of Austin. If you haven't heard of Austin before, it is a frame stack sampler for CPython. It can be used to obtain statistical profiling data out of a running Python application without a single line of instrumentation. This means that you can start profiling a Python application straightaway, even while it's running on a production environment, with minimal impact on performance. The simplest way of using Austin is by piping its output to FlameGraph for a quick and detailed representation of the collected samples. The latest release introduces a memory profiling mode which allows you to profile memory usage. Austin is a pure C application that has no other dependencies other than the C standard library. Its source code is hosted on GitHub at https://github.com/P403n1x87/austin The README contains installation and usage details, as well as some examples of Austin in action. Details on how to contribute to Austin's development can be found at the bottom of the page. Austin v1.0.1 is also the first version of Austin to be available from Homebrew for easy installation on MacOS. These are the other places where Austin can be downloaded Linux: - Snap Store - Debian repositories Windows: - Chocolatey Furthermore, you can stay up-to-date with the project's development by following Austin on Twitter (https://twitter.com/AustinSampler). All the best, Gabriele Bugfixes - Fixed Python 3.8 support on MacOS. -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
Dennis,
> So... extract the original args, then build a new args object with your
> added argument, then call your new function with that...
I wanted to respond that prepending a string to an existing argument sounds
quite a bit easier than what you are describing, but than I realized that I
just flatout assumed that the origional "args" would be a string too ..
Thanks for the links. And yes, thats one of the six related pages I've
saved.I blame me being focussed on calling another method, (pretty-much)
ignoring the arguments til after I found it (arguments without being able to
call would have had a zero value to me). Looking back I can now see their
value.
> {Personally, I still think you are looking for a solution to a problem
> that doesn't exist.
I for my part still think that my "lets dig into it" has been worthwhile to
me - much more than just grabbing another extension.I've learned a few
things along the way, which is really all that matters to me.
> The proper way to handle this is to NOT hard-code any pin numbers
> in your module, but instead provide an initialization/setup function which
> the end-user calls, passing in pin numbers in their preferred scheme.
Absolutily. But instead of requiring the (noobie) user to provide those I
tend to make that optional by using defaults.
> they provided the pins in that scheme and your code doesn't
> have to worry about it.
Yep, thats one way to solve the problem. :-)
Regards,
Rudy Wieser
--
https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
Michael, > If you mentioned RPi.GPIO before, I apologize for my mistake. No I didn't, there is nothing to apologize for. > That's very helpful to know. I have no clue to why it would be, as my question has got *zero* to do with it - its valid for /any/ extension using the CPython C API.Just look at the "this is what I'm using" code in my previous message. > If I knew what the pin naming scheme was (how do you use it from python?) :-) You can't (use it from python). That was the whole problem I started with.Its simply not exposed to the user. > But I thought, and remain convinced, that there were probably other > ways of solving it that didn't involve mucking with C code. I already asked that question in "comp.sys.raspberry-py", in a thread named "Accessing GPIO pins using the two different numering schemes (BCM and BOARD) at the same time ?". You know what most of the answers boiled down to ? 'Use another extension'. Most likely well-ment, but not something I tend to accept/do before doing an in-depth search for possibilities (for multiple reasons, also stated there). > You mentioned you're working with RPi.GPIO, so why not just use the > real function names in your questions? Because my question was-and-is not about that extension. Its as simple as that. And ofcourse because I did not want yet another "just use a different entextension" slew of non-answers (once bitten, twice shy). > After grepping I've determined that you are really wanting to work > with the C function py_output_gpio(). That one, and a number of others that cannot be used before & get locked into place by the "py_setmode()" call. > Why not just say that? Doesn't take very much extra time but will > get more people willing to respond who might know. See above: My experience tells me that I would have gotten a jumble of people who would just tell me to forget about my question and use something completely different - possibly stopping someone from posting the answer I needed. Yep, that latter part is the other side of your coin. Part of the problem might also be that I am here to enjoy the journey, with the goal as a kind of extra. Heck, everytime I reach a goal I need to find myself another journey ... :-) >That "int ExtraArg" bit looks a bit strange; I thought everything that > was exposed to the Python side of things had to be wrapped in > PyObject. Guess I'm wrong? Yes, it did and still does look a bit strange, and I was even worse off: I somehow assumed that a PyObject method would only accept a single argument, hence my question to how to prepend that "foo" string to the origional one. But with me being me I also tried to transfer the PyObject containing that "foo" string by itself as a second argument, and it worked. Score one, and much easier to work with. Than I simply tried to replace that PyObject string with a C-style argument. Which also worked and made the solution even simpler. Score two. Changing "foo" into a numeric argument was just the last step - all I needed to transfer was either the BCM or BOARD constants. And that was "game over". Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
Luciano, > Now that's a novel approach to asking for free help: pretending > to be smarter than the people who are trying to help you. What makes you think I'm /pretending/ ?*Ofcourse* I'm smarter than anyone on this earth, didn't you know ? :-D But I'll let you in on a secret: I'm rather aware that my knowledge, even on subjects I've spend most of my time on, is rather limited. There is /always/ someone who knows more about a particular subject (better memory, hands-on experience, you name it). Though that doesn't mean I take anyones word as gods gospell - which you might have noticed and taken offense to. And pray tell: How is me pointing out stuff that anyone can have read in this thread any indication that I would be smarter ?I wrote those questions, so it stands to reason that I know a bit more about whats in them than someone who just read (skimmed?) them. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
On 20/11/19 9:20 AM, Luciano Ramalho wrote: I apologize to all but the intended recipient for this. I’d have given him feedback in private if I knew his email. I will take leave from the list now. Keep up the good work, friendly responders. Please reconsider. Should your relationship with the 'good folks' be governed by someone/anyone else? There is no need to tell you that are many innocent reasons why we misunderstand each other's motives or intent, particularly in a multi-cultural context; just as there are folk who attempt to 'take advantage'. Grossly generalised examples - each academic year a new crop of PyStudents seems to crop-up, thinking we'll *do* their 'homework' for them... - some parts of British humor is impenetrable to those born south of Dover - Dutch/German positivity can be interpreted as brusque or even arrogant, in some parts of the world - Kiwi/Aussie humor as often involves insult (which is not meant to be taken seriously) as it does self-deprecation - Self-deprecation is not 'the American way'... - Monty Python humor is its own (lack of) explanation! That said, I am asking (elsewhere, but please feel free...'here') if the standards and conventions of the Python Foundation apply to this/these list(s)? Such requires a balance between an individual's right to privacy, and the open-ness with which we conduct Python-business, ie without insult, derision, victimisation, etc, etc... -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
On 11/19/19 10:12 AM, R.Wieser wrote:
> Feel free to post code showing that it can be done. The extension is
> RPi.GPIO, the method is "output", and the extra argument is the pinnaming
> scheme (BCM or BOARD). Success! :-p
If you mentioned RPi.GPIO before, I apologize for my mistake. That's
very helpful to know.
As for posting code to show it can be done, If I knew what the pin
naming scheme was (how do you use it from python?), and if I knew how
you modified py_output_gpio to do something with that, I sure would give
it a shot.
>> We're working in the dark here
>
> Are you sure ?
> MRAB didn't seem to have too much problems with both
> recognising and understanding what I was busy with - he posted a spot-on
> example, containing not more, but also not anything less than what I was
> asking for.
MRAB understood and answered the specific question, yes.
But I thought, and remain convinced, that there were probably other ways
of solving it that didn't involve mucking with C code. Because forking
the RPi.GPIO code means that every time there's a change or update to it
you know have to redo everything each time.
You mentioned you're working with RPi.GPIO, so why not just use the real
function names in your questions? After grepping I've determined that
you are really wanting to work with the C function py_output_gpio().
Why not just say that? Doesn't take very much extra time but will get
more people willing to respond who might know.
> I did not find any example that showed me what I needed to know - simply one
> CPython function calling another one.And yes, I've found multiple
> documentation pages, including the "Extending and Embedding the Python
> Interpreter" ones. Alas, no dice.
Fair enough.
> By the way, the whole solution consists outof the following:
>
> static PyObject *py_proc1(PyObject *self, int ExtraArg, PyObject *args)
> {
>
> Py_RETURN_NONE
> }
>
> static PyObject *py_proc2(PyObject *self, PyObject *args)
> {
>return py_proc1(self, 42, args)
> }
Glad it worked out for you. That "int ExtraArg" bit looks a bit
strange; I thought everything that was exposed to the Python side of
things had to be wrapped in PyObject. Guess I'm wrong?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
I apologize to all but the intended recipient for this. I’d have given him
feedback in private if I knew his email.
I will take leave from the list now. Keep up the good work, friendly
responders.
On Tue, 19 Nov 2019 at 17:13 Luciano Ramalho wrote:
> Now that’s a novel approach to asking for free help: pretending to be
> smarter than the people who are trying to help you.
>
> On Tue, 19 Nov 2019 at 14:17 R.Wieser wrote:
>
>> Michael,
>>
>> > Sure but the Python methods* themselves are exposed and accessible
>> > and according to your previous posts, all you want to do is add an
>> > argument to a call to the existing method. If that's true, then you
>> > should be able to do that part from pure Python.
>>
>> >* class methods defined by the C code
>>
>> Feel free to post code showing that it can be done. The extension is
>> RPi.GPIO, the method is "output", and the extra argument is the pinnaming
>> scheme (BCM or BOARD). Success! :-p
>>
>> > I can understand that the pure C stuff is not accessible of course.
>> > But the snippets you've shown so far don't show any of that.
>>
>> Where did you think that "static PyObject *py_proc1(PyObject *self,
>> PyObject
>> *args)" came from, or why I said "I've also tried to go the C way" ?
>> Besides that, the subject line should have been a dead giveaway by
>> itself ...
>>
>> > We're working in the dark here
>>
>> Are you sure ? MRAB didn't seem to have too much problems with both
>> recognising and understanding what I was busy with - he posted a spot-on
>> example, containing not more, but also not anything less than what I was
>> asking for.
>>
>> > Looking at existing examples, as well as the C API documentation
>>
>> I did not find any example that showed me what I needed to know - simply
>> one
>> CPython function calling another one.And yes, I've found multiple
>> documentation pages, including the "Extending and Embedding the Python
>> Interpreter" ones. Alas, no dice.
>>
>> Most of that documentation is only good when you already know what you are
>> looking for, and need to make sure of its exact usage. Not so much the
>> other way around, when you have no clue and are searching for what you
>> need
>> to use to solve a particular problem (even one as stupid as just calling
>> another method)
>>
>>
>> By the way, the whole solution consists outof the following:
>>
>> static PyObject *py_proc1(PyObject *self, int ExtraArg, PyObject *args)
>> {
>>
>> Py_RETURN_NONE
>> }
>>
>> static PyObject *py_proc2(PyObject *self, PyObject *args)
>> {
>>return py_proc1(self, 42, args)
>> }
>>
>> Regards,
>> Rudy Wieser
>>
>>
>>
>>
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
> --
> Luciano Ramalho
> | Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> | Technical Principal at ThoughtWorks
> | Twitter: @ramalhoorg
>
--
Luciano Ramalho
| Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
| Technical Principal at ThoughtWorks
| Twitter: @ramalhoorg
--
https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
Now that’s a novel approach to asking for free help: pretending to be
smarter than the people who are trying to help you.
On Tue, 19 Nov 2019 at 14:17 R.Wieser wrote:
> Michael,
>
> > Sure but the Python methods* themselves are exposed and accessible
> > and according to your previous posts, all you want to do is add an
> > argument to a call to the existing method. If that's true, then you
> > should be able to do that part from pure Python.
>
> >* class methods defined by the C code
>
> Feel free to post code showing that it can be done. The extension is
> RPi.GPIO, the method is "output", and the extra argument is the pinnaming
> scheme (BCM or BOARD). Success! :-p
>
> > I can understand that the pure C stuff is not accessible of course.
> > But the snippets you've shown so far don't show any of that.
>
> Where did you think that "static PyObject *py_proc1(PyObject *self,
> PyObject
> *args)" came from, or why I said "I've also tried to go the C way" ?
> Besides that, the subject line should have been a dead giveaway by
> itself ...
>
> > We're working in the dark here
>
> Are you sure ? MRAB didn't seem to have too much problems with both
> recognising and understanding what I was busy with - he posted a spot-on
> example, containing not more, but also not anything less than what I was
> asking for.
>
> > Looking at existing examples, as well as the C API documentation
>
> I did not find any example that showed me what I needed to know - simply
> one
> CPython function calling another one.And yes, I've found multiple
> documentation pages, including the "Extending and Embedding the Python
> Interpreter" ones. Alas, no dice.
>
> Most of that documentation is only good when you already know what you are
> looking for, and need to make sure of its exact usage. Not so much the
> other way around, when you have no clue and are searching for what you need
> to use to solve a particular problem (even one as stupid as just calling
> another method)
>
>
> By the way, the whole solution consists outof the following:
>
> static PyObject *py_proc1(PyObject *self, int ExtraArg, PyObject *args)
> {
>
> Py_RETURN_NONE
> }
>
> static PyObject *py_proc2(PyObject *self, PyObject *args)
> {
>return py_proc1(self, 42, args)
> }
>
> Regards,
> Rudy Wieser
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
Luciano Ramalho
| Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
| Technical Principal at ThoughtWorks
| Twitter: @ramalhoorg
--
https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
Michael,
> Sure but the Python methods* themselves are exposed and accessible
> and according to your previous posts, all you want to do is add an
> argument to a call to the existing method. If that's true, then you
> should be able to do that part from pure Python.
>* class methods defined by the C code
Feel free to post code showing that it can be done. The extension is
RPi.GPIO, the method is "output", and the extra argument is the pinnaming
scheme (BCM or BOARD). Success! :-p
> I can understand that the pure C stuff is not accessible of course.
> But the snippets you've shown so far don't show any of that.
Where did you think that "static PyObject *py_proc1(PyObject *self, PyObject
*args)" came from, or why I said "I've also tried to go the C way" ?
Besides that, the subject line should have been a dead giveaway by
itself ...
> We're working in the dark here
Are you sure ? MRAB didn't seem to have too much problems with both
recognising and understanding what I was busy with - he posted a spot-on
example, containing not more, but also not anything less than what I was
asking for.
> Looking at existing examples, as well as the C API documentation
I did not find any example that showed me what I needed to know - simply one
CPython function calling another one.And yes, I've found multiple
documentation pages, including the "Extending and Embedding the Python
Interpreter" ones. Alas, no dice.
Most of that documentation is only good when you already know what you are
looking for, and need to make sure of its exact usage. Not so much the
other way around, when you have no clue and are searching for what you need
to use to solve a particular problem (even one as stupid as just calling
another method)
By the way, the whole solution consists outof the following:
static PyObject *py_proc1(PyObject *self, int ExtraArg, PyObject *args)
{
Py_RETURN_NONE
}
static PyObject *py_proc2(PyObject *self, PyObject *args)
{
return py_proc1(self, 42, args)
}
Regards,
Rudy Wieser
--
https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
On 11/19/19 9:00 AM, Michael Torrie wrote: > Sure but the Python methods themselves are exposed and accessible and > according to your previous posts, I meant to say the class methods defined by the C code. -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
On 11/19/19 1:09 AM, R.Wieser wrote: > Michael > >> Does this have to be done in the C API? > > As far as I can tell, yes. What I need to do is not exposed by the > extension itself, meaning that a wrapper class can't get access to it > either. Sure but the Python methods themselves are exposed and accessible and according to your previous posts, all you want to do is add an argument to a call to the existing method. If that's true, then you should be able to do that part from pure Python. The beauty of the C API is that anything you define there should be visible and accessible from pure Python world. I can understand that the pure C stuff is not accessible of course. But the snippets you've shown so far don't show any of that. > And its just a syntax problem. I currently simply have not enough knowledge > about the CPython API lanuages one to be able to even do a simple call ... > :-\ Are you able to post the C code, or at least enough of it that can actually compile? It'd be much easier to help if we had something to work with. We're working in the dark here so it's difficult to know exactly where to direct you. It's always best on the list to work with complete, standalone, minimal examples. Looking at existing examples, as well as the C API documentation, are how I figured out how to use it some years back when I needed to do a small thing in C, although I've forgotten most of it now. -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
MRAB, > It could be something like this: [snip example code] Thank you very much. Your "Call the other method" line shows me that I've been overthinking things. :-( After that I decided to see if I could give the "py_proc1" function two arguments, which worked. That means that the prepending of "foo" (to the origional one) has been changed into transferring it on its own (much easier for both the caller as well as the callee). Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
Michael > Does this have to be done in the C API? As far as I can tell, yes. What I need to do is not exposed by the extension itself, meaning that a wrapper class can't get access to it either. And its just a syntax problem. I currently simply have not enough knowledge about the CPython API lanuages one to be able to even do a simple call ... :-\ Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
On 11/18/19 1:15 PM, R.Wieser wrote: > The thing is that the arguments of py_proc1 and py_proc2 are the same, but > for a single argument. Does this have to be done in the C API? Depending on how this class is used in your Python code, I would just create a new Python class that extends this class defined in the C code. Then it's more a matter of: import cmodule class NewClass(cmodule.OldClass): def my_proc2(self, *args): b=3 self.my_proc1( *((b,) + args) ) #OldClass.my_proc1 Now any instance of NewClass has a method called my_proc2 which calls the my_proc1 from the C API defined class with the extra argument prepended. The "*" notation is to unpack the tuple, which is used when calling another function that takes positional arguments. -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
On 2019-11-18 20:15, R.Wieser wrote:
MRAB,
One possibility is to refactor the code so that py_proc1 and py_proc2
themselves just handle their arguments and then call the function that
does the actual work.
The thing is that the arguments of py_proc1 and py_proc2 are the same, but
for a single argument. Which means that letting both of them first parse
their own arguments means duplicated code.Which I do not really want and
thus try to evade
But yes, that is a possibility too. The "the function that does the actual
work" part is what I tried to describe with my second example.
A clunkier way would be to make a new tuple that consists of the prepended
item and the items of args and pass that to py_proc1 as its args.
That is what I tried to describe with my first example.
The thing is I have no clue about what the above calling should look like
(though I think I already found how to append my argument to the "args"
string-object).
In other words, do you have any idea of what either of those calling methods
should look like ? An example perhaps ? Having only encountered the
CPython API two days ago I'm still fumbling in the dark I'm afraid.
It could be something like this:
static PyObject *py_proc2(PyObject *self, PyObject *args)
{
/*** TODO: Add error checking. ***/
PyObject* prepend_arg;
PyObject* prepend_tuple;
PyObject* new_args;
PyObject* result;
/* The object to be prepended. */
prepend_arg = PyUnicode_FromString("foo");
/* Make a tuple from the prepended object. */
prepend_tuple = BuildValue("(O)", prepend_arg);
/* No longer need prepend_arg. */
Py_DECREF(prepend_arg);
/* Make the new argument list. */
new_args = PySequence_Concat(prepend, args);
/* No longer need prepend_tuple. */
Py_DECREF(prepend_tuple);
/* Call the other method. */
result = py_proc1(self, new_args);
/* No longer need new_args. */
Py_DECREF(new_args);
return result;
}
--
https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
MRAB, > One possibility is to refactor the code so that py_proc1 and py_proc2 > themselves just handle their arguments and then call the function that > does the actual work. The thing is that the arguments of py_proc1 and py_proc2 are the same, but for a single argument. Which means that letting both of them first parse their own arguments means duplicated code.Which I do not really want and thus try to evade But yes, that is a possibility too. The "the function that does the actual work" part is what I tried to describe with my second example. > A clunkier way would be to make a new tuple that consists of the prepended > item and the items of args and pass that to py_proc1 as its args. That is what I tried to describe with my first example. The thing is I have no clue about what the above calling should look like (though I think I already found how to append my argument to the "args" string-object). In other words, do you have any idea of what either of those calling methods should look like ? An example perhaps ? Having only encountered the CPython API two days ago I'm still fumbling in the dark I'm afraid. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
Re: Writing a CPython extension - calling another sibbling method ?
On 2019-11-18 07:52, R.Wieser wrote:
Hello all,
I'm trying to edit a binary extension to Python, and have a situation where
I would like to create method which adds a single argument, and than jumps
to / calls another method. Like this:
static PyObject *py_proc1(PyObject *self, PyObject *args)
{
Py_RETURN_NONE
}
static PyObject *py_proc2(PyObject *self, PyObject *args)
{
// call py_proc1 to with "foo" prepended to "args"
}
I have no idea how I should do either the call or the adding of that
argument (and going to a few examples I've found googeling didn't show me
the answer either).
Than again, I'm not even sure if the "foo" needs to be prepended, or if that
"py_proc1" method can receive more than a single "args" argument ... Like
this perhaps:
static PyObject *py_proc1(PyObject *self, int MyNewArgument, PyObject *args)
{
}
I've also tried to go the C way (just calling, from "py_proc2", a C function
containing "py_proc1"s code), but I got lots of errors, most of them in the
realm of the different returns not being of the same type (no idea why it
doesn't complain about it in the origional "py_proc1" code itself though).
tl;dr:
I could use some examples that show how to work withl PyObject subfunctions.
Regards,
Rudy Wieser
P.s.
Yes, this is related to my earlier questions and problems.
One possibility is to refactor the code so that py_proc1 and py_proc2
themselves just handle their arguments and then call the function that
does the actual work.
A clunkier way would be to make a new tuple that consists of the
prepended item and the items of args and pass that to py_proc1 as its
args. When py_proc1 returns its result object, DECREF the new tuple to
clean up and then return the result object.
--
https://mail.python.org/mailman/listinfo/python-list
Writing a CPython extension - calling another sibbling method ?
Hello all,
I'm trying to edit a binary extension to Python, and have a situation where
I would like to create method which adds a single argument, and than jumps
to / calls another method. Like this:
static PyObject *py_proc1(PyObject *self, PyObject *args)
{
Py_RETURN_NONE
}
static PyObject *py_proc2(PyObject *self, PyObject *args)
{
// call py_proc1 to with "foo" prepended to "args"
}
I have no idea how I should do either the call or the adding of that
argument (and going to a few examples I've found googeling didn't show me
the answer either).
Than again, I'm not even sure if the "foo" needs to be prepended, or if that
"py_proc1" method can receive more than a single "args" argument ... Like
this perhaps:
static PyObject *py_proc1(PyObject *self, int MyNewArgument, PyObject *args)
{
}
I've also tried to go the C way (just calling, from "py_proc2", a C function
containing "py_proc1"s code), but I got lots of errors, most of them in the
realm of the different returns not being of the same type (no idea why it
doesn't complain about it in the origional "py_proc1" code itself though).
tl;dr:
I could use some examples that show how to work withl PyObject subfunctions.
Regards,
Rudy Wieser
P.s.
Yes, this is related to my earlier questions and problems.
--
https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] Austin -- CPython frame stack sampler v1.0.0 is now available
Austin computes the deltas of resident memory between samples. That's because resident memory is the closest to the actual space occupied in physical memory. I hope this answers your question! Best, G On Mon, 21 Oct 2019, 22:37 Barry, wrote: > > > > On 20 Oct 2019, at 23:12, Gabriele wrote: > > > > The > > latest release introduces a memory profiling mode which allows you to > > profile memory usage. > > I am curious how do you determine used memory for Python > Program? > What is you definition of “memory”? > > The reason I am asking is that I have looked into this for a production > server app and found only approximations. > > Barry > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] Austin -- CPython frame stack sampler v1.0.0 is now available
> On 20 Oct 2019, at 23:12, Gabriele wrote: > > The > latest release introduces a memory profiling mode which allows you to > profile memory usage. I am curious how do you determine used memory for Python Program? What is you definition of “memory”? The reason I am asking is that I have looked into this for a production server app and found only approximations. Barry -- https://mail.python.org/mailman/listinfo/python-list
[ANN] Austin -- CPython frame stack sampler v1.0.0 is now available
I am delighted to announce the release 1.0.0 of Austin. If you haven't heard of Austin before, it is a frame stack sampler for CPython. It can be used to obtain statistical profiling data out of a running Python application without a single line of instrumentation. This means that you can start profiling a Python application straightaway, even while it's running on a production environment, with minimal impact on performance. The simplest way of using Austin is by piping its output to FlameGraph for a quick and detailed representation of the collected samples. The latest release introduces a memory profiling mode which allows you to profile memory usage. Austin is a pure C application that has no other dependencies other than the C standard library. Its source code is hosted on GitHub at https://github.com/P403n1x87/austin The README contains installation and usage details, as well as some examples of Austin in action. Details on how to contribute to Austin's development can be found at the bottom of the page. All the best, Gabriele What's New == - Added support for multi-process Python applications. - Added support for Python 3.8. Bugfixes - Fixed support for WSL on Windows. -- https://mail.python.org/mailman/listinfo/python-list
Re: fopen() and open() in cpython
Thank you so much for the answer, now it makes sense :D eryk sun 于2019年8月15日周四 上午12:27写道： > On 8/13/19, Windson Yang wrote: > > After my investigation, I found Since Python maintains its own buffer > when > > read/write files, the build-in python open() function will call the > open() > > system call instead of calling standard io fopen() for caching. So when > we > > read/write a file in Python, it would not call fopen(), fopen() only use > > for Python itself but not for python user. Am I correct? > > Python 2 I/O wraps C FILE streams (i.e. fopen, fclose, fread, fwrite, > fgets). Python 3 has its own I/O stack (raw, buffered, text) that aims > to be more reliably cross-platform than C FILE streams. Python 3 still > uses FILE streams internally in some cases (e.g. to read pyvenv.cfg at > startup). > > FYI in Windows open() or _wopen() is a C runtime library function, not > a system function. It calls the Windows API function CreateFile, which > calls the NT system function, NtCreateFile. It's similarly layered for > all calls, e.g. read() calls ReadFile or ReadConsoleW, which calls > NtReadFile or NtDeviceIoControlFile (ReadConsoleW). > -- https://mail.python.org/mailman/listinfo/python-list
Re: fopen() and open() in cpython
On 8/13/19, Windson Yang wrote: > After my investigation, I found Since Python maintains its own buffer when > read/write files, the build-in python open() function will call the open() > system call instead of calling standard io fopen() for caching. So when we > read/write a file in Python, it would not call fopen(), fopen() only use > for Python itself but not for python user. Am I correct? Python 2 I/O wraps C FILE streams (i.e. fopen, fclose, fread, fwrite, fgets). Python 3 has its own I/O stack (raw, buffered, text) that aims to be more reliably cross-platform than C FILE streams. Python 3 still uses FILE streams internally in some cases (e.g. to read pyvenv.cfg at startup). FYI in Windows open() or _wopen() is a C runtime library function, not a system function. It calls the Windows API function CreateFile, which calls the NT system function, NtCreateFile. It's similarly layered for all calls, e.g. read() calls ReadFile or ReadConsoleW, which calls NtReadFile or NtDeviceIoControlFile (ReadConsoleW). -- https://mail.python.org/mailman/listinfo/python-list
