date:20180706


On 06.07.2018 7:02, Chris Angelico wrote:

On Fri, Jul 6, 2018 at 12:48 PM, Alexander Belopolsky
 wrote:

Python really has a strong C legacy and this is the area where I agree that
C designers made a mistake by picking a symmetric symbol (=) for an
asymmetric operation. On top of that, they picked an asymmetric digraph (!=)
for a symmetric operation as well and Python (unfortunately) followed the
crowd and ditched a much better alternative (<>).  My only hope is that
Python 4.0 will allow ← to be used in place of either = or :=. :-)

Interesting. Looking over Python's binary operators, we have:

|, ^, &, +, *: symmetric (on ints)
-, /, //, **: asymmetric
<, >: mirrored operations
<=, >=: mirrored operations but not reflected
<<, >>: non-mirrored asymmetric
and, or: technically asymmetric but often treated as symmetric
in, not in: asymmetric
is, is not: symmetric

Which ones ought to have symmetric symbols, in an ideal world? Should
<= and >= be proper mirrors of each other? Are << and >> confusing? Is
it a problem that the ** operator is most decidedly asymmetric?

Personally, I'm very happy that the operators use the same symbols
that they do in other languages - U+002B PLUS SIGN means addition, for
instance - and everything else is secondary. But maybe this is one of
those "hidden elegances" that you're generally not *consciously* aware
of, but which makes things "feel right", like how Disney's "Moana" has
freedom to the right of the screen and duty to the left. Are there
languages where symmetric operations are always represented with
symmetric symbols and vice versa?


Nothing like that.
The connotations for the symbols rather draw from other fields that 
we're familiar with.


Primarily math (that everyone has studied at school -- this is also the 
reason why we use infix notation even though the postfix one allows to 
ditch braces);

in particular, % draws from ÷ (division sign), / from fraction sign;
& is from English;
!, | and ^ are a mash from "the closest unused symbols on keyboard" to 
symbols from logic algebra:

   ¬  (https://en.wikipedia.org/wiki/Negation),∨ {\displaystyle \lor }
  ∨ (https://en.wikipedia.org/wiki/Logical_disjunction),
  ∧ (https://en.wikipedia.org/wiki/Logical_conjunction),
 ↑ or | (https://en.wikipedia.org/wiki/Sheffer_stroke),
 ↓ (https://en.wikipedia.org/wiki/Peirce's_arrow);

"!=" reads literally "not equal" ( ! is "not", = is "equal" )
   (while "<>" reads "less or greater" which is mathematically not 
equivalent to that: not everything has a defined ordering relation. "<>" 
draws from BASIC AFAIK which was geared towards regular users who don't 
deal with advanced mathematics.)



ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comparing PEP 576 and PEP 580


On 2018-07-05 21:57, Guido van Rossum wrote:

Would it be possible to get outside experts to help?


I don't understand what you mean: to help with what? Designing the PEP? 
Discussing the PEP? Accepting the PEP? Lobbying Python core devs?


The Cython developers (in particular Stefan Behnel) certainly support my 
work. I have talked with them in person at a workshop and they posted a 
few emails to python-dev and they also gave me some personal comments 
about PEP 580.


As for NumPy, one obvious place where some ideas of PEP 579 could be 
applied is ufuncs. However, typically ufuncs are not *called* in tight 
loops, they implement tight loops internally. So I don't think that 
there is pressing need for anything like PEP 580 in NumPy.



Jeroen.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] On the METH_FASTCALL calling convention


On 2018-07-06 06:07, INADA Naoki wrote:

Maybe, one way to improve METH_FASTCALL | METH_KEYWORDS can be this.
kwds can be either tuple or dict.


But that would be just pushing the complexity down to the callee. I'd 
rather have a simpler protocol at the expense of a slightly more complex 
supporting API.


I also don't see the point: the calls where performance truly matters 
typically don't use keyword arguments anyway (independently of whether 
the called function accepts them).


Moreover, the large majority of functions take normal keyword arguments, 
not **kwargs. When parsing those arguments, the dict would need to be 
unpacked anyway. So you don't gain much by forcing the callee to handle 
that instead of doing it in PyCCall_FASTCALL().


Functions just passing through **kwargs (say, functools.lru_cache) don't 
need a dict either: they can implement the C call protocol of PEP 580 
with METH_FASTCALL and then call the wrapped function also using FASTCALL.


So really the only remaining case is when the callee wants to do 
something with **kwargs as dict. But I find it hard to come up with a 
natural use case for that, especially one where performance matters. And 
even then, that function could just use METH_VARARGS.


So I don't see any compelling reason to allow a dict in METH_FASTCALL.


Jeroen.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comparing PEP 576 and PEP 580

2018-07-06 Thread Chris Barker - NOAA Federal via Python-Dev


On 2018-07-05 14:20, INADA Naoki wrote:

like you ignored my advice about creating realistic benchmark for
calling 3rd party callable before talking about performance...


I didn't really want to ignore that, I just didn't know what to do.

As far as I can tell, the official Python benchmark suite is 
https://github.com/python/performance

However, that deals only with pure Python code, not with the C API.
So those benchmarks are not relevant to PEP 580.


Jeroen.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comparing PEP 576 and PEP 580

2018-07-06 Thread INADA Naoki

On Fri, Jul 6, 2018 at 7:50 PM Jeroen Demeyer  wrote:
>
> On 2018-07-05 14:20, INADA Naoki wrote:
> > like you ignored my advice about creating realistic benchmark for
> > calling 3rd party callable before talking about performance...
>
> I didn't really want to ignore that, I just didn't know what to do.
>
> As far as I can tell, the official Python benchmark suite is
> https://github.com/python/performance
> However, that deals only with pure Python code, not with the C API.
> So those benchmarks are not relevant to PEP 580.
>

These benchmarks uses 3rd party extension modules.  For example,
mako benchmark uses Mako, and Mako uses MarkupSafe.
I optimized MarkupSafe based on the benchmark.
https://github.com/pallets/markupsafe/pull/64

If bm_mako or some other existing benchmarks is OK to demonstrate
METH_FASTCALL benefits, you can just customize 3rd party
library and compare performance.

If it's not enough, you should write new benchmark to demonstrate it.
One important point is the benchmark should demonstrate "application"
performance.   Comparing just overhead of METH_VARARGS vs METH_FASTCALL
is useless, because we did it already.

What you should demonstrate is: METH_FASTCALL (or METH_FASTCALL | METH_KEYWORDS)
really boost real world application performance.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Examples for PEP 572

2018-07-06 Thread Mike Miller




On 2018-07-04 00:25, Nathaniel Smith wrote:

The only cases that seem potentially valuable to me are the ones that
are literally the form 'if  := ` and 'while  :=
'. (I suspect these are the only cases that I would allow in
code that I maintain.) The PEP does briefly discuss the alternative
proposal of restricting to just these two cases, but rejects it
because it would rule out code like 'if ( := )
 '. But those are exactly the cases that I want to
rule out, so that seems like a plus to me :-).

The 'if  as ' syntax would be a simple way to encode
exactly these simple non-harmful cases. The PEP rejects it on the
grounds that 'as' is already used in a different way by 'except' and
'with'. But... 'as' is *also* used in the *same* way by 'import', so
the argument feels disingenuous. Yeah, there'd be an inconsistency,
but that inconsistency already exists, and adding 'if ... as' and
'while ... as' wouldn't create any *new* inconsistencies.



Agreed, tried to make this point in several threads.

-Mike
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

Are we just having fun here?

Or might we actually start using a new naming convention for
the-syntax-formerly-known-as-generator-expressions?

-CHB

Sent from my iPhone

> On Jul 3, 2018, at 11:54 PM, Greg Ewing  wrote:
>
> Steven D'Aprano wrote:
>> - list builder syntax is syntax which returns a list;
>> - dict builder syntax is syntax which returns a dict;
>> - set builder syntax is syntax which returns a set;
>> - generator builder syntax is syntax which returns a generator.
>
> You only get a list/dict/set from the first three after
> you've run the iterators within it, but with a generator
> expression, you already have a generator before you've
> run it. That makes it feel different to me.
>
> --
> Greg
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2018-07-06 Thread Python tracker


ACTIVITY SUMMARY (2018-06-29 - 2018-07-06)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open6721 (+16)
  closed 39090 (+44)
  total  45811 (+60)

Open issues with patches: 2675 


Issues opened (43)
==

#33735: test_multiprocessing_spawn leaked [1, 2, 1] memory blocks on A
https://bugs.python.org/issue33735  reopened by vstinner

#34001: LibreSSL does not tolerate setting minimum_version greater tha
https://bugs.python.org/issue34001  opened by Alan.Huang

#34002: minor efficiency and clarity improvements in email package
https://bugs.python.org/issue34002  opened by selik

#34003: csv.DictReader can return basic dict instead of OrderedDict
https://bugs.python.org/issue34003  opened by selik

#34004: Acquiring locks not interrupted by signals on musl libc
https://bugs.python.org/issue34004  opened by Joseph Sible

#34007: test_gdb fails in s390x SLES buildbots
https://bugs.python.org/issue34007  opened by pablogsal

#34008: Do we support calling Py_Main() after Py_Initialize()?
https://bugs.python.org/issue34008  opened by ncoghlan

#34009: Document Travis CI / Ubuntu 14.04 OpenSSL compatibility issues
https://bugs.python.org/issue34009  opened by ncoghlan

#34011: Default preference not given to venv DLL's
https://bugs.python.org/issue34011  opened by jonathan-lp

#34012: No option to include system headers in distutils.core.Extensio
https://bugs.python.org/issue34012  opened by danh

#34013: Inconsistent SyntaxError for print
https://bugs.python.org/issue34013  opened by corona10

#34014: loop.run_in_executor should propagate current contextvars
https://bugs.python.org/issue34014  opened by hellysmile

#34017: Tkinter CheckButton not working in EXE
https://bugs.python.org/issue34017  opened by elfantroussi

#34019: webbrowser: wrong arguments for Opera browser.
https://bugs.python.org/issue34019  opened by kbumsik

#34021: [2.7] test_regrtest: test_env_changed() fails on x86 Windows X
https://bugs.python.org/issue34021  opened by vstinner

#34022: 6 tests fail using SOURCE_DATE_EPOCH env var
https://bugs.python.org/issue34022  opened by vstinner

#34023: timedelta(seconds=x) strange results when type(x) ==  np.int32
https://bugs.python.org/issue34023  opened by mark.dickinson

#34025: SMTP EmailPolicy not using the correct line length for RCF 204
https://bugs.python.org/issue34025  opened by Douglas Thor

#34026: Request for 2 Windows installation changes.
https://bugs.python.org/issue34026  opened by terry.reedy

#34027: python 3.7 openpty/forkpty build failure using nix package man
https://bugs.python.org/issue34027  opened by LnL7

#34028: Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged mi
https://bugs.python.org/issue34028  opened by [email protected]

#34029: tkinter.filedialog.askdirectory() crashing before dialog opens
https://bugs.python.org/issue34029  opened by rsteel1

#34031: [EASY] Incorrect usage of unittest.TestCase in test_urllib2_lo
https://bugs.python.org/issue34031  opened by pablogsal

#34032: Add platlibdir to allow distinction between /usr/lib and /usr/
https://bugs.python.org/issue34032  opened by mcepl

#34033: distutils is not reproducible
https://bugs.python.org/issue34033  opened by vstinner

#34034: Python 3.7.0 multiprocessing forkserver ForkingPickler behavio
https://bugs.python.org/issue34034  opened by Santiago Hernandez

#34035: zipfile: AttributeError in "seek" method of "_SharedFile" clas
https://bugs.python.org/issue34035  opened by espdev

#34036: ModuleNotFoundError: No module named '_ctypes' when install Py
https://bugs.python.org/issue34036  opened by semkin

#34037: test_asyncio: test_run_in_executor_cancel() leaked a dangling 
https://bugs.python.org/issue34037  opened by vstinner

#34038: urllib2.urlopen fails if http_proxy(s) is set to a sock5 proxy
https://bugs.python.org/issue34038  opened by T L2

#34041: add *deterministic* parameter to sqlite3.Connection.create_fun
https://bugs.python.org/issue34041  opened by sir-sigurd

#34042: Reference loss for local classes
https://bugs.python.org/issue34042  opened by kayhayen

#34046: subparsers -> add_parser doesn't support hyphen char '-'
https://bugs.python.org/issue34046  opened by [email protected]

#34047: IDLE: on macOS, scroll slider 'sticks' at bottom of file
https://bugs.python.org/issue34047  opened by belgort

#34050: Broken links to "OpenSSL cipher list format" in documentation
https://bugs.python.org/issue34050  opened by rolweber

#34051: Update multiprocessing example
https://bugs.python.org/issue34051  opened by Windson Yang

#34052: sqlite's create_function() raises exception on unhashable call
https://bugs.python.org/issue34052  opened by sir-sigurd

#34055: IDLE: erroneous 'smart' indents in shell
https://bugs.python.org/issue34055  opened by grantjenks

#34056: checked hash-based pyc files not working with imp module
https://bug

Re: [Python-Dev] Failing tests (on a Linux distro)

2018-07-06 Thread Serhiy Storchaka


04.07.18 15:05, Nick Coghlan пише:

So my guess would be that this is a test suite error where we're not
handling the "running in a reproducible build environment with
SOURCE_DATE_EPOCH already set" case.


Should SOURCE_DATE_EPOCH be documented together with 
PYTHONDONTWRITEBYTECODE?


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Failing tests (on a Linux distro)

On Fri, 6 Jul 2018 at 11:02 Serhiy Storchaka  wrote:

> 04.07.18 15:05, Nick Coghlan пише:
> > So my guess would be that this is a test suite error where we're not
> > handling the "running in a reproducible build environment with
> > SOURCE_DATE_EPOCH already set" case.
>
> Should SOURCE_DATE_EPOCH be documented together with
> PYTHONDONTWRITEBYTECODE?
>

Since it's not Python-specific I don't know if it's necessary, but it
wouldn't hurt either since it is an environment variable that affects
Python's behaviour.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

On Fri, 6 Jul 2018 at 08:52 Chris Barker - NOAA Federal via Python-Dev <
[email protected]> wrote:

> Are we just having fun here?
>
> Or might we actually start using a new naming convention for
> the-syntax-formerly-known-as-generator-expressions?
>

If you can create a groundswell of support then maybe.

-Brett


>
> -CHB
>
> Sent from my iPhone
>
> > On Jul 3, 2018, at 11:54 PM, Greg Ewing 
> wrote:
> >
> > Steven D'Aprano wrote:
> >> - list builder syntax is syntax which returns a list;
> >> - dict builder syntax is syntax which returns a dict;
> >> - set builder syntax is syntax which returns a set;
> >> - generator builder syntax is syntax which returns a generator.
> >
> > You only get a list/dict/set from the first three after
> > you've run the iterators within it, but with a generator
> > expression, you already have a generator before you've
> > run it. That makes it feel different to me.
> >
> > --
> > Greg
> > ___
> > Python-Dev mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comparing PEP 576 and PEP 580

2018-07-06 Thread Petr Viktorin


On 07/05/18 13:59, Jeroen Demeyer wrote:

On 2018-07-05 13:32, INADA Naoki wrote:

Core devs interested in this area is limited resource.


I know and unfortunately there is nothing that I can do about that. It 
would be a pity that PEP 580 (or a variant like PEP 576) is not accepted 
simply because no core developer cares enough.


Hi,
I do care about this, and I'm really sorry I've been mostly silent here.
Unfortunately, this is the kind of work that can't be done with a few 
hours in the evenings, and currently an urgent project is sucking up all 
the big blocks of time I have :(

That project should be done in a month or two, however.





As far as I understand, there are some important topics to discuss.

a. Low level calling convention, including argument parsing API.
b. New API for calling objects without argument tuple and dict.
c. How more types can support FASTCALL, LOAD_METHOD and CALL_METHOD.
d. How to reorganize existing builtin types, without breaking stable ABI.


Right, that's why I wanted PEP 580 to be only about (c) and nothing 
else. I made the mistake in PEP 575 of also involving (d).


I still don't understand why we must finish (a) before we can even start 
discussing (c).



Reference implementation helps discussion.


METH_FASTCALL and argument parsing for METH_FASTCALL is already 
implemented in CPython. Not in documented public functions, but the 
implementation exists.


And PEP 580 also has a reference implementation:
https://github.com/jdemeyer/cpython/tree/pep580


Jeroen.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/encukou%40gmail.com

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Examples for PEP 572

On Wed, 4 Jul 2018 at 07:42 Antoine Pitrou  wrote:

> On Wed, 4 Jul 2018 09:43:04 -0300
> Brett Cannon  wrote:
> >
> > I think this is a very key point that the "this is bad" crowd is
> > overlooking. Even if this syntax turns out to not be that useful, abusing
> > the walrus operator can be fixed with a comment of "hard to follow;
> please
> > simplify" without teaching any new concepts or idioms
>
> The same could be said of any language mis-feature.  Do we want to
> claim that questionable semantics in Javascript and PHP are not a
> problem, because the bad constructs can simply be turned away in code
> review?
>
> That sounds like a modern re-phrasing of the old argument, """C is not
> dangerous in itself, it's only the fault of incompetent programmers""".
> Just replace "incompetent programmers" with "complacent reviewers"...
>

I would disagree as for some things understanding why it needs a change is
much easier than others. For instance saying that some use of := is too
convoluted and should be simplified needs much less explanation than other
things like why you should typically avoid staticmethod.

Or another way to view it, saying := is abused  in a review should be
universally understood while something else may require a more
Python-specific explanation and deeper knowledge.

Now none of this isn't to say we should take any idea regardless of
potential abuses and maintenance cost. But for me, I don't view this as
requiring any innate knowledge to cause people not to abuse it.

>
> > Another point is we live in a dictatorship by choice, and yet some people
> > seem very upset our dictator dictated in the end.
>
> Not sure what you mean with "by choice".

As in people choose to join this team knowing that Guido is the BDFL and
what that entails. Since none of us have to be here I view it as a choice
to be here.

-Brett

>   When I arrived here, I
> certainly wasn't asked whether I wanted the place to be a dictatorship
> or not ;-)  Granted, I did choose to come here, but not because of a
> personal appeal for dictatorship.
>
> One could claim that the qualities of Python are due to it being a
> dictatorship.  I think it's impossible to answer that question
> rigorously, and all we're left with is our personal feelings and biases
> on the subject.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removal of install_misc command from distutils

For referencing, the commit was
https://github.com/python/cpython/commit/ef158c3ced3fce39e43f54e8d149dc2714e3456e#diff-ef2e84716aa6196aa0ebf0691e608986
and the issue was https://bugs.python.org/issue29218 .

On Thu, 5 Jul 2018 at 11:27 Alexander Belopolsky <
[email protected]> wrote:

> I started porting my project [1] to Python 3.7 and came across bpo-29218:
>
> "The unused distutils install_misc command has been removed."  [2]
>
> Historically, the distutils package was very conservative about changes
> because many 3rd party packages extended it in ways unforeseen by the
> Python core developers.  As far as I can tell, this removal was done
> without a deprecation period or any public discussion.
>
> The comment above the command class [3] was there for 18 years and
> promised to "keep it around for the time being."  Why did it suddenly
> become necessary to remove it in 3.7?  Is shedding 20 lines of code really
> worth the risk of breaking user code?
>
> [1]: https://github.com/KxSystems/pyq
> [2]: https://docs.python.org/3/whatsnew/3.7.html#api-and-feature-removals
> [3]:
> https://github.com/python/cpython/commit/aae45f93e7b7708deb1ce9d69b58fa029106613d
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 484

On Wed, 4 Jul 2018 at 22:07 Greg Ewing  wrote:

> Shawn Chen wrote:
> > The PEP 484 is proposing a type hint which can annotate the type of each
> > parameters. How ever code written in this format can not be run for
> > python3.5 and below.
>
> You're a bit late. Parameter annotations have been a part
> of the language since at least 3.1. PEP 484 just codifies
> a way of using them to represent types.
>
> Also, PEP 484 does specify a way of using comments to
> indicate types.
>

Actually it does in
https://www.python.org/dev/peps/pep-0484/#suggested-syntax-for-python-2-7-and-straddling-code
and https://www.python.org/dev/peps/pep-0484/#type-comments. So the OP's
desire to specify in a comment is already specified.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] A "day of silence" on PEP 572?


On 06.07.2018 1:40, Guido van Rossum wrote:

Thanks you for writing up a proposal. There have been many proposals 
made, including 'EXPR as NAME', similar to yours. It even has a small 
section in the PEP: 
https://www.python.org/dev/peps/pep-0572/#alternative-spellings. It's 
really hard to choose between alternatives, but all things considered 
I have decided in favor of `NAME := EXPR` instead. Your efforts are 
appreciated but you would just be wasting your time if you wrote a 
PEP. If you're interested in helping out, would you be interested in 
working on the implementation of PEP 572?


Maybe we should call for subj? Not a day most probably, rather however 
much time is needed.


AFAICS, all the arguments have already been told and retold. So we 
should probably give Guido some peace of mind until he officially 
accepts the PEP or whatever he decides.


--
Regards,
Ivan
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tone it down on Twitter?

While I agree with Antoine that the wording by Serhiy on Twitter was
unnecessary, the tone in responses here are also unnecessary. As has been
discussed both here on this mailing list and at the PyCon US language
summit, reacting to actual or perceived rudeness with more rudeness is not
reasonable behaviour. If something upsets you and you want to discuss it
then that's fine, but wait until you can do so with a cool head (I avoided
personal email for 2 days because of this email thread in order to not
react harshly to it myself).

IOW believing you have been disrespected does suddenly give you permission
to be disrespectful as well. That simply leads to everyone not caring about
your complaint and this whole environment ends up feeling hostile.

On Wed, 4 Jul 2018 at 12:15 Ivan Levkivskyi  wrote:

> Just to clarify, the club of three in _my_ twit are the three authors of
> the PEP.
>
> Also, how about you not telling me what to say?
>
> --
> Ivan
>
>
>
> On 4 July 2018 at 16:48, Stefan Krah  wrote:
>
>>
>> Apparently I have made it into "club of three who don't care much about
>> opinions of others" for the crime of a single +0.5 for PEP-572 without
>> participating in the discussion at all (neither did Jason).
>>
>> https://twitter.com/SerhiyStorchaka/status/1014274554452209665
>>
>> This is a new high for Twitter gossip.  Well done.  Perhaps in the next
>> vote
>> the politbureau can indicate the intended outcome beforehand so we know
>> how
>> to vote.
>>
>>
>>
>> Thanks,
>>
>> Stefan Krah
>>
>>
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>>
> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com
>>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A "day of silence" on PEP 572?

2018-07-06 Thread Antoine Pitrou



I would gladly welcome a PEP 572-less development mailing-list.

Regards

Antoine.


On Fri, 6 Jul 2018 22:29:47 +0300
Ivan Pozdeev via Python-Dev  wrote:
> On 06.07.2018 1:40, Guido van Rossum wrote:
> 
> > Thanks you for writing up a proposal. There have been many proposals 
> > made, including 'EXPR as NAME', similar to yours. It even has a small 
> > section in the PEP: 
> > https://www.python.org/dev/peps/pep-0572/#alternative-spellings. It's 
> > really hard to choose between alternatives, but all things considered 
> > I have decided in favor of `NAME := EXPR` instead. Your efforts are 
> > appreciated but you would just be wasting your time if you wrote a 
> > PEP. If you're interested in helping out, would you be interested in 
> > working on the implementation of PEP 572?
> >  
> Maybe we should call for subj? Not a day most probably, rather however 
> much time is needed.
> 
> AFAICS, all the arguments have already been told and retold. So we 
> should probably give Guido some peace of mind until he officially 
> accepts the PEP or whatever he decides.
> 
> --
> Regards,
> Ivan



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tone it down on Twitter?

On Wed, 4 Jul 2018 at 11:54 Mark Lawrence  wrote:

> On 04/07/18 16:48, Stefan Krah wrote:
> >
> > Apparently I have made it into "club of three who don't care much about
> > opinions of others" for the crime of a single +0.5 for PEP-572 without
> > participating in the discussion at all (neither did Jason).
> >
> > https://twitter.com/SerhiyStorchaka/status/1014274554452209665
> >
> > This is a new high for Twitter gossip.  Well done.  Perhaps in the next
> vote
> > the politbureau can indicate the intended outcome beforehand so we know
> how
> > to vote.
> >
> >
> >
> > Thanks,
> >
> > Stefan Krah
> >
> >
> >
>
> Quite frankly I don't give a hoot what gets said on twitter, as it
> appears to be reserved for morons like the current president of the USA.
>

I happen to be on Twitter so you just called me a moron, Mark (as well as
many other core developers).

While I think Stefan's response was uncalled for, he at least felt like the
injured party and thus his response could potentially be attributed an
impassioned response that should not have occurred. IOW while I understand
why the reaction occurred, that doesn't excuse it while warranting a
warning of that fact and that it shouldn't be considered acceptable
behaviour overall.

Your response, though, definitely crossed a line as you were insulting as
well as not directly involved in the issue at hand, which means you had no
direct motivation to be upset other than to prove a point and be rude
entirely on purpose. IOW you were just piling on the rudeness for no good
reason.

For that reason, consider this a warning from me that this kind of
behaviour is simply not acceptable. If it happens again I will request at
least a 2 month ban for you from the mailing list.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tone it down on Twitter?

2018-07-06 Thread Ethan Furman


On 07/06/2018 12:30 PM, Brett Cannon wrote:


IOW believing you have been disrespected does


not


suddenly give you permission to be disrespectful as well.



Thanks, Brett, for the reminder.  I know we all have rough days, and it's easy 
to forget to take a break before responding.

--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

2018-07-06 Thread Glenn Linderman

On 7/6/2018 11:20 AM, Brett Cannon wrote:

On Fri, 6 Jul 2018 at 08:52 Chris Barker - NOAA Federal via Python-Dev 
mailto:[email protected]>> wrote:

Are we just having fun here?

Or might we actually start using a new naming convention for
the-syntax-formerly-known-as-generator-expressions?

If you can create a groundswell of support then maybe.

"Comprehension" was an incomprehensible term to me, when I first heard 
it. After reading the documentation, I comprehended it, but the term is 
meaningless.

"generator expression" is actually a little more comprehensible, by 
analogy to a power (electricity) generator... values are generated. But 
comprehensions would have been more intuitively understood by me, had 
they been called "list generators" or "dict generators" or "set generators".

The difference between comprehensions and generators seems to be one of 
timing and sequencing: the comprehensions are comprehended as fast as 
possible, while generators are lazy (unlike those electricity 
generators, unless you turn them on and off repeatedly). So neither term 
is very intuitive to "plain old programmers" unless perhaps they happen 
to know some of the advanced math concepts where the term 
"comprehension" is claimed to come from (obviously, in spite of a math 
degree from some years back, I never encountered that term).

Focusing just on lists, at this time, "list builder" would be better 
than "list generator" because using "generator" to replace 
"comprehension" would be confusing because of the history of the 
terminology as used/documented currently.

A generator seems to be a "lazy list builder".

If the names are changed, for a time both terminologies would have to 
coexist, so it would be critical to use terms not already in use in 
Python terminology. I would find it an improvement to use terms like 
"list builder" rather than "comprehension".

-Brett

-CHB

Sent from my iPhone

> On Jul 3, 2018, at 11:54 PM, Greg Ewing
mailto:[email protected]>>
wrote:
>
> Steven D'Aprano wrote:
>> - list builder syntax is syntax which returns a list;
>> - dict builder syntax is syntax which returns a dict;
>> - set builder syntax is syntax which returns a set;
>> - generator builder syntax is syntax which returns a generator.
>
> You only get a list/dict/set from the first three after
> you've run the iterators within it, but with a generator
> expression, you already have a generator before you've
> run it. That makes it feel different to me.
>
> --
> Greg

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comparing PEP 576 and PEP 580

2018-07-06 Thread Guido van Rossum

On Fri, Jul 6, 2018 at 2:52 AM Jeroen Demeyer  wrote:

> On 2018-07-05 21:57, Guido van Rossum wrote:
> > Would it be possible to get outside experts to help?
>
> I don't understand what you mean: to help with what? Designing the PEP?
> Discussing the PEP? Accepting the PEP? Lobbying Python core devs?
>

It's your PEP. And you seem to be struggling with something. But I can't
tell quite what it is you're struggling with. So if my suggestion isn't
helpful I won't be offended if you ignore it.

At the same time I assume you want your PEP accepted. And PEP 1 clearly
states that that acceptance is up to me, or up to a BDFL-delegate appointed
by me. In this case I don't feel I understand the details well enough to
decide by myself, so I would either need a BDFL-delegate or a lot of help
from people I trust.

> The Cython developers (in particular Stefan Behnel) certainly support my
> work. I have talked with them in person at a workshop and they posted a
> few emails to python-dev and they also gave me some personal comments
> about PEP 580.
>

And how do they feel about PEP 576? I'd like to see some actual debate of
the pros and cons of the details of PEP 576 vs. PEP 580. So far I mostly
see you and INADA Naoki disagreeing about process, which doesn't give me
the feeling that there is consensus.

As for NumPy, one obvious place where some ideas of PEP 579 could be
> applied is ufuncs. However, typically ufuncs are not *called* in tight
> loops, they implement tight loops internally. So I don't think that
> there is pressing need for anything like PEP 580 in NumPy.
>

OK, so is it your claim that the NumPy developers don't care about which
one of these PEPs is accepted or even whether one is accepted at all? I'd
like to hear some NumPy developer agree with that.

Finally, I'm unclear on what your opinion on FASTCALL actually is. In the
other thread you seemed to praise it as "just perfect" (not a quote, just
what I came away with from reading the thread). Yet earlier in *this*
thread you seemed to claim that PEP 580 requires changes ro FASTCALL. So
which is it?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A "day of silence" on PEP 572?

2018-07-06 Thread Jonathan Goble

On Fri, Jul 6, 2018, 3:41 PM Antoine Pitrou  wrote:

>
> I would gladly welcome a PEP 572-less development mailing-list.
>

+1.

Speaking as a lurker with little interest in the particular topic, PEP 572
has almost driven me to unsubscribe. It's not the massive number of posts
that is annoying, but the fact that seemingly (perhaps literally?) scores
of separate threads have been created for it. A single thread, or a small
number of threads, are easily muted, but when multiple new threads are
created seemingly daily or weekly for months on end, trying to gain control
of my inbox feels like an endless game of Whac-A-Mole [1] with no prizes,
and that's not a good thing.

[1] Being a global list, here's a link for anyone not familiar with the
game: https://en.m.wikipedia.org/wiki/Whac-A-Mole

>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A "day of silence" on PEP 572?

2018-07-06 Thread Victor Stinner

Last week I proposed to create a mailing list dedicated to discuss only the
PEP 572, but nobody reacted to my idea (on python-commiters). Then Guido
van Rossum announced his intent to approve it. So I am not sure if a
mailing list is still needed if the PEP will be approved soon.

Victor

Le vendredi 6 juillet 2018, Antoine Pitrou  a écrit :
>
> I would gladly welcome a PEP 572-less development mailing-list.
>
> Regards
>
> Antoine.
>
>
> On Fri, 6 Jul 2018 22:29:47 +0300
> Ivan Pozdeev via Python-Dev  wrote:
>> On 06.07.2018 1:40, Guido van Rossum wrote:
>>
>> > Thanks you for writing up a proposal. There have been many proposals
>> > made, including 'EXPR as NAME', similar to yours. It even has a small
>> > section in the PEP:
>> > https://www.python.org/dev/peps/pep-0572/#alternative-spellings. It's
>> > really hard to choose between alternatives, but all things considered
>> > I have decided in favor of `NAME := EXPR` instead. Your efforts are
>> > appreciated but you would just be wasting your time if you wrote a
>> > PEP. If you're interested in helping out, would you be interested in
>> > working on the implementation of PEP 572?
>> >
>> Maybe we should call for subj? Not a day most probably, rather however
>> much time is needed.
>>
>> AFAICS, all the arguments have already been told and retold. So we
>> should probably give Guido some peace of mind until he officially
>> accepts the PEP or whatever he decides.
>>
>> --
>> Regards,
>> Ivan
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removal of install_misc command from distutils

2018-07-06 Thread Victor Stinner

Hello,

I am not sure of what you propose. Do you want to get the feature back in
Python 3.7.1? If yes, should it start to emit a deprection warning?

Did you manage to workaround the removal? If yes, maybe we can add more doc
to the Porting section of What's New in Python 3.7?

Victor

Le jeudi 5 juillet 2018, Alexander Belopolsky <
[email protected]> a écrit :
> I started porting my project [1] to Python 3.7 and came across bpo-29218:
>
> "The unused distutils install_misc command has been removed."  [2]
>
> Historically, the distutils package was very conservative about changes
because many 3rd party packages extended it in ways unforeseen by the
Python core developers.  As far as I can tell, this removal was done
without a deprecation period or any public discussion.
>
> The comment above the command class [3] was there for 18 years and
promised to "keep it around for the time being."  Why did it suddenly
become necessary to remove it in 3.7?  Is shedding 20 lines of code really
worth the risk of breaking user code?
>
> [1]: https://github.com/KxSystems/pyq
> [2]: https://docs.python.org/3/whatsnew/3.7.html#api-and-feature-removals
> [3]:
https://github.com/python/cpython/commit/aae45f93e7b7708deb1ce9d69b58fa029106613d
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A "day of silence" on PEP 572?

2018-07-06 Thread Antoine Pitrou


I would simply suggest that people who want to improve or fine-tune the
PEP post pull requests for that (or contact the PEP's authors
privately).

As for the other kinds of threads, as much as I dislike PEP 572, they
are useless now.

Regards

Antoine.


On Fri, 6 Jul 2018 23:50:46 +0200
Victor Stinner  wrote:
> Last week I proposed to create a mailing list dedicated to discuss only the
> PEP 572, but nobody reacted to my idea (on python-commiters). Then Guido
> van Rossum announced his intent to approve it. So I am not sure if a
> mailing list is still needed if the PEP will be approved soon.
> 
> Victor
> 
> Le vendredi 6 juillet 2018, Antoine Pitrou  a écrit :
> >
> > I would gladly welcome a PEP 572-less development mailing-list.
> >
> > Regards
> >
> > Antoine.
> >
> >
> > On Fri, 6 Jul 2018 22:29:47 +0300
> > Ivan Pozdeev via Python-Dev  wrote:  
> >> On 06.07.2018 1:40, Guido van Rossum wrote:
> >>  
> >> > Thanks you for writing up a proposal. There have been many proposals
> >> > made, including 'EXPR as NAME', similar to yours. It even has a small
> >> > section in the PEP:
> >> > https://www.python.org/dev/peps/pep-0572/#alternative-spellings. It's
> >> > really hard to choose between alternatives, but all things considered
> >> > I have decided in favor of `NAME := EXPR` instead. Your efforts are
> >> > appreciated but you would just be wasting your time if you wrote a
> >> > PEP. If you're interested in helping out, would you be interested in
> >> > working on the implementation of PEP 572?
> >> >  
> >> Maybe we should call for subj? Not a day most probably, rather however
> >> much time is needed.
> >>
> >> AFAICS, all the arguments have already been told and retold. So we
> >> should probably give Guido some peace of mind until he officially
> >> accepts the PEP or whatever he decides.
> >>
> >> --
> >> Regards,
> >> Ivan  
> >
> >
> >
> > ___
> > Python-Dev mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:  
> https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
> >  
> 

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] On the METH_FASTCALL calling convention

2018-07-06 Thread Victor Stinner

Hi,

I designed FASTCALL with the help of Serhiy for keywords. I prepared a long
email reply, but I found an opportunity for optimisation on **kwargs and I
need time to see how to optimize it.

Maybe there is a need for passing **kwargs as a dict at C level, but use
FASTCALL for positional arguments? I only know dict.update() which would
benefit of that. All other functions are fine with FASTCALL for keywords.

Victor

Le vendredi 6 juillet 2018, Guido van Rossum  a écrit :
> I'm not the world's leading expert on Python bytecode anymore, but unless
there's something I'm missing your conclusion looks eminently reasonable,
and so I expect you'll get very little traction on this thread. (If you had
wanted to get a megathread you should have written "FASTCALL considered
harmful". :-)
>
> I think there was one person in another thread (INADA Naoki?) who thought
METH_FASTCALL could use improvements. Maybe that person can write back to
this thread? Or perhaps Victor Stinner (who seems to have touched it last)
has a suggestion for what could be improved about it?
> --Guido
>
> On Thu, Jul 5, 2018 at 7:55 AM Jeroen Demeyer  wrote:
>>
>> Hello all,
>>
>> As discussed in some other threads ([1], [2]), we should discuss the
>> METH_FASTCALL calling convention.
>>
>> For passing only positional arguments, a C array of Python objects is
>> used, which is as fast as it can get. When the Python interpreter calls
>> a function, it builds that C array on the interpreter stack:
>>
>>  >>> from dis import dis
>>  >>> def f(x, y): return g(x, y, 12)
>>  >>> dis(f)
>>1   0 LOAD_GLOBAL  0 (g)
>>2 LOAD_FAST0 (x)
>>4 LOAD_FAST1 (y)
>>6 LOAD_CONST   1 (12)
>>8 CALL_FUNCTION3
>>   10 RETURN_VALUE
>>
>> A C array can also easily and efficiently be handled by the C function
>> receiving it. So I consider this uncontroversial.
>>
>> The convention for METH_FASTCALL|METH_KEYWORDS is that keyword *names*
>> are passed as a tuple and keyword *values* in the same C array with
>> positional arguments. An example:
>>
>>  >>> from dis import dis
>>  >>> def f(x, y, z): return f(x, foo=y, bar=z)
>>  >>> dis(f)
>>1   0 LOAD_GLOBAL  0 (f)
>>2 LOAD_FAST0 (x)
>>4 LOAD_FAST1 (y)
>>6 LOAD_FAST2 (z)
>>8 LOAD_CONST   1 (('foo', 'bar'))
>>   10 CALL_FUNCTION_KW 3
>>   12 RETURN_VALUE
>>
>> This is pretty clever: it exploits the fact that ('foo', 'bar') is a
>> constant tuple stored in f.__code__.co_consts. Also, a tuple can be
>> efficiently handled by the called code: it is essentially a thin wrapper
>> around a C array of Python objects. So this works well.
>>
>> The only case when this handling of keywords is suboptimal is when using
>> **kwargs. In that case, a dict must be converted to a tuple. It looks
>> hard to me to support efficiently both the case of fixed keyword
>> arguments (f(foo=x)) and a keyword dict (f(**kwargs)). Since the former
>> is more common than the latter, the current choice is optimal.
>>
>> In other words: I see nothing to improve in the calling convention of
>> METH_FASTCALL. I suggest to keep it and make it public as-is.
>>
>>
>> Jeroen.
>>
>>
>> [1] https://mail.python.org/pipermail/python-dev/2018-June/153945.html
>> [2] https://mail.python.org/pipermail/python-dev/2018-July/154251.html
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
> --
> --Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comparing PEP 576 and PEP 580


On 2018-07-06 23:12, Guido van Rossum wrote:

It's your PEP. And you seem to be struggling with something. But I can't
tell quite what it is you're struggling with.


To be perfectly honest (no hard feelings though!): what I'm struggling 
with is getting feedback (either positive or negative) from core devs 
about the actual PEP 580.



At the same time I assume you want your PEP accepted.


As I also said during the PEP 575 discussion, my real goal is to solve a 
concrete problem, not to push my personal PEP. I still think that PEP 
580 is the best solution but I welcome other suggestions.



And how do they feel about PEP 576? I'd like to see some actual debate
of the pros and cons of the details of PEP 576 vs. PEP 580.


I started this thread to do precisely that.

My opinion: PEP 580 has zero performance cost, while PEP 576 does make 
performance for bound methods worse (there is no reference 
implementation of the new PEP 576 yet, so that's hard to quantify for 
now). PEP 580 is also more future-proof: it defines a new protocol which 
can easily be extended in the future. PEP 576 just builds on PyMethodDef 
which cannot be extended because of ABI compatibility (putting 
__text_signature__ and __doc__ in the same C string is a good symptom of 
that). This extensibility is important because I want PEP 580 to be the 
first in a series of PEPs working out this new protocol. See PEP 579 for 
the bigger picture.


One thing that might count against PEP 580 is that it defines a whole 
new protocol, which could be seen as too complicated. However, it must 
be this complicated because it is meant to generalize the current 
behavior and optimizations of built-in functions and methods. There are 
lots of little tricks currently in CPython that must be "ported" to the 
new protocol.



OK, so is it your claim that the NumPy developers don't care about which
one of these PEPs is accepted or even whether one is accepted at all?


I don't know, I haven't contacted any NumPy devs yet, so that was just 
my personal feeling. These PEPs are about optimizing callables and NumPy 
isn't really about callables. I think that the audience for PEP 580 is 
mostly compilers (Cython for sure but possibly also Pythran, numba, 
cppyy, ...). Also certain C classes like functools.lru_cache could 
benefit from it.



Yet earlier in
*this* thread you seemed to claim that PEP 580 requires changes ro
FASTCALL.


I don't know what you mean with that. But maybe it's also confusing 
because "FASTCALL" can mean different things: it can refer to a 
PyMethodDef (used by builtin_function_or_method and method_descriptor) 
with the METH_FASTCALL flag set. It can also refer to a more general API 
like _PyCFunction_FastCallKeywords, which supports METH_FASTCALL but 
also other calling conventions like METH_VARARGS.


I don't think that METH_FASTCALL should be changed (and PEP 580 isn't 
really about that at all). For the latter, I'm suggesting some API 
changes but nothing fundamental: mainly replacing the 5 existing private 
functions _PyCFunction_FastCallKeywords, _PyCFunction_FastCallDict, 
_PyMethodDescr_FastCallKeywords, _PyMethodDef_RawFastCallKeywords, 
_PyMethodDef_RawFastCallDict by 1 public function PyCCall_FASTCALL.



Hopefully this clears some things up,
Jeroen.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Comparing PEP 576 and PEP 580

2018-07-06 Thread Guido van Rossum

Thanks, I will wait until there is a conclusion to the debate.

On Fri, Jul 6, 2018 at 4:05 PM Jeroen Demeyer  wrote:

> On 2018-07-06 23:12, Guido van Rossum wrote:
> > It's your PEP. And you seem to be struggling with something. But I can't
> > tell quite what it is you're struggling with.
>
> To be perfectly honest (no hard feelings though!): what I'm struggling
> with is getting feedback (either positive or negative) from core devs
> about the actual PEP 580.
>
> > At the same time I assume you want your PEP accepted.
>
> As I also said during the PEP 575 discussion, my real goal is to solve a
> concrete problem, not to push my personal PEP. I still think that PEP
> 580 is the best solution but I welcome other suggestions.
>
> > And how do they feel about PEP 576? I'd like to see some actual debate
> > of the pros and cons of the details of PEP 576 vs. PEP 580.
>
> I started this thread to do precisely that.
>
> My opinion: PEP 580 has zero performance cost, while PEP 576 does make
> performance for bound methods worse (there is no reference
> implementation of the new PEP 576 yet, so that's hard to quantify for
> now). PEP 580 is also more future-proof: it defines a new protocol which
> can easily be extended in the future. PEP 576 just builds on PyMethodDef
> which cannot be extended because of ABI compatibility (putting
> __text_signature__ and __doc__ in the same C string is a good symptom of
> that). This extensibility is important because I want PEP 580 to be the
> first in a series of PEPs working out this new protocol. See PEP 579 for
> the bigger picture.
>
> One thing that might count against PEP 580 is that it defines a whole
> new protocol, which could be seen as too complicated. However, it must
> be this complicated because it is meant to generalize the current
> behavior and optimizations of built-in functions and methods. There are
> lots of little tricks currently in CPython that must be "ported" to the
> new protocol.
>
> > OK, so is it your claim that the NumPy developers don't care about which
> > one of these PEPs is accepted or even whether one is accepted at all?
>
> I don't know, I haven't contacted any NumPy devs yet, so that was just
> my personal feeling. These PEPs are about optimizing callables and NumPy
> isn't really about callables. I think that the audience for PEP 580 is
> mostly compilers (Cython for sure but possibly also Pythran, numba,
> cppyy, ...). Also certain C classes like functools.lru_cache could
> benefit from it.
>
> > Yet earlier in
> > *this* thread you seemed to claim that PEP 580 requires changes ro
> > FASTCALL.
>
> I don't know what you mean with that. But maybe it's also confusing
> because "FASTCALL" can mean different things: it can refer to a
> PyMethodDef (used by builtin_function_or_method and method_descriptor)
> with the METH_FASTCALL flag set. It can also refer to a more general API
> like _PyCFunction_FastCallKeywords, which supports METH_FASTCALL but
> also other calling conventions like METH_VARARGS.
>
> I don't think that METH_FASTCALL should be changed (and PEP 580 isn't
> really about that at all). For the latter, I'm suggesting some API
> changes but nothing fundamental: mainly replacing the 5 existing private
> functions _PyCFunction_FastCallKeywords, _PyCFunction_FastCallDict,
> _PyMethodDescr_FastCallKeywords, _PyMethodDef_RawFastCallKeywords,
> _PyMethodDef_RawFastCallDict by 1 public function PyCCall_FASTCALL.
>
>
> Hopefully this clears some things up,
> Jeroen.
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

2018-07-06 Thread Terry Reedy


On 7/6/2018 11:51 AM, Chris Barker - NOAA Federal via Python-Dev wrote:
via phone...

Are we just having fun here?


I floated the idea as a trial balloon to see what response it got.


Or might we actually start using a new naming convention for
the-syntax-formerly-known-as-generator-expressions?


Since Guido, the first respondent, did not immediately shoot the idea 
down, I intend to flesh it out and make it more concrete.



On Jul 3, 2018, at 11:54 PM, Greg Ewing  wrote:

Steven D'Aprano wrote:

- list builder syntax is syntax which returns a list;
- dict builder syntax is syntax which returns a dict;
- set builder syntax is syntax which returns a set;
- generator builder syntax is syntax which returns a generator.


To expand on this: an iterable represents a collection of information 
objects.  Some iterables are concrete collections.  Others are more 
abstract, generating objects on demand in an order that may or may not 
be significant.


Set builders in math define a set in terms of 1 set, 0 to 1 filters, and 
1 transform: defined-set = map(tranform, filter(predicate, known-set)). 
(One could say that there is always a filter, which defaults to passing 
everything.)


Python builders generalize the type 'set' to 'iterable' and the first 
and second numbers 1 to n and specify a particular nested order of 
iteration and filtration.  For n left as 1, the type generalization is


new_iterable = output_type(map(transform,
   filter(predicate, iter(iterable)).

I omitted above the potential dependence of iterable, predicate, and 
transform pre-existing arguments.  For generator builders, define output 
type 'generator' as a identity function when the input is a generator.


The generalization to n > 1 is tricky to specify with functions call, as 
I did above, because the filtered iterations are nested rather than 
crossed.  Consequently, each iterable and filter (as well as the 
tranform) could depend not only on values existing before the top call 
but also the current values of surrounding iterations.



You only get a list/dict/set from the first three after
you've run the iterators within it, but with a generator
expression, you already have a generator before you've
run it. That makes it feel different to me.


What all 4 results have in common is that they are (mutable) iterables 
produced from iterators and other inputs with builder syntax.


Aside from that, it is true that there are differences between concrete 
iterables like set, list, and dict versus generator iterators.  But to 
me, this is secondary in this context.  One could note that lists and 
dicts can be subscripted, sets and generators cannot.  Or note that dict 
builders are 'different' because they use the funny dict item ':' 
notation instead of the (key,value) notation that would make 
{dict-builder} = dict(dict-builder) true without needing an asterisk. 
(But then something else would be needed to mark {(k,v) for k,v in it} 
as a dict rather than set.  The use of ':' is quite clever.)





--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A "day of silence" on PEP 572?

2018-07-06 Thread Ryan Gonzalez


On July 6, 2018 5:04:05 PM Antoine Pitrou  wrote:



(or contact the PEP's authors
privately).



Hoenstly, this feels like a recipe for a disaster...



As for the other kinds of threads, as much as I dislike PEP 572, they
are useless now.

Regards

Antoine.


On Fri, 6 Jul 2018 23:50:46 +0200
Victor Stinner  wrote:

Last week I proposed to create a mailing list dedicated to discuss only the
PEP 572, but nobody reacted to my idea (on python-commiters). Then Guido
van Rossum announced his intent to approve it. So I am not sure if a
mailing list is still needed if the PEP will be approved soon.

Victor

Le vendredi 6 juillet 2018, Antoine Pitrou  a écrit :
>
> I would gladly welcome a PEP 572-less development mailing-list.
>
> Regards
>
> Antoine.
>
>
> On Fri, 6 Jul 2018 22:29:47 +0300
> Ivan Pozdeev via Python-Dev  wrote:
>> On 06.07.2018 1:40, Guido van Rossum wrote:
>>
>> > Thanks you for writing up a proposal. There have been many proposals
>> > made, including 'EXPR as NAME', similar to yours. It even has a small
>> > section in the PEP:
>> > https://www.python.org/dev/peps/pep-0572/#alternative-spellings. It's
>> > really hard to choose between alternatives, but all things considered
>> > I have decided in favor of `NAME := EXPR` instead. Your efforts are
>> > appreciated but you would just be wasting your time if you wrote a
>> > PEP. If you're interested in helping out, would you be interested in
>> > working on the implementation of PEP 572?
>> >
>> Maybe we should call for subj? Not a day most probably, rather however
>> much time is needed.
>>
>> AFAICS, all the arguments have already been told and retold. So we
>> should probably give Guido some peace of mind until he officially
>> accepts the PEP or whatever he decides.
>>
>> --
>> Regards,
>> Ivan
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
>



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com




___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] A "day of silence" on PEP 572?

2018-07-06 Thread Steve Holden

On Sat, Jul 7, 2018 at 12:18 AM, Ryan Gonzalez  wrote:

> On July 6, 2018 5:04:05 PM Antoine Pitrou  wrote:
>
>
>> (or contact the PEP's authors
>> privately).
>>
>>
> Hoenstly, this feels like a recipe for a disaster...
>
> Many of the people who have strong opinions in this know the PEP authors
from years of working together.

They might feel that personal channels are appropriate. I'd agree it
would be a bit presumptuous and spammy of others to use them.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

2018-07-06 Thread Guido van Rossum

On Fri, Jul 6, 2018 at 4:19 PM Terry Reedy  wrote:

> Since Guido, the first respondent, did not immediately shoot the idea
> down, I intend to flesh it out and make it more concrete.
>

Maybe I should have shot it down. The term is entrenched in multiple
languages by now (e.g. https://en.wikipedia.org/wiki/List_comprehension).
Regarding "list builder" one could argue that it would just add more
confusion, since there's already an unrelated Builder Pattern (
https://en.wikipedia.org/wiki/Builder_pattern) commonly used in Java.
(Though I worry about the presence of a Python example in that Wikipedia
page. :-)

Also, "generator builder" is not much more expressive than "generator
expression", and the key observation that led to this idea was that it's
such a mouthful to say "comprehensions and generator expressions". Maybe
it's not too late to start calling the latter "generator comprehensions" so
that maybe by the year 2025 we can say "comprehensions" and everyone will
understand we mean all four types?

FWIW more people should start using "list display" etc. for things like [a,
b, c].

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removal of install_misc command from distutils

2018-07-06 Thread Alexander Belopolsky

Honestly, I did not realize that 3.7 has been released by the time I wrote
my e-mail.  I think it will be prudent to get this command back in Python
3.7.1.  My work-around was to simply copy the 20-something lines that
define install_misc from Python 3.6 to my setup.py file.

It was my impression that it is precisely due to situations like this,
distutils was considered more or less frozen for development and all new
features went to setuptools.

On Fri, Jul 6, 2018 at 5:57 PM Victor Stinner  wrote:
>
> Hello,
>
> I am not sure of what you propose. Do you want to get the feature back in
Python 3.7.1? If yes, should it start to emit a deprection warning?
>
> Did you manage to workaround the removal? If yes, maybe we can add more
doc to the Porting section of What's New in Python 3.7?
>
> Victor
>
> Le jeudi 5 juillet 2018, Alexander Belopolsky <
[email protected]> a écrit :
> > I started porting my project [1] to Python 3.7 and came across
bpo-29218:
> >
> > "The unused distutils install_misc command has been removed."  [2]
> >
> > Historically, the distutils package was very conservative about changes
because many 3rd party packages extended it in ways unforeseen by the
Python core developers.  As far as I can tell, this removal was done
without a deprecation period or any public discussion.
> >
> > The comment above the command class [3] was there for 18 years and
promised to "keep it around for the time being."  Why did it suddenly
become necessary to remove it in 3.7?  Is shedding 20 lines of code really
worth the risk of breaking user code?
> >
> > [1]: https://github.com/KxSystems/pyq
> > [2]:
https://docs.python.org/3/whatsnew/3.7.html#api-and-feature-removals
> > [3]:
https://github.com/python/cpython/commit/aae45f93e7b7708deb1ce9d69b58fa029106613d
> >
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]


On 07.07.2018 2:31, Guido van Rossum wrote:
On Fri, Jul 6, 2018 at 4:19 PM Terry Reedy > wrote:


Since Guido, the first respondent, did not immediately shoot the idea
down, I intend to flesh it out and make it more concrete.


Maybe I should have shot it down. The term is entrenched in multiple 
languages by now (e.g. 
https://en.wikipedia.org/wiki/List_comprehension). Regarding "list 
builder" one could argue that it would just add more confusion, since 
there's already an unrelated Builder Pattern 
(https://en.wikipedia.org/wiki/Builder_pattern) commonly used in Java. 
(Though I worry about the presence of a Python example in that 
Wikipedia page. :-)


According to https://en.wikipedia.org/wiki/List_comprehension#History, 
the term's known from at least 1977 and comes from such influential 
languages as NPL, Miranda and Haskell. So it's not you to blame for it :-)




Also, "generator builder" is not much more expressive than "generator 
expression",


"generator builder" is simply incorrect. The GE doesn't "build" 
generators, it's a generator itself. It's a generator _and_ an 
expression. What could be a more obvious name?
This suggestion looks like coming from someone who hasn't quite grasped 
generators yet.


and the key observation that led to this idea was that it's such a 
mouthful to say "comprehensions and generator expressions".


Since "X comprehensions" are advertised as and intended to be 
functionally equivalent to `X(generator expression)', I use just 
"generator expressions" to refer to all.
That's accurate because the common part with the distinctive syntax -- 
which is the thing referred to when addressing them all -- effectively 
_is_ a generator expression (the syntax differences in the leading term 
are insignificant), what wraps it is of no concern.


So, no new terms are necessary, but someone who cares may add a note to 
the docs to this effect.


Maybe it's not too late to start calling the latter "generator 
comprehensions" so that maybe by the year 2025 we can say 
"comprehensions" and everyone will understand we mean all four types?


FWIW more people should start using "list display" etc. for things 
like [a, b, c].

--
--Guido van Rossum (python.org/~guido )


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] On the METH_FASTCALL calling convention

2018-07-06 Thread INADA Naoki

On Sat, Jul 7, 2018 at 7:29 AM Victor Stinner  wrote:
>
> Hi,
>
> I designed FASTCALL with the help of Serhiy for keywords. I prepared a long 
> email reply, but I found an opportunity for optimisation on **kwargs and I 
> need time to see how to optimize it.
>
> Maybe there is a need for passing **kwargs as a dict at C level, but use 
> FASTCALL for positional arguments? I only know dict.update() which would 
> benefit of that. All other functions are fine with FASTCALL for keywords.
>
> Victor
>

I agree with Jeroen.  If only few methods can be improved, it's not
necessary.  METH_VARARGS | METH_KEYWORDS is fine.

-- 
INADA Naoki  
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

On 07.07.2018 2:58, Ivan Pozdeev via Python-Dev wrote:

On 07.07.2018 2:31, Guido van Rossum wrote:
On Fri, Jul 6, 2018 at 4:19 PM Terry Reedy > wrote:

Since Guido, the first respondent, did not immediately shoot the
idea
down, I intend to flesh it out and make it more concrete.

Maybe I should have shot it down. The term is entrenched in multiple
languages by now (e.g.
https://en.wikipedia.org/wiki/List_comprehension). Regarding "list
builder" one could argue that it would just add more confusion, since
there's already an unrelated Builder Pattern
(https://en.wikipedia.org/wiki/Builder_pattern) commonly used in
Java. (Though I worry about the presence of a Python example in that
Wikipedia page. :-)

According to https://en.wikipedia.org/wiki/List_comprehension#History,
the term's known from at least 1977 and comes from such influential
languages as NPL, Miranda and Haskell. So it's not you to blame for it :-)

Also, "generator builder" is not much more expressive than "generator
expression",

"generator builder" is simply incorrect. The GE doesn't "build"
generators, it's a generator itself. It's a generator _and_ an
expression. What could be a more obvious name?
This suggestion looks like coming from someone who hasn't quite
grasped generators yet.

and the key observation that led to this idea was that it's such a
mouthful to say "comprehensions and generator expressions".

Since "X comprehensions" are advertised as and intended to be
functionally equivalent to `X(generator expression)', I use just
"generator expressions" to refer to all.
That's accurate because the common part with the distinctive syntax --
which is the thing referred to when addressing them all -- effectively
_is_ a generator expression (the syntax differences in the leading
term are insignificant), what wraps it is of no concern.

So, no new terms are necessary, but someone who cares may add a note
to the docs to this effect.

Maybe it's not too late to start calling the latter "generator
comprehensions" so that maybe by the year 2025 we can say
"comprehensions" and everyone will understand we mean all four types?

https://docs.python.org/3/reference/expressions.html?highlight=comprehension#displays-for-lists-sets-and-dictionaries

Oh, I see. So, "comprehension" is actually the official term for this
"distinctive syntax", and the fact that "generator expressions" came to
use it is but a coincidence.

In that case, we can do a Solomon's decision: mention _both_ that
"comprehension" is the official term for the syntax in GE's reference
entry, _and_ the fact that "X comprehensions" are effectively wrapped
GEs in their reference entries.

Then everyone will learn both terminologies and could choose which is
more convenient to use.

FWIW more people should start using "list display" etc. for things
like [a, b, c].

--
--Guido van Rossum (python.org/~guido )

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removal of install_misc command from distutils

2018-07-06 Thread Ned Deily

On Jul 6, 2018, at 19:43, Alexander Belopolsky  
wrote:
> Honestly, I did not realize that 3.7 has been released by the time I wrote my 
> e-mail.

So I guess I didn't send out enough notices since January about each of the 5 
betas and the release candidate begging everyone to test with the 3.7 
pre-releases to find and discuss potentially avoidable incompatibilities? :)

> I think it will be prudent to get this command back in Python 3.7.1.  My 
> work-around was to simply copy the 20-something lines that define 
> install_misc from Python 3.6 to my setup.py file.
> 
> It was my impression that it is precisely due to situations like this, 
> distutils was considered more or less frozen for development and all new 
> features went to setuptools. 

If you want to pursue it, I think the best thing to do would be to bring up the 
issue on the distutils-sig mailing list where the change probably should have 
been discussed first if it wasn't and also reopen 
https://bugs.python.org/issue29218.  AFAIK, the removal hasn't come up as a 
problem before in the nearly 18 months since the change was first merged into 
the feature branch.

--
  Ned Deily
  [email protected] -- []

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Symmetric vs asymmetric symbols (was PEP 572: Do we really need a ":" in ":="?)

2018-07-06 Thread Greg Ewing

Ivan Pozdeev via Python-Dev wrote:
(while "<>" reads "less or greater" which is mathematically not 
equivalent to that: not everything has a defined ordering relation.

I think this is a silly argument against "<>". If we're going to try
to assign meaning to individual characters in an operator, we could
equally well say that "!" on its own should mean "not", which it
doesn't in Python. Whereas "~" does, kind of, so "not equal" should
be spelled "~=".

> "<>"
> draws from BASIC AFAIK which was geared towards regular users who don't
> deal with advanced mathematics.)

Criticising something because it comes from BASIC smacks of snobbery.
Anyway, it's also used by a number of entirely respectable languages
such as Pascal and SQL.

And what proportion of Python users deal with advanced mathematics?

--
Greg
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Symmetric vs asymmetric symbols (was PEP 572: Do we really need a ":" in ":="?)

2018-07-06 Thread Steven D'Aprano

On Sat, Jul 07, 2018 at 01:03:06PM +1200, Greg Ewing wrote:
> Ivan Pozdeev via Python-Dev wrote:
> >(while "<>" reads "less or greater" which is mathematically not 
> >equivalent to that: not everything has a defined ordering relation.
> 
> I think this is a silly argument against "<>".

While I agree with your conclusions, I'd just like to point out that 
given the existence of float NANs, there's a case to be made for having 
separate <> and != operators with != keeping the "not equal" meaning and 
the <> operator meaning literally "less than, or greater than".

py> NAN != 23
True
py> NAN < 23 or NAN > 23
False

(I'm not making the case for this, just pointing out that it exists...)

There would be precedent too: at least one of Apple's SANE maths 
libraries back in the 1990s had a full set of NAN-aware comparison 
operators including IIRC separate "not equal" and "less than or greater 
than" comparisons.

But I think this is a corner of IEEE-754 esoterica that probably doesn't 
need to be a builtin operator :-)

Also:

py> from __future__ import barry_as_FLUFL
py> 23 <> 42
True

-- 
Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

2018-07-06 Thread Steven D'Aprano

On Sat, Jul 07, 2018 at 02:58:23AM +0300, Ivan Pozdeev via Python-Dev wrote:

> >Also, "generator builder" is not much more expressive than "generator 
> >expression",

I agree with Guido on that comment. The only advantage (such little as 
it is) is that we can refer to them all using the same terminology:

[list | set | dict | generator] builder syntax

but given how prevalent the comprehension terminology has become, maybe 
the best we can hope for is to start using "generator comprehension".

> "generator builder" is simply incorrect. The GE doesn't "build" 
> generators, it's a generator itself.

Nobody suggested that it was an thing that you call to build a 
generator. The name refers to the syntax, not the object. I did refer to 
it as *generator builder syntax* in my earlier post, and explicitly 
noted that "list/set/dict/generator builder" was the abbreviated form.

But as Guido says, the possible confusion with the Builder design 
pattern makes this terminology confusing. If we were back in Python 2.2 
days when neither the feature nor the terminology "comprehension" were 
so well established, perhaps we could have gone with "builder" instead, 
but I think that ship has sailed.

> It's a generator _and_ an 
> expression. What could be a more obvious name?

It's not about the obviousness, it is about it being a mouthful to say 
"comprehension or generator expression" to represent something which is 
conceptually a single kind of thing.

We can use "comprehension" to group "list comprehension or dict 
comprehension or dict comprehension", but generator expressions are the 
odd one out.

> This suggestion looks like coming from someone who hasn't quite grasped 
> generators yet.

I assure you that both Greg and I understand generators quite well.

-- 
Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Symmetric vs asymmetric symbols (was PEP 572: Do we really need a ":" in ":="?)

2018-07-06 Thread Tim Peters

[Steven D'Aprano]

>  I'd just like to point out that
> given the existence of float NANs, there's a case to be made for having
> separate <> and != operators with != keeping the "not equal" meaning and
> the <> operator meaning literally "less than, or greater than".
>
> py> NAN != 23
> True
> py> NAN < 23 or NAN > 23
> False
>
> (I'm not making the case for this, just pointing out that it exists...)
>
> There would be precedent too: at least one of Apple's SANE maths
> libraries back in the 1990s had a full set of NAN-aware comparison
> operators including IIRC separate "not equal" and "less than or greater
> than" comparisons.
>
> But I think this is a corner of IEEE-754 esoterica that probably doesn't
> need to be a builtin operator :-)
>
> The 754 standard's section 5.7 (Comparisons) defines 26(!) distinct
comparison predicates.  I bet SANE supplied all of them - and quite
possibly nothing else in the world ever bothered (the standard _required_
only a relative few of them).

I never had the slightest interest in garbaging-up Python with syntax for
all those, so never even mentioned it in the early days.

My secret plan ;-) was that if someone agitated for it enough to sway
Guido, I'd add a

math.ieee_compare(x, y, raise=False)

function that returned one of the four bit constants IEEE_(LESS, EQUAL,
GREATER, UNORDERED} (with values 1, 2, 4, 8), and raised some spelling of
"invalid operation" iff `raise` was True and at least one of the comparands
was a NaN.  That's enough to build any of the standard's predicates (and a
few more essentially useless ones, like "always true").

Then, e.g., for your <> above

def "<>"(x, y):
return ieee_compare(x, y) & (IEEE_LESS | IEEE_GREATER) != 0

and != above would add IEEE_UNORDERED to the bits checked in that.

Then it's equal easy to build oddballs like "unordered or greater" and
"only equal but raise an exception if a NaN is compared" too.

I've been quite relieved that, after all these years, nobody else seemed to
care about this either :-)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]