> At a technical level, the biggest problems relate to the way we
> manipulate frame objects at runtime, including the fact that we expose
> those frames programmatically for the benefit of debuggers and other
> tools.
Shoudnt be something that could be tackled with the introduction of a
kind of "
In South Asia, a different style of digit delimiters for large numbers is
used than in Europe, North America, Australia, etc. With some minor
spelling differences, the term lakh is used for a hundred-thousand, and it
is generally written as '1,00,000'.
In turn, a crore is 100 lakh, and is written
On 28 January 2018 at 07:18, Pau Freixes wrote:
> Regarding the cost of calling a function, that I can guess is not
> related with the previous stuff, what is an impediment right now to
> make it faster ?
At a technical level, the biggest problems relate to the way we
manipulate frame objects at
>
> def filter(rule, whatever):
> if rule.x in whatever.x:
> return True
>
> rules = get_rules()
> whatevers = get_whatevers()
> for rule in rules:
> for whatever in whatevers:
> if filter(rule, whatever):
> cnt = cnt + 1
>
> return cnt
>
This code seems almost
Hi,
Thanks to all of you for your responses, the points of view and the
information that you shared to back up your rationales, I had some
time to visit few of them but sure I will try to suit the proper time
to review all of them.
It's hard to try to keep the discussion organized responding at e
Hi all,
I would like to remark that, in my opinion, the question of CPython's
performance cannot
be decoupled from the extremely wide selection of packages which provide
optimized
code for almost any imaginable task.
For example: Javascript may be faster than (C)Python on simple benchmarks,
but
a
