Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

[Antoine Pitrou]

On Mon, 19 Feb 2018 20:15:27 +0100
Stefan Behnel  wrote:
> Nick Coghlan schrieb am 02.02.2018 um 06:47:
> > to make the various extension module authoring tools
> > easier to discover, rather than having folks assuming that handcrafted
> > calls directly into the CPython C API is their only option.  
> 
> Or even a competitive option. Tools like Cython or pybind11 go to great
> length to shave off every bit of overhead from C-API calls, commonly
> replacing high-level C-API functionality with macros and direct access to
> data structures. The C/C++ code that they generate is so complex and tuned
> that it would be infeasible to write and maintain something like that by
> hand, but it can perfectly be generated, and it usually performs visibly
> better than most hand-written modules, definitely much better than anything
> a non-expert could write.
> 
> Basically, by not learning the C-API you can benefit from all that highly
> tuned and specialised code written by C-API experts that the documentation
> doesn't even tell you about.

Doesn't the documentation ever mention Cython? It probably should (no
idea about pybind11, which I've never played with). Perhaps you can
open an issue about that?

As a sidenote, you can certainly use Cython without learning the C API,
but to extract maximum performance it's better to know the C API
anyway, to be aware of what kind of optimizations are available in
which situations.

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Stephen J. Turnbull]

Guido van Rossum writes:

 > Hm, perhaps Integral is an adjective, just like Boolean?

I would guess so.  This is the same idiom we use when we call
[1, 2, 3] a "truth-y".

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Nick Coghlan]

On 20 February 2018 at 08:33, Guido van Rossum  wrote:
> Hm, perhaps Integral is an adjective, just like Boolean? Though it's also
> possible that it was simply a mistake. In general I don't like adding
> aliases for different spellings -- it violates TOOWTDI. If we decide that
> this really was a mistake we should go ahead and make Integer the
> recommended way and define Integral as an alias for backwards compatibility.

FWIW, I had to run `dir(numbers)` while tinkering at the REPL based on
this discussion, because I was surprised that "numbers.Integer" was
giving me an attribute error.

Checking PEP 3141 doesn't shed any light on the question either -
while that cites Scheme as the origin of the numeric tower structure,
the given reference at
https://groups.csail.mit.edu/mac/ftpdir/scheme-reports/r5rs-html/r5rs_8.html#SEC50
uses "integer" rather than "integral".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Guido van Rossum]

On Mon, Feb 19, 2018 at 5:58 AM, Sylvain MARIE <
sylvain.ma...@schneider-electric.com> wrote:

> > A thought just occurred to me. Maybe we should just add a Boolean class
> to numbers?
>
> That would be great indeed
>
> > It's a subclass of Integral, presumably. And normally only builtins.bool
> is registered with it. But np.bool can be added at the same point you
> register the other np integral types.
>
> I would rather suggest to keep that Boolean ABC class independent of
> Integral (see proposal in first post) to let it remain 'pure', i.e.
> represent logical booleans only. However nothing prevents us to register
> python bool as a virtual subclass of *both* Integral and Boolean - while
> np.bool would be registered as a virtual subclass of Boolean only. This
> would reflect quite well the reality - the fact that python bool is both a
> Boolean and an Integer, while numpy bool is only a Boolean.
>

OK, that could work. At this point I think you should just file an issue on
bugs.python.org (but since Python 3.7 is in feature freeze, expect this to
be put on the 3.8 track).


> By the way, is there a reason for the name "Integral" (algebraic theory)
> instead of "Integer" (computer science) ? Would it be practically feasible
> to add "Integer" as an alias to "Integral" in the numbers package ?
>

Hm, perhaps Integral is an adjective, just like Boolean? Though it's also
possible that it was simply a mistake. In general I don't like adding
aliases for different spellings -- it violates TOOWTDI. If we decide that
this really was a mistake we should go ahead and make Integer the
recommended way and define Integral as an alias for backwards compatibility.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 468

[Brett Cannon]

FYI I have unsubscribed this person from the mailing list. If they persist
to send empty emails I will figure out how to block them.

On Sun, 18 Feb 2018 at 22:04 guido  wrote:

>
>
>
>
> Gesendet von Mail  für
> Windows 10
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

[Stefan Behnel]

Nick Coghlan schrieb am 02.02.2018 um 06:47:
> to make the various extension module authoring tools
> easier to discover, rather than having folks assuming that handcrafted
> calls directly into the CPython C API is their only option.

Or even a competitive option. Tools like Cython or pybind11 go to great
length to shave off every bit of overhead from C-API calls, commonly
replacing high-level C-API functionality with macros and direct access to
data structures. The C/C++ code that they generate is so complex and tuned
that it would be infeasible to write and maintain something like that by
hand, but it can perfectly be generated, and it usually performs visibly
better than most hand-written modules, definitely much better than anything
a non-expert could write.

Basically, by not learning the C-API you can benefit from all that highly
tuned and specialised code written by C-API experts that the documentation
doesn't even tell you about.

Stefan

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

[David Foster]

(1) This proposal serves well to eliminate repeated computations by 
allowing what is an inline assignment to a temporary variable. But it 
doesn't seem to make the case of None-aware operators any less verbose 
than they would be otherwise.


Proposal:
value = ?it.strip()[4:].upper() if (?it=var1) is not None else None
Traditional:
it = var1
value = it.strip()[4:].upper() if it is not None else None

If we wanted to get rid of the "if it is not None else None" 
boilerplate, we'd need something more concise. For example - completely 
off the cuff - syntax like:

value = var1?.strip()[4:].upper()

I'm not really interested in going down a rabbit hole of discussing 
those kinds of syntax alternatives on this thread. I just want to point 
out that the current proposal don't seem to make None-aware operations 
much more concise than they were before except in the case of complex 
subexpressions being None-tested, which I find uncommon in my own programs.


(2) In considering the proposal in the alternative light of specifically 
trying to eliminate complex subexpressions, I'll also put a +1 in for 
(expr as it) rather than (?it=) since I find it reads nicer. Also is 
consistent with existing syntax (with expr as var).


Cheers,
David

--
David Foster | Seattle, WA, USA

On 2/15/18 6:06 PM, Nick Coghlan wrote:

The recent thread on variable assignment in comprehensions has
prompted me to finally share
https://gist.github.com/ncoghlan/a1b0482fc1ee3c3a11fc7ae64833a315 with
a wider audience (see the comments there for some notes on iterations
I've already been through on the idea).

== The general idea ==

The general idea would be to introduce a *single* statement local
reference using a new keyword with a symbolic prefix: "?it"

* `(?it=expr)` is a new atomic expression for an "it reference
binding" (whitespace would be permitted around "?it" and "=", but PEP
8 would recommend against it in general)
* subsequent subexpressions (in execution order) can reference the
bound subexpression using `?it` (an "it reference")
* `?it` is reset between statements, including before entering the
suite within a compound statement (if you want a persistent binding,
use a named variable)
* for conditional expressions, put the reference binding in the
conditional, as that gets executed first
* to avoid ambiguity, especially in function calls (where it could be
confused with keyword argument syntax), the parentheses around
reference bindings are always required
* unlike regular variables, you can't close over statement local
references (the nested scope will get an UnboundLocalError if you try
it)

The core inspiration here is English pronouns (hence the choice of
keyword): we don't generally define arbitrary terms in the middle of
sentences, but we *do* use pronouns to refer back to concepts
introduced earlier in the sentence. And while it's not an especially
common practice, pronouns are sometimes even used in a sentence
*before* the concept they refer to ;)

If we did pursue this, then PEPs 505, 532, and 535 would all be
withdrawn or rejected (with the direction being to use an it-reference
instead).

== Examples ==

`None`-aware attribute access:

value = ?it.strip()[4:].upper() if (?it=var1) is not None else None

`None`-aware subscript access:

value = ?it[4:].upper() if (?it=var1) is not None else None

`None`-coalescense:

value = ?it if (?it=var1) is not None else ?it if (?it=var2) is
not None else var3

`NaN`-coalescence:

value = ?it if not math.isnan((?it=var1)) else ?it if not
math.isnan((?that=var2)) else var3

Conditional function call:

value = ?it() if (?it=calculate) is not None else default

Avoiding repeated evaluation of a comprehension filter condition:

filtered_values = [?it for x in keys if (?it=get_value(x)) is not None]

Avoiding repeated evaluation for range and slice bounds:

range((?it=calculate_start()), ?it+10)
data[(?it=calculate_start()):?it+10]

Avoiding repeated evaluation in chained comparisons:

value if (?it=lower_bound()) <= value < ?it+tolerance else 0

Avoiding repeated evaluation in an f-string:

print(f"{?it=get_value()!r} is printed in pure ASCII as {?it!a}
and in Unicode as {?it}"

== Possible future extensions ==

One possible future extension would be to pursue PEP 3150, treating
the nested namespace as an it reference binding, giving:

sorted_data = sorted(data, key=?it.sort_key) given ?it=:
def sort_key(item):
return item.attr1, item.attr2

(A potential bonus of that spelling is that it may be possible to make
"given ?it=:" the syntactic keyword introducing the suite, allowing
"given" itself to continue to be used as a variable name)

Another possible extension would be to combine it references with `as`
clauses on if statements and while loops:

if (?it=pattern.match(data)) is not None as matched:
...

while (?it=pattern.match(data)) is not None as matched:
...

Re: [Python-ideas] Coming up with an alternative to PEP 505's None-aware operators

[Ethan Furman]

On 02/18/2018 05:57 PM, Nick Coghlan wrote:

On 17 February 2018 at 02:31, Ethan Furman wrote:

On 02/15/2018 11:55 PM, Nick Coghlan wrote:



However, while I think that looks nicer in general, we'd still have to
choose between two surprising behaviours:

* implicitly delete the statement locals after the statement where
they're set (which still overwrites any values previously bound to
those names, similar to what happens with exception clauses)



If we're overwriting locals anyway, don't delete it.  The good reason for
unsetting an exception variable doesn't apply here.


* skip deleting, which means references to subexpressions may last
longer than expected (and we'd have the problem where embedded
assignments could overwrite existing local variables)


Odds are good that we'll want/need that assignment even after the immediate
expression it's used in.  Let it stick around.


If we want to use a subexpression in multiple statements, then regular
assignment statements already work fine - breaking out a separate
variable assignment only feels like an inconvenience when we use a
subexpression twice in a single statement, and then don't need it any
further.

By contrast, if we have an implicit del immediately after the
statement for any statement local variables, then naming a
subexpression only extends its life to the end of the statement, not
to the end of the current function, and it's semantically explicit
that you *can't* use statement locals to name subexpressions that
*aren't* statement local.

The other concern I have with any form of statement local variables
that can overwrite regular locals is that we'd be reintroducing the
problem that comprehensions have in Python 2.x: unexpectedly rebinding
things in non-obvious ways. At least with an implicit "del" the error
would be more readily apparent, and if we disallow closing over
statement local variables (which would be reasonable, since closures
aren't statement local either), then we can avoid interfering with
regular locals without needing to introduce a new execution scope.


Good points.  I see two possibly good solutions:

- don't override existing local variables, implicit del after statement
- override existing local variables, no implicit del after statement

I like the first one better, as it mirrors list comprehensions and is simple to understand.  The second one is okay, and 
if significantly easier to implement I would be okay with.  It's the combination of:


- override existing local variables, implicit del after statement

that I abhor.  As I understand it, only try/except has that behavior -- and we have a really good reason for it, and 
it's the exception to the general rule, and...


Okay, after further thought I like the second one better.  List comps have the outside brackets as a reminder that they 
have their own scope, but these "statement local" variables only have internal parenthesis.  I still don't like the 
third option.


--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Serhiy Storchaka]

15.02.18 18:27, Guido van Rossum пише:
A thought just occurred to me. Maybe we should just add a Boolean class 
to numbers? It's a subclass of Integral, presumably.


Isn't bool a subclass of int only for historical reasons? I think that 
if bool was in Python from the beginning, it would not be an int subclass.


Operations inherited from int like division or bits shift doesn't make 
sense as boolean operations. The only boolean operations are testing for 
truthfulness, `not`, `and` and `or`. But every object in Python supports 
them. The bool class is just a type of constants True and False.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Sylvain MARIE]

> A thought just occurred to me. Maybe we should just add a Boolean class to 
> numbers?

That would be great indeed

> It's a subclass of Integral, presumably. And normally only builtins.bool is 
> registered with it. But np.bool can be added at the same point you register 
> the other np integral types.

I would rather suggest to keep that Boolean ABC class independent of Integral 
(see proposal in first post) to let it remain 'pure', i.e. represent logical 
booleans only. However nothing prevents us to register python bool as a virtual 
subclass of *both* Integral and Boolean - while np.bool would be registered as 
a virtual subclass of Boolean only. This would reflect quite well the reality - 
the fact that python bool is both a Boolean and an Integer, while numpy bool is 
only a Boolean.

By the way, is there a reason for the name "Integral" (algebraic theory) 
instead of "Integer" (computer science) ? Would it be practically feasible to 
add "Integer" as an alias to "Integral" in the numbers package ? 

Sylvain 

-Message d'origine-
De : Chris Barker - NOAA Federal [mailto:chris.bar...@noaa.gov] 
Envoyé : vendredi 16 février 2018 22:42
À : gu...@python.org
Cc : Sylvain MARIE ; Python-Ideas 

Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 
'numbers' module

Sent from my iPhone
> A thought just occurred to me. Maybe we should just add a Boolean class to 
> numbers?

This makes lots of sense to me.

Bool is a subclass of int — might as well embrace that fact.

-CHB

__
This email has been scanned by the Symantec Email Security.cloud service.
__
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/