[Python-Dev] For-If syntax

[Emily Bowman]

I hope this isn't too noobish, nothing on the list comes up in Google, but
I'm curious why the construct

for x in y if x.is_some_thing:
  # do a thing

isn't legal. That seems a very Pythonic symmetry with lambdas. The
equivalent syntax required right now is,

for x in [x for x in y if x.is_some_thing]:
  # do a thing

Of course there's more flexibility in the full syntax, but is there any
interest in the simpler, more performant one-line syntax?

Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VHFUQFEF3TCI6LHLBAUEKMFM2A6V3CQO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: For-If syntax

[Emily Bowman]

Thanks, this is what I was looking for and couldn't find. I'm glad it is
something that's been considered and debated before. I'm not sure why I
couldn't find it or anything like it, but I guess the syntax is just a
needle in a haystack.

Em

On Sat, May 2, 2020 at 7:42 AM Henk-Jaap Wagenaar <
wagenaarhenkj...@gmail.com> wrote:

> We seem to be, once again, rehashing about this.  For example, I proposed
> this in 2017, which was not the first time:
>
>
> https://mail.python.org/archives/list/python-id...@python.org/thread/GFZFJAI4WGFYFFVQTF7DORHMY7F45XZZ/
>
> (Gary's suggestion, and (counter) counter points to it are in the linked
> discussion)
>
> Would it maybe be time for someone to write a PEP for this (if they can be
> found), so it can then be rejected (or not)?
>
> I think there is no bikeshedding to be done on the idea, though in terms
> of parsing there might be (though as I mentioned in that thread, there
> should be no difference to generator expression parsing).
>
> On Fri, 1 May 2020 at 19:52, Gary Herron  wrote:
>
>>
>> On 5/1/20 9:19 AM, silverback...@gmail.com wrote:
>>
>> I hope this isn't too noobish, nothing on the list comes up in Google,
>> but I'm curious why the construct
>>
>> for x in y if x.is_some_thing:
>>   # do a thing
>>
>> But this is probably clearer (and has the same syntax):
>>
>> for x in y:
>>   if x.is_some_thing:
>> # do a thing
>>
>>
>> Cramming two separate thoughts onto a single line is probably *not*
>> clearer.
>>
>>
>>
>> isn't legal. That seems a very Pythonic symmetry with lambdas. The
>> equivalent syntax required right now is,
>>
>> for x in [x for x in y if x.is_some_thing]:
>>   # do a thing
>>
>> Of course there's more flexibility in the full syntax, but is there any
>> interest in the simpler, more performant one-line syntax?
>>
>> Em
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to 
>> python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/python-dev@python.org/message/VHFUQFEF3TCI6LHLBAUEKMFM2A6V3CQO/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>> --
>> Dr. Gary Herron
>> Professor of Computer Science
>> DigiPen Institute of Technology
>> (425) 895-4418
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/T3VQGGAHYR4AOKMVPL5NDTAV2GB6BIAH/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/SBEKOAFBUNVFXR5UXCSFF6HPEE4GEE6O/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7E4CK5GBA2F4WLVECHOCJFY54L5WRCLI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PoC: Subinterpreters 4x faster than sequential execution or threads on CPU-bound workaround

[Emily Bowman]

 Main memory bus or cache contention? Integer execution ports full?
Throttling? VTune is useful to find out where the bottleneck is, things
like that tend to happen when you start loading every logical core.

On Tue, May 5, 2020 at 4:45 PM Joseph Jenne via Python-Dev <
python-dev@python.org> wrote:

> I'm seeing a drop in performance of both multiprocess and subinterpreter
> based runs in the 8-CPU case, where performance drops by about half
> despite having enough logical CPUs, while the other cases scale quite
> well. Is there some issue with python multiprocessing/subinterpreters on
> the same logical core?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CDF6K2ALJV6MWCKF54JCXDWSR4HNBMKR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PoC: Subinterpreters 4x faster than sequential execution or threads on CPU-bound workaround

[Emily Bowman]

On Wed, May 6, 2020 at 12:36 PM Nathaniel Smith  wrote:

>
> Sure, zero cost is always better than some cost, I'm not denying that
> :-). What I'm trying to understand is whether the difference is
> meaningful enough to justify subinterpreters' increased complexity,
> fragility, and ecosystem breakage.
>
> If your data is in large raw memory buffers to start with (like numpy
> arrays or arrow dataframes), then yeah, serialization costs are
> smaller proportion of IPC costs. And out-of-band buffers are an
> elegant way of letting pickle users take advantage of that speedup
> while still using the familiar pickle API. Thanks for writing that PEP
> :-).
>
> But when you're in the regime where you're working with large raw
> memory buffers, then that's also the regime where inter-process
> shared-memory becomes really efficient. Hence projects like Ray/Plasma
> [1], which exist today, and even work for sharing data across
> languages and across multi-machine clusters. And the pickle
> out-of-band buffer API is general enough to work with shared memory
> too.
>
> And even if you can't quite manage zero-copy, and have to settle for
> one-copy... optimized raw data copying is just *really fast*, similar
> to memory access speeds. And CPU-bound, big-data-crunching apps are by
> definition going to access that memory and do stuff with it that's
> much more expensive than a single memcpy. So I still have trouble
> figuring out how skipping a single memcpy will make subinterpreters
> significantly faster that subprocesses in any real-world scenario.
>

While large object copies are fairly fast -- I wouldn't say trivial, a
gigabyte copy will introduce noticeable lag when processing enough of them
-- the flip side of having large objects is that you want to avoid having
so many copies that you run into memory pressure and the dreaded swapping.
A multiprocessing engine that's fully parallel, every fork takes chunks of
data and does everything needed to them won't gain much from zero-copy as
long as memory limits aren't hit. But a pipeline of processing would
involve many copies, especially if you have a central dispatch thread that
passes things from stage to stage. This is a big deal where stages may take
longer or slower at any time, especially in low-latency applications, like
video conferencing, where dispatch needs the flexibility to skip steps or
add extra workers to shove a frame out the door, and using signals to
interact with separate processes to tell them to do so is more latency and
overhead.

Not that I'm recommending someone go out and make a pure Python
videoconferencing unit right now, but it's a use case I'm familiar with.
(Since I use Python to test new ideas before converting them into C++.)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NBO4EZ5OHSDBTHSTWLPG45IAD3OHN3AL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Emily Bowman]

Python has always preferred full-word over old-school C/Perl/PHP-style
abbreviated names. Clarity is paramount. (Or this whole discussion wouldn't
even be happening.)

I think this is *more* of a zip_shortest than zip_strict, but since you can
never have total clarity without a method name that doubles as a docstring,
whatever works will work as long as it's documented.

Em

On Wed, May 20, 2020 at 3:33 PM Joseph Jenne via Python-Dev <
python-dev@python.org> wrote:

> I'd like to suggest "len_eq" as a short but (rather) self-explanatory
> option.
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ENRSP4ZSA4D3X7MXQK43GJE3IE2RKEBD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

[Emily Bowman]

 On Wed, Jun 10, 2020 at 5:37 AM Mark Shannon  wrote:
 > By sharing an address space the separation is maintained by trust and
hoping that third party modules don't have too many bugs.

By definition, the use of any third-party module (or even the standard
library itself) is by trust and the hope that they don't have too many
bugs. Sure, this creates a potential new class of bugs, for those who use
it, while also offering the chance to find and fix old bugs like Victor
found. Mostly, though, it exposes lots of bad practices that people could
mostly get away with as long as the assumption was that everything would
always be single-threaded, single-process, and the entire software industry
is moving away from those assumptions, so it's only logical that Python
takes advantage of that shift instead of becoming another legacy language.

In the meantime, modules can explicitly label themselves as
single-interpreter only, requiring multiprocessing instead of threading or
embedding to work correctly. Modules were more than happy to label
themselves as 2.x only for a decade

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JKELVIZHMZRS4VPBNJFWSP5POACQ4ODU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

[Emily Bowman]

On Fri, Jun 12, 2020 at 7:19 AM Mark Shannon  wrote:

> Hi Edwin,
>
> Thanks for providing some concrete numbers.
> Is it expected that creating 100 processes takes 6.3ms per process, but
> that creating 1000 process takes 40ms per process? That's over 6 times
> as long in the latter case.
>
> Cheers,
> Mark.
>
> On 12/06/2020 11:29 am, Edwin Zimmerman wrote:
> > On 6/12/2020 6:18 AM, Edwin Zimmerman wrote:
> >> On 6/12/2020 5:08 AM, Paul Moore wrote:
> >>> On Fri, 12 Jun 2020 at 09:47, Mark Shannon  wrote:
>  Starting a new process is cheap. On my machine, starting a new Python
>  process takes under 1ms and uses a few Mbytes.
> >>> Is that on Windows or Unix? Traditionally, process creation has been
> >>> costly on Windows, which is why threads, and in-process solutions in
> >>> general, tend to be more common on that platform. I haven't done
> >>> experiments recently, but I do tend to avoid multiprocess-type
> >>> solutions on Windows "just in case". I know that evaluating a new
> >>> feature based on unsubstantiated assumptions informed by "it used to
> >>> be like this" is ill-advised, but so is assuming that everything will
> >>> be OK based on experience on a single platform :-)
> >> Here's a test on Windows 10, 4 logical cpus, 8 GB of ram:
> >>
> >
> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=100,
> globals=globals())
> >> 0.62975287
> >
> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=1000,
> globals=globals())
> >> 40.28172119964
> >>
> >> Or this way:
> > timeit.timeit("""os.system('python.exe -c "exit()"')""",number=100,
> globals=globals())
> >> 17.46125929995
> >>
> >> --Edwin
> > For comparison, on a single core linux cloud server with 512 mb of ram:
> >
> >
> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=100,
> globals=globals())
> > 0.354354709998006
> >
> >
> timeit.timeit("""multiprocessing.Process(target=exit).start()""",number=1000,
> globals=globals())
> > 3.847851719998289
> >
> > So yeah, process creation is still rather costly on Windows.
>

I was wondering that too, some tests show that process creation/destruction
starts to seriously bog down after a few hundred in a row. I guess it's
hitting some resource limits it has to clean up, though creating hundreds
of processes at once sounds like an antipattern that doesn't really deserve
too much consideration. It would be rare that fork is more than a
negligible part of any workload. (With A/V on, though, it's _much_ slower
out the gate. I'm seeing over 100ms per process with Kaspersky running.)

Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/S47P3DFRW46VRVWLSKDASREHLYOFE6L4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How to specify optional support of arguments

[Emily Bowman]

Isn't it more Pythonic to simply call the function and an alternative path
to handle the exception, anyway? Half of os needs to be tested for
NotImplementedError or OSError if it's going to run anywhere outside the
development environment anyway, otherwise you're stuck with only the most
basic functions. What _would_ be handy is a list of what each function
throws.

As for the original question, since it's duplicating or wrapping a module
level functionality, it should be module level, rather than function level,
and if there's a better design then it would need to be ported back to os
as well. Although I could also see good reasoning behind os being
implicitly or having to be explicitly imported to test for the
less-compatible extensions.

On Sun, Jun 14, 2020 at 11:14 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

>
> On 15.06.2020 8:45, Serhiy Storchaka wrote:
> > 14.06.20 23:45, Ivan Pozdeev via Python-Dev пише:
> >> 1. The documentation clearly says that it's supported depending on OS
> flavor -- so if I want to know if I can supply it, I need to rather
> >> check `os.name`. Those members are thus redundant.
> >>
> >>  If the distinction is finer than os.name then I'd need some
> other, case-specific check depending on what the distinction is;
> >> alternatively, I could check the function's signature in its metadata
> if the support is reflected in it.
> >
> > Yes, it is finer than os.name. It can depend on the kernel or libc
> version (and we do not know which versions are required on every
> > platform), and there are a lot of platforms besides the main three. The
> user should not be expert in all platforms on which his program
> > potentially can be ran.
> >
> > The function's signature is the same on all platforms. Just on some
> platforms only default value can be passed (None for dir_fd) or only
> > specific types of argument is accepted (path-like, but not int).
>
> Then a single boolean flag is clearly not enough. Compare: in
> https://docs.python.org/3/library/resource.html , the set of present
> RLIMIT_*
> members shows which rlimits are available in the specific OS.
>
> So I guess you want some similar pointers that would show which relevant
> #define constants (or other C-level entities that govern the
> availability) were present at the time of compilation.
> If availability is rather governed by a runtime than compile-time check,
> then something to perform the same check should be introduced; the
> distinction from .supports_stuff is it would be named after the check and
> completely decoupled from any functions that might be affected by
> the check.
>
>
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/YWYTZRLQK4ZHRFX3G3MJDGN6H4BJQCKN/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> > --
> > Regards,
> > Ivan
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/BJ7HFKNQAO3C44XQ75AEYCRTG5GMYTU5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UOTPZGFJ4IGPWDD2G5V5GDDP3G4NDY2H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

[Emily Bowman]

On Wed, Jun 17, 2020 at 5:56 AM Nick Coghlan  wrote:

>
> Doing full blown zero-copy ownership transfer of actual Python objects
> would be more difficult, since the current plan is to have separate memory
> allocation pools per interpreter to avoid excessive locking overhead, so I
> don't currently expect to see that any time soon, even if PEP 554 is
> accepted. Assuming that remains the case, I'd expect multiprocessing to
> remain the default choice for CPU bound use cases where all the interesting
> state is held in Python objects (if you're going to have to mess about with
> a separate heap of shared objects anyway, you may as well also enjoy the
> benefits of greater process isolation).
>

So most likely there wouldn't be any way to share something like a
bytearray or another buffer interface-compatible type for some time. That's
too bad, I was hoping to have shared arrays that I could put a memoryview
on in each thread/interpreter and deal with locking if I need to, but I
suppose I can work through an extension once the changes stabilize.
Packages like NumPy have had their own opaque C types and C-only routines
to handle all the big threading outside of Python as a workaround for a
long time now.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7MR4MJDTFQIEEMY6WQ2IE4EYFYU6PPKJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: os.add_dll_directory and DLL search order

[Emily Bowman]

It's still a problem, even if it's a problem in the opposite direction than
you first thought (Python has a newer sqlite, rather than older). Updating
your API fixes the problem now, but you still need to decide how you check
for and handle newer, potentially incompatible library versions.

On Mon, Jun 22, 2020 at 1:13 PM Seth G  wrote:

> Thanks Ned.
> I did double check the docs for sqlite3 after posting and wondering why
> the versions were so different.
> I guess the clue should have been the sqlite-3 !
> Reading the history of the module I presume sqlite3 has its own module
> version number as it was integrated from a separate project.
>
> Seth
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NYFXECAXMGZM73DSB5AF74O5FV4TFXOL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

On Tue, Jun 23, 2020 at 2:10 PM MRAB  wrote:

> I think that's done for consistency. '_' is a wildcard and you can have:
>
>  case (_, _):
>
> to match any 2-tuple, so:
>
>  case _:
>
> would match any value, and can thus already serve as the default.
>
> I wouldn't object to 'else', though.
>

Can you have case (x,x): ? I haven't tried the implementation, but it's not
addressed in the PEP that I see, and if that's legal, then _ is effectively
just a style choice, rather than a functional one, and there's no reason it
shouldn't also be a named match.

+1 for including "else:" for consistency even if that's just a shim for
"case _:"
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SBFOEILU56E5QCM6344QNGEMKKT5MWKE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

 On Tue, Jun 23, 2020 at 10:59 PM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

>
> >> I also (with others) prefer `else:` or perhaps `case else:` to using
> >> the`_` variable.
> >> The latter is obscure, and woudn't sit well with code that already
> >> uses that variable for its own purposes.
> >>
> > I think that's done for consistency. '_' is a wildcard and you can have:
> >
> > case (_, _):
> >
> > to match any 2-tuple, so:
> >
> > case _:
> >
> > would match any value, and can thus already serve as the default.
> >
> Consistency with what?  Where else is `_` currently used as a wildcard?


Calling it a wildcard for the purposes of matching is more about using the
terminology someone who wants to match a thing would search for. In other
contexts it's called a throwaway, but it serves the exact same purpose.
Calling it a throwaway would confuse people who don't know how language
features are linked, but just know they want a catchall/wildcard.

I wonder if it's time to officially designate _ as a reserved name.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QIRPBTPDQGMMYS26OB6JUTB2NN42OXBQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

On Wed, Jun 24, 2020 at 3:15 PM Ethan Furman  wrote:

> > I too thought "why not else:?" at first. But "case _:" covers it in
> > the one obvious way after grasping how general wildcard matches are.
>
> "case _:" is easy to miss -- I missed it several times reading through the
> PEP.
>
> > Introducing "else:" too would be adding a wart (redundancy) just to
> > stop shallow-first-impression whining.
>
> Huh.  I would consider "case _:" to be the wart, especially since "case
> default:" or "case anything:" or "case i_dont_care:" all do basically the
> same thing (although they bind to the given name, while _ does not bind to
> anything, but of what practical importance is that?) .
>

There's always making everyone equally annoyed, and allowing 'case else:'
(not a very serious suggestion, though it does have a certain sort of
symmetry).
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5FEGF436IVEMMDPGMPTPDWEW2VDFTU7A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

On Thu, Jun 25, 2020 at 9:21 AM Rhodri James  wrote:

> Well, now is the time for expressing surprise :-p
>
> As I've said before, one of my main problems with the PEP is as you go
> through it, more and more special cases and surprises appear, and the
> consequences of earlier surprises generate more special cases and
> surprises.  You claim not unreasonably that it's easy to remember that
> "_" is special in matches.  Maybe you're right, but that decision has
> consequences spelled out later in the PEP that are less easy to
> remember.  Another example: I had not previously thought the definition
> of name patterns to be surprising, but apparently they are (it just
> surprised me, at any rate).  That consequently makes the definition of
> constant value patterns, which I was already iffy about, really quite
> surprising.
>
> Each individual learning curve might be small, but cumulative total by
> the time you reach the end of the PEP is large.  Simple match statements
> will, with adequate squinting, look recognisably like other areas of
> Python.  Complex match statements won't.  And that's a problem for
> anyone who wants to be able to read someone else's code.
>
> Bear in mind I am predominantly a C programmer who uses Python from time
> to time for tools and glue.  If I have to put in effort to learn new
> special-case rules in Python, that's an active discouragement; I'm
> frankly unlikely to bother, and more likely to write those tools and
> glue in C instead.  I'm certainly much less likely to use someone else's
> tools and glue if I have to re-read the spec to remind myself what all
> the gotchas are.
>

On my personal "potentially inscrutable uses of a tool" this still rates
well below list comprehensions, so there's that; the biggest pet peeve I
have anymore is understanding at a glance what is and isn't an assignment.
This is a draft PEP and a lot of discussion around making assignment vs
matched classes more explicit, so it's not like this is going to be set in
stone, and I doubt that most will ever use the more esoteric parts of the
syntax. One way or another, this is going to be a far more capable, and
thus complex, tool than a switch statement, so there's only so much
obviousness you can ask for coming in blind.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FIPQMOHWVYOPBFLH2MZN66Z2DM7TBWL7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Emily Bowman]

On Wed, Jun 24, 2020 at 12:46 PM Guido van Rossum  wrote:

> Everyone,
>
> If you've commented and you're worried you haven't been heard, please add
> your issue *concisely* to this new thread. Note that the following issues
> are already open and will be responded to separately; please don't bother
> commenting on these until we've done so:
>
> - Alternative spellings for '|'
> - Whether to add an 'else' clause (and how to indent it)
> - A different token for wildcards instead of '_'
> - What to do about the footgun of 'case foo' vs. 'case .foo'
>
> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
> variable binding and '?' for a wildcard.)
>

I don't think combining assignment and wildcard will help. '_' is fine for
that. I could get used to '?' as an assignment or a wildcard, but it would
always be a double-take if it was both.

I've seen languages that use '>foo' to indicate assignment, but I can't for
the life of me remember which now, aside from shell redirection. '=foo'
might be more obvious. In the end I think it's only important that there's
some assignment operator, and we'll all get used to whatever you choose.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QSJRX2QAPA45KMJOZHW2WYPJWRPRFL65/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

On Thu, Jun 25, 2020 at 3:41 PM Richard Damon 
wrote:
> Actually, you could make _ less special by still binding the value to

> it, just make it special in that you allow several values to be bound,
> and maybe just define that the result will be just one of the values,
> maybe even specify which if you want.
>

Like Guido said above, the problem is that _ is already effectively
reserved for translated text. Combining the two would feel a bit weird, but
should still be possible.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KJMYK6AP3CPA2LJUFSAKKO3JSHZJYZCP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

On Thu, Jun 25, 2020 at 8:31 PM Richard Damon 
wrote:

>
> I thought _ was also commonly used as:
>
> first, -, last = (1, 2, 3)
>
> as a generic don't care about assignment. I guess since the above will
> create a local, so not overwrite a 'global' function _ for translations,
> so the above usage works as long as that function (or whatever namespace
> you are in) doesn't use _ for translations. As long as the bindings in
> match also make the symbol a local (which seems reasonable) then you
> would get a similar restriction.
>

The PEP currently says:

"The named class must inherit from type. It may be a single name or a
dotted name (e.g. some_mod.SomeClass or mod.pkg.Class). The leading name
must not be _, so e.g. _(...) and _.C(...) are invalid. Use object(foo=_)
to check whether the matched object has an attribute foo."
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EAMFUFSEPZFABBMD3EWASUS5YQOA26YQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

Whoops, meant to reply to Gregory on that one, sorry Richard.


On Thu, Jun 25, 2020 at 7:15 PM Gregory P. Smith  wrote:

>
> Can I use an i18n'd _("string") within a case without jumping through
> hoops to assign it to a name before the match:?
>


The PEP currently says:
>
> "The named class must inherit from type. It may be a single name or a
> dotted name (e.g. some_mod.SomeClass or mod.pkg.Class). The leading name
> must not be _, so e.g. _(...) and _.C(...) are invalid. Use object(foo=_)
> to check whether the matched object has an attribute foo."
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KC6KLMBJZY3VKIDY2TT2QUQ36AILYUW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

On Fri, Jun 26, 2020 at 12:42 AM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

> 1) In the beginning of the "Mapping Pattern" section:
>  "{" (pattern ":" pattern)+ "}"
> This is spelt inconsistently: there is a `+` before the closing `}`
> but not after the opening `{`.
>

That grammar is more like a regex: + means "accept one or more of the
previous" here.

Maybe grammar inserts should be their own subsections to avoid confusion,
or at least highlighted, instead of mixing into the text.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/G2HL7KKWSZRQQ5TL5ZD5M3K2BPEUMLJK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Emily Bowman]

On Fri, Jun 26, 2020 at 3:47 AM Paul Moore  wrote:

> For me, this prompts the question (which I appreciate is more about
> implementation than design) - would there be any (significant)
> performance difference between [...]


> In C, the switch statement was explicitly intended to be faster by
> means of doing a computed branch. In a higher level language, I can
> see the added features of match meaning that it's *slower* than a
> series of if tests for simple cases. But I have no intuition about the
> performance of this proposal. I'd like to believe that the choice
> between the 2 alternatives above is purely a matter of preferred
> style, but I don't know. If match is significantly slower, that could
> make it a bit of an attractive nuisance.
>

Each case essentially compiles down to an equivalent if structure, already.
There's no penalty that I'm seeing. There's actually much more room for
optimizing eventually, since the test is bound to a single element instead
of any arbitrary if expression, and a Cython or PyPy could work some magic
to detect a small set of primitive types and optimize for that.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7U7VAG2NVWZFBIOH36KVEJC5PCSHZ2R7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Emily Bowman]

On Mon, Jun 29, 2020 at 7:41 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:

> Perhaps you don't want to believe the results, but the timings are
> careful, stable, repeatable, and backed-up by a disassembly that shows the
> exact cause.  The builds used for the timings were the production macOS
> builds as distributed on python.org.
>

This points more to specific builds needing to be fixed, if their build
options result in significantly un-optimized code on the same cpu
architecture.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BCWCGBVXTOBAQW5B5OYZVBFEZENSSLGC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Emily Bowman]

I completely agree with this, that UTF-8 has become the One True
Encoding(tm), and UCS-2 and UTF-16 are hardly found anywhere outside of the
Win32 API. Nearly all basic emoji can't be represented in UCS-2 wchar_t,
let alone composite emoji.

So how to make that C-compatible? Make everything a void* and it just comes
back with as many bytes as it gets?

On Tue, Jun 30, 2020 at 5:22 AM Richard Damon 
wrote:

> On 6/30/20 7:53 AM, M.-A. Lemburg wrote:
> > Since the C world has adopted wchar_t for this purpose, it's the
> > natural choice.
>
> I would disagree with this comment. Microsoft Windows has chosen to use
> 'wchar_t' for Unicode, because they adopted UCS-2 before it morphed into
> UTF-16 due to the expansion of Unicode above 16 bits. The *nix side of
> the world has chosen to use UTF-8 as the preferred way to store Unicode
> characters.
>
> Also, in Windows, wchar_t doesn't really meet the requirements for what
> C defines wchar_t to mean, as wchar_t is supposed to represent every
> character as a single unit, and thus would need to be at least a 21 bit
> type (typically, it would be a 32 bit type), but Windows makes it a 16
> bit type due to ABIs being locked before the Unicode expansion.
>
> --
> Richard Damon
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/TA2ITVZY6ZGH2Y42JAXD243RSG7MONTV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KHFCEVSMTF6LIJAKHCAKTYAYWU6JEBNB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

[Emily Bowman]

On Wed, Jul 1, 2020 at 4:09 AM Antoine Pitrou  wrote:

> How does this help third-party extensions?
>

If the cost is high enough, exposing the guts of a function to allow the
compiler to inline it is not unreasonable; all of the major compilers have
ways to inline things that are technically across a dynamic boundary, if
you declare them properly. The trade-off is accepting that it may have to
be rebuilt at some point, but an ABI change is less painful than an API
change. Relying on this kind of "optimized interface" would have to be
opt-in, since most won't need it and it would be actively harmful for
portability. Actually, that's probably an attractive nuisance, better to
just make extension writers copy-paste the function into their own codebase
if they need performance that badly for a specific call.

Better to identify an actual existing case that's degraded by the change
and can be tested against than a hypothetical, though. The macos build is
already getting fixed thanks to that!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DZBO5HFAYZ57L26GHFKRYCUYOFBOEJT7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Emily Bowman]

 I don't see how this extrapolates to arbitrary, extended match
expressions? You're proposing a slightly more flexible switch, which match
is only intended to be as the most basic case. Even if you purely swapped
it out with any the various proposals for identifying a constant vs a
target, it's still far more verbose than any of them.

On Sat, Jul 4, 2020 at 4:31 PM Shantanu Jain  wrote:

> Thank you for this PEP! Pattern matching is really exciting.
>
> As the PEP mentions and the thread evidences, the current dot syntax for
> the “constant value pattern” is a tricky point. Given this, I thought I’d
> throw another suggestion into the bikeshed.
>
> Use percent placeholder to indicate lookup (or even eval) semantics for a
> given name. For example:
> ```
> FOO = 1
> value = 0
>
> match value:
> case %(FOO):  # This would not be matched
> ...
> case BAR:# This would be matched
> ...
> ```
> I like this syntax because it’s reminiscent of named substitution in
> percent formatted strings. It suggests a substitution / placeholder
> metaphor that is quite fitting. It has the benefit of not introducing a new
> symbol into Python and being explicit and hard to miss, including in nested
> contexts.
>
> Note, it seems like it would also be technically possible to use curly
> braces (the more idiomatic means of named substitution in Python 3):
> ```
> case {FOO}: …
> ```
> The main downside of this is that it could look like some sort of
> singleton “set pattern” (note that the PEP only supports “sequence
> patterns” and “mapping patterns”).
> (But set patterns maybe don’t quite make sense + if your set pattern had
> multiple elements you’d still get a SyntaxError. For other examples where
> something in Python looks like a set literal but isn’t, refer to `{}` and
> f-strings, so it’s maybe not the biggest stretch)
>
> Both of these suggestions could also allow us more flexibility for
> constant value patterns, since currently there isn't a good way to match
> against a constant expression. For example, we could extend this syntax to
> allow us to express:
> ```
> case %(2 ** 10): ...
> ```
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/YQUCFREQ2P7NENOTPBE277I3BZ6DGXSR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WTUD5LSX7QZVSJM4UZLAVLW5OV4PNWS2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Suspected Spam]Re: Recent PEP-8 change

[Emily Bowman]

On Sat, Jul 4, 2020 at 5:37 PM Greg Ewing 
wrote:

> On 5/07/20 3:24 am, Stephen J. Turnbull wrote:
> > Amusingly, Strunk (1918) was perfectly happy with split infinitives,
> > though he noted it centered whiteness.  (Obviously he didn't put it
> > that way, more along the lines of "some people will look down on
> > you.")
>
> Um... what?
>
> Are you saying that people who split infinitives are usually
> black, and the people who look down on them are white? If so,
> it would seem that Strunk is actually standing up for black
> people here.
>
> (I don't actually believe this has anything to do with race,
> I'm just trying *to fully understand* your reasoning.)
>

Whatever he meant, nothing about split infinitives is in my 1918 original
copy of Strunk's rules, which is basically a compilation of common-sense
ways to not write like a legal paper or dissertation trying to baffle the
reviewers into approval. Which, sadly, continues into this day.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/X4RPPBRSTIS3D4IEE3NUI7BN6465YFFP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Emily Bowman]

On Tue, Jul 7, 2020 at 8:37 AM Rhodri James  wrote:

> I'm not quite convinced about making "_" non-binding, mostly because of
> the knock-on effects in the PEP for other types of patterns.  It seems
> to breed more special cases, and I can't help but feel that's a bad sign.
>

After spending some time with it in my head and in the actual testbed, it
seems like a reasonable compromise. case Point(x,x): being illegal while
x,x=(1,2) is perfectly legal is a bit of contention, but grammar also
doesn't need to be perfectly consistent in order to learn to speak a
language, it just needs to minimize the context-switching. It'd be so
simple if we could use case *:, but alas.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GD4XNSAW463J2U3P546UO6NFFENC3RUW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 (match statement) playground

[Emily Bowman]

On Wed, Jul 8, 2020 at 7:03 AM Kerwin Sun  wrote:

> I tried with this code:
>
[...]

> def whereis(point):
> case w:
>  print("Not the answer, local w")
> case z:
>  print("The answer")
> case _:
>  print("other")
> whereis(42)


 w, z and _ are all equivalent here, therefore it will take the first
matching branch. The very first post about 622 contained a caveat that case
_: will never be reached if case identifier: exists instead. Equivalent
branches are only ignored, not illegal.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2Y2GROC3IRLGUMXHHVFPODOZG35KYBOE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Emily Bowman]

On Sat, Jul 18, 2020 at 3:29 AM  wrote:

> > adept at ignoring them, we will again have difficulties when debugging
> > as we won't easily see them.
> > Besides which, the problem is solved:
> >
> > namespace.var is a lookup
> > var is a store
>
> These rules can't be deduced from a few examples, or from experience from
> other languages. You have to explicitly learn them. Since newcomers won't
> propably learn them first (if at all), they won't understand how it works,
> and they will propably introduce bugs hard to debug. They'll think it's a
> kind of "swith case" new construct, and will use it that way, completly
> ignoring the "capturing" property that shows in some cases and not in
> others.
>
> match entree[-1]:
> case Sides.SPAM:
> # newcomers will understand that entree[-1] == Sides.SPAM and
> write the code they need
>
> SPAM = "spam"
> match entree[-1]:
> case SPAM:
> # newcomers will understand that entree[-1] == "spam" and
> write the code they need
> # ignoring that now, in the following code, SPAM == anything
> but "spam"
> # introducing a bug anywhere in the following code where SPAM
> is expected to hold the
> # initial value
>

If a constant's actually constant, as in

SPAM: Final = "spam"

then it'll throw an error. Likewise, the first time it does something
totally unexpected like insert something into what they thought held a
match pattern, it'll break their initial assumptions and hopefully get them
to read the documentation, to form a more accurate mental model.

As long as

> namespace.var is a lookup
> var is a store

is big, bold, and front & center in the docs, I think everyone will catch
on very quickly and wrap their vars in a class, even if they never use it
for more than a glorified switch-case. Designing an entire feature around
what someone who's never encountered it before thinks it might do doesn't
seem useful, since anyone could bring any number of assumptions.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BCGMP6LDBWL6LQWKESLNL5NOMJZNLMZO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Emily Bowman]

On Fri, Sep 4, 2020 at 10:31 AM Stefan Krah  wrote:

>
> All the time, especially when I'm writing them. I imagine that there's
> a huge amount of internal company code that discourages use of pip
> installed packages as well.  Or has an air-gapped network in the first
> place.
>

That's wildly hyperbolic; not only will Python retain distutils through
3.11, any "airgapped" build will rest on an existing build that cannot be
upgraded, so dependencies are a moot point.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NXWL4UMLBOXAEMI4S2VTJNW3CVNIHY2Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Emily Bowman]

On Fri, Sep 4, 2020 at 3:11 PM Stefan Krah  wrote:

>
>
> It is not hyperbolic at all. You can get permissions for a certain set
> of modules (the stdlib), but not for PyPI packages.
>
> Of course the upgrade is not via the network, that is beside the point.
>

If you can update to a breaking Python version, but aren't allowed one
single point version of an external module, you have a process problem.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZDV5OHDEVH3DGBHLPRQIZ7CHBLYV4CLA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Emily Bowman]

On Sat, Sep 5, 2020 at 12:37 AM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> As I wrote in
> https://stackoverflow.com/questions/25337706/setuptools-vs-distutils-why-is-distutils-still-a-thing/40176290#40176290,
>
> distutils has a responsibility that setuptools as a 3rd-party entity
> cannot fulfill -- to set the core standards for addon modules structure
> and interface and be guaranteed to be present and compatible with the
> Python distribution that it comes with.
>
> If you are going to remove distutils, something else will need to fulfill
> these goals.


Obviously, the "something else" is setuptools, which has filled that niche
for well over a decade now, and shows no signs of going away anytime soon.
Maybe someday there might be a PEP 517 challenger, but for now, setuptools
isn't going anywhere even if distutils goes away.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QUA6ITJJ7366FKUVQH3ROBHBU7UMP2B2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Understanding why object defines rich comparison methods

[Emily Bowman]

NotImplemented is like a pure virtual function; failing to implement it
tells you that you forgot part of the contract, except at runtime instead
of compile time. So if you never need them, you're free to elide them, but
if you want full compatibility, you need to implement every part of it.

If someone tried to Obj + Obj and that's just completely nonsensical for
the type, then NotImplemented is a reasonable message, as opposed to
NameError which can be rather confusing. Alternately, you can implement it
and tell the caller exactly why it's not implemented. It's also useful for
anyone looking to subclass by immediately showing them every base method
they might need to implement.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VPARRUAONYWMKELECKVAC4HP7AI23W2W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Emily Bowman]

On Mon, Sep 28, 2020 at 7:23 AM Marco Sulla 
wrote:

> On Mon, 28 Sep 2020 at 13:56, Nick Coghlan  wrote:
> > For usage, whether something is a macro or not should either be
> irrelevant (when they're used as a more powerful function call or
> > decorator), or else entirely obvious from the way you use it (when
> they're defining a new pseudo-statement), so it doesn't make sense to
> > emphasize the syntactic marker too much.
>
> IMHO `import!` can be easily confused with `import`, even with a
> monospace font. An alternative is that macro must have a name
> different from keywords (so you will have macro_import!, for example),
> even if I'd prefer my first proposal (maybe something like %import).
>

I think the whole point is that import! won't be obvious unless you're
looking for it, and those macros won't be obvious unless you're looking for
them. They're meant to blend in rather than stand out.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DBM47OMSR5M4NYXERG6OV3BN332H2KCU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: fail keyword like there is pass keyword

[Emily Bowman]

On Wed, Oct 28, 2020 at 6:49 AM Jean Abou Samra  wrote:

> where `impossible` raises AssertionError.
>

Reserving a common English word as a new keyword (whether fail or
impossible) is the mother of all breaking changes. The syntactic sugar it
provides is not only tiny, it's pretty much negative, since any message it
could provide would be too generic to be of much use, versus raising your
own relevant exception message.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ONEKNUWIPL2QHA4K5JY4CFKHPU7FJ4HI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Advice / RTFM needed for tool setup to participate in python development from a Windows host

[Emily Bowman]

Even if Python itself is the standard distribution, you should be able to
debug your outside DLL module in VS just by putting a breakpoint on your
favorite line and setting "/path/to/python.exe -m yourmodule" as the
command path under debugging in your project properties, or whatever
commandline accomplishes whatever initialization you need to test.
Multiprocessing might be something else entirely, I don't know, I've only
debugged DLLs in-process. As soon as your breakpoint is hit, it'll stop as
you'd expect, even though you started something else entirely.

-Em

On Wed, Dec 16, 2020 at 4:56 PM  wrote:

> Yes, that is my specific issue.  I have a C DLL invoked by a python
> wrapper module using ctypes that has at least one issue (and likely more
> than one) so I need to be able to start a python test script and debug the
> lower-level DLL code.  The C test programs for the lower-level C DLL all
> seen to succeed, so I am suspecting something is wrong in the wrapper code.
>
> If anyone has or knows of step-by-step instructions on how to set that
> debug environment up and start the outer-level script with debug
> breakpoints in the DLL I would greatly appreciate it.  I'm also doing my
> own searches for tutorials on debugging python with VS20xx, but have not
> read/viewed one of those yet.
>
> I have in fact been able to re-compile cpython and the lower-level DLL
> using the VS2019 command line tools, but so far my only debugging
> capability has been to insert fprintf's to a trace file in the lower-level
> DLL code (or macros that result in such output) into the C code where I
> *think* the problem is happening, but I have not been able to nail it down
> yet.  Being able to start the process from the IDE and catch any C errors
> when they happen would be ideal.
>
> My environment is Win10-64 and python 3.8.5.
>
> Peter
>
> > -Original Message-
> > From: Paul Moore 
> > Sent: Wednesday, December 16, 2020 2:20 PM
> > To: pjfarl...@earthlink.net
> > Cc: Python Dev 
> > Subject: Re: [Python-Dev] Advice / RTFM needed for tool setup to
> participate in
> > python development from a Windows host
> >
> > Personally, I just have Visual Studio and VS Code as my text editor. I
> > rarely use Visual Studio directly, though, I mostly use the
> > `build.bat` and similar scripts in the `PCBuild` directory.
> >
> > Having said that, I'm not doing anything like debugging problems with
> > DLLs, for which I imagine a decent C development environment is
> > needed. You don't have much choice other than Visual Studio there (no
> > other compiler is supported on Windows), though, so you'll probably
> > need to learn that.
> >
> > Paul
> >
> > On Wed, 16 Dec 2020 at 18:28,  wrote:
> > >
> > > Hello,
> > >
> > > I hope this is the correct place to ask this question.  I have a
> desire to
> > > participate in python development in a particular area from my Windows
> host
> > > machine, but I am not finding any concise listing of the tool setup
> needed
> > > to fully participate, nor any detailed guidance on how to proceed when
> > > underlying code debugging is necessary.
> > >
> > > I do know that some version of the MS VS20xx suite is necessary to
> begin.
> > > My initial attempts using the VS2019 Community Edition have been less
> than
> > > successful when it comes to debugging an underlying C library component
> > when
> > > the starting program is python because I have not figured out how to
> use the
> > > VS2019 environment to do that.
> > >
> > > So I would appreciate any RTFM / URL that can guide me in starting to
> > > participate, especially for guidance on debugging procedures for
> underlying
> > > C components when the initial program is a python script.
> > >
> > > I have read most of the "Python Developers Guide" material, but there
> is not
> > > any Window-specific tooling information that I have seen there yet.
> What
> > > other tooling do I need besides a VS20xx environment?
> > >
> > > I do have good experience in C programming, but not much in using
> VS20xx
> > > IDE's.
> > >
> > > TIA for your gentle guidance in curing my ignorance.
> > >
> > > Peter
> --
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/H4MZYLFFB4EF6ZMMXE4FYH7KJRKNE3ZS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NZSEDOCTIMRLJXQFOJWX73ZDIFPVHKRE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 3.10 change (?) for __bool__

[Emily Bowman]

 Even if you define __bool__() as returning a bool, and error/undefined
behavior otherwise, that doesn't eliminate side effects. Is it even
possible to nail down a definition to the point that you can say, "Thou
shalt not mutate or cause anything" and have it meaningfully enforced in
the compiler or interpreter?

-Em

On Wed, Jan 13, 2021 at 12:18 AM Paul Sokolovsky  wrote:

> Hello,
>
> On Wed, 13 Jan 2021 18:27:07 +1100
> Chris Angelico  wrote:
>
> []
>
> > > Optimizations are an implementation detail, and implementation
> > > details should not change the language.
> >
> > The language can also be defined in an optimization-friendly way,
> > though. Consider how we got positional-only arguments in Python: first
> > they existed in C-implemented functions in CPython, even though they
> > couldn't exist in pure Python code, and then the functionality got
> > added to the language definition, thus permitting the optimization.
>
> In this case, the culprit seems to be that __bool__() and many other
> "special" methods may have side effects. So, just as "const" annotation
> would be useful for variables, "pure" (side-effect free) annotation
> would be useful for functions.
>
> But that alone won't help due to too-dynamic nature of Python. It's not
> much of an optimization if, at runtime, at each call-site, you need to
> check whether a function is pure to decide if you have to call it, or
> may skip it. Instead, that rather be done at compile time.
>
> But checking which method (pure or impure) will be called when is again
> complicated statically in Python. What to do about that? Well, we can
> introduce, ahem, some "strict" mode, in which *all* __bool__(),
> __gt__(), and friends must be declared pure, and for good measure,
> returning bool. Then we know we can skip any such method call.
>
> You see, all heresy starts from small things...
>
> []
>
> --
> Best regards,
>  Paul  mailto:pmis...@gmail.com
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4P52JORZ4WBCPC6DERRITDRETEFWT73H/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JEJGH465VBGKORF5KMIZHX56WWB7MZUW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why aren't we allowing the use of C11?

[Emily Bowman]

 On Thu, Jan 28, 2021 at 1:31 PM MRAB  wrote:

> I have Microsoft Visual Studio Community 2019 Version 16.8.4 (it's free)
> and it supports C11 and C17.


While an upgrade for Community is free, for Pro/Enterprise without an
annual license it's not. They've gone 100% subscription now, but people who
have outright purchased in the past would now have to make that decision.
The other problem is that a large version update can consume a large
portion of a day, or even a week if it all goes horribly wrong, especially
if your real job is supposed to be building things with it. Then you get to
deal with the fun time that is deprecations and new warnings (and
potentially new bugs) hitting your other codebases. If you're in a team,
it'll have to be a team consensus and effort, since you probably need to be
in lockstep. If you're restricted by corporate policy to software that's
gone through specific approval processes, that takes even longer. All of
this contributes to weighing all the cool new stuff you get against all the
irritating everyone who uses it, thus the inertia.

In some ways it's a lot easier being a home user who can experiment with
the bleeding edge and use whatever they want with their projects, but we
don't pay the bills like the big companies with big governance do.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CCQ4CT3ZQPHRJHWUK57L2PFMPIJFXDKH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

[Emily Bowman]

On Tue, Feb 2, 2021 at 3:47 AM Inada Naoki  wrote:

> But when wchar_t* is UTF-16, ucs2_utf8_encoder() can not handle
> surrogate escape.
> We need to use a temporary Unicode object. That is what "inefficient"
> means.
>

Since real UCS-2 is effectively dead, maybe it should be flipped around:
Make UTF-16 be the efficient path and UCS-2 be the path that needs to
round-trip through Unicode. But I suppose that's out of scope for this PEP.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KWEJN7FKF4GUEW34KZZWXOD4W5HCLVIH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Emily Bowman]

A call for standardization is typically done when multiple competing
de-facto standards competing for space, especially if it's relatively
immature, as a way to bring stakeholders together and reduce fragmentation.
You don't just go through the standards process for its own sake, unless
it's a requirement for some specific kind of government contract or
whatever. C and C++ ended up standardized because they blew up and were
implemented in dozens of often-incompatible ways. Python's had a much more
constrained development process, for better or worse, in which there's
traditionally been very little divergence regarding important language
functionality or standard library support in alternate implementations.
Because the language, not just CPython, is allowed to evolve in every minor
version, as well, standardization would just hamstring that.

There's no reason it couldn't be done if the interest was there, but
there's just no really powerful impetus to actually do it. Python the
language isn't splintering. (2 vs 3 is long past us all, and it's not like
2 evolved in implementations that didn't pick up 3.)

-Em

On Fri, Feb 12, 2021 at 10:35 AM Dan Stromberg  wrote:

>
> What would it take to create an ANSI, ECMA and/or ISO standard for Python?
>
> It seems to have really helped C.
>
> It looks like Java isn't standardized, and it's done OK, though perhaps it
> was healthier in the past - before Oracle decided API's were ownable.
>
> I think standardizing Python might be really good for controlling its
> growth and avoiding featuritis.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/JZYW4JOTANYIOLYDQ6YHRUP2TWO52OAE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MVDATOACGGA2HNHLSVG4BBD7T4IBDKOC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

[Emily Bowman]

FWIW, it would really be nice if this was called IsInstance[...]; I feel
like that would neatly encapsulate its meaning to both old and new, that
it's just a yes/no on whether this is an instance of [...]. TypeScript has
the concept of a type guard but doesn't use that name in code, so there's
no reason to be wedded to it.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T3XEKYHDOFC6EDVUSC55AQKLW2NY3JWK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It is really necessary to check that a object has a Py_TPFLAGS_HEAPTYPE flag?

[Emily Bowman]

On Mon, Feb 15, 2021 at 4:11 PM Victor Stinner  wrote:

>
> I didn't use Ruby on Rails, but the feedback that I heard is that the
> ability to extend built-in types is appealing, but it is problematic
> in practice.
>

Monkeypatching's such a part of the Ruby (and Javascript) culture that
there isn't much pushback over it. The biggest problem is that it's such a
part of the culture that it's not uncommon to have multiple modules
redefining the same name in incompatible ways, which is as painful to track
down as it sounds. Ruby also has refinements, which only modify within a
specific scope (up to a single file), so forgetting whether it's enabled
can get you even inside the same project.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RWDD7ENAIUQKO62ISDMSG53I7AD5DNLD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecate support for mingw - add to PEP 11

[Emily Bowman]

On Sun, Feb 21, 2021 at 10:02 AM Dan Stromberg  wrote:

>
> It looks like CPython remains 100% C, so clang becomes more attractive:
>
> https://stackoverflow.com/questions/6329688/llvm-and-visual-studio-obj-binary-incompatibility
>
> Then again, do we allow C++ extension modules?  That might make C++ more
> relevant, even if CPython itself is purely C.
>

Extensions can easily be built in any language, C++ is even documented, and
I've built a simple one in Rust when I was learning it -- as long as you
use the equivalent of extern "C" { } for that language, or rebuild the
headers you need in another language (quite an undertaking, admittedly,
even with a header parser).

The line "You will still need the C compiler that was used to build Python;
typically Microsoft Visual C++." hasn't been accurate in a long time either
(it's been in there since Python 2.2, when VC++ 6.0 was the latest, which
had quite a few... quirks), anything that can digest the headers can link
via the C API just fine. I guess since it's just not tested or supported,
so you're on your own if you run into any issues with memory management,
threading conflicts, compiler bugs, header conversion issues, etc.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7VLV5LCW7XL2OILMVS57WDWDGDU5O765/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Emily Bowman]

On Tue, Feb 23, 2021 at 4:51 PM Random832  wrote:

> Why is it that this community is resigned to recommending a workaround
> when distributions decide the site-packages directory belongs to their
> package manager rather than pip, instead of bringing the same amount of
> fiery condemnation of that practice as we apparently have for *checks
> notes* splitting parts of the stdlib into optional packages? Why demand
> that pip be present if we're not going to demand that it works properly?
>

The alternative to virtualenv is the solution most software takes for, eg,
Java: Package a complete binary distribution internally to eliminate any
dependency on the system package -- and allow the software to pollute their
own package in any way they want without affecting the rest of the system,
while potentially becoming very out of date with security patches.
Virtualenv allows software to lockstep and pollute their own runtime of
Python almost all they want while still sharing the actual base install
that gets regular security and bugfix updates. (Of course, even the hint of
possibility that anything about the runtime could change and cause downtime
is too much for many enterprise Java systems, no matter how severe the
security update, so even ported to Python they wouldn't settle for that,
they'd still package the entire interpreter internally.)

Since telling application developers "no, don't do that, just get along"
doesn't work, no matter how loudly you say it, virtualenv is a happy middle
ground. A few core OS maintainers are much more likely to listen, so the
yelling about splitting up or overly customizing the stdlib achieves
results.

-Em
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/S6BIVMQH32J5VVWITDBSAWWJARSAVIFF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Emily Bowman]

After reading through the PEP and skimming the code (but I didn't build
it), something I didn't see: What happens to a currently conforming except
check?

try:
async with trio.open_nursery() as nursery:
# Make two concurrent calls to child()
nursery.start_soon(child)
nursery.start_soon(child)
except ValueError:
pass

I've removed the * from the example: Say the interface was built for 3.7,
but the "trio" module has been upgraded to use ExceptionGroups which can't
fall back to a standalone exception.

Silently hand back the first exception, or the first matching exception?
Deprecation warning? Silently skip? Context-specific error? Run the default
error handler?

I think that deserves a statement in the PEP.

-Em


On Mon, Feb 22, 2021 at 4:48 PM Irit Katriel via Python-Dev <
python-dev@python.org> wrote:

>
> Hi all,
>
> We would like to request feedback on PEP 654 -- Exception Groups and
> except*.
>
> https://www.python.org/dev/peps/pep-0654/
>
> It proposes language extensions that allow programs to raise and handle
> multiple unrelated
> exceptions simultaneously, motivated by the needs of asyncio and other
> concurrency libraries,
> but with other use cases as well.
>
> * A new standard exception type,  ExceptionGroup, to represent multiple
> exceptions with
>   shared traceback.
> * Updates to the traceback printing code to display (possibly nested)
> ExceptionGroups.
> * A new syntax except* for handling ExceptionGroups.
>
> A reference implementation (unreviewed) can be found at:
> https://github.com/iritkatriel/cpython/pull/10
>
> Thank you for your help
>
> Kind regards
> Irit, Yury & Guido
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2ABNKHUQK2GZZBPEOSOKZFVZTQCQ2QOK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Emily Bowman]

A side benefit is that if an Exception somehow propagates up where only
ExceptionGroup is defined, except *() could just work anyway, though it
might take a little magic to make sure they act the same. Like Guido said,
I don't think it can be retrofitted into existing *-less APIs, and it'll
either need a new API and deprecation, or dumping the old for the new
hotness if that's the maintenance strategy, but as long as docs call out
that this is now returning collective exceptions, I don't see a problem.

I don't think it's been mentioned, but it's a nice synergy with pattern
matching, even if it's wholly unrelated, and having both in one release
will actually make sense.

-Em


On Fri, Feb 26, 2021 at 6:45 AM Nathaniel Smith  wrote:

> On Fri, Feb 26, 2021 at 5:05 AM Irit Katriel 
> wrote:
> > I'm not sure it's safe to assume that it is necessarily a programming
> error, and that the interpreter can essentially break the program in this
> case.
> > Is this not allowed?
> >
> > try:
> > try:
> > obj.func()# function that raises ExceptionGroups
> > except AttributeError:
> > logger.info("obj doesn't have a func")
> > except *(AttributeError, SyntaxError):
> > logger.info("func had some problems")
>
> I'd be fine with disallowing that. The intuition is that things will
> be simplest if ExceptionGroup is kept as transparent and meaningless
> as possible, i.e. ExceptionGroup(ValueError) and ValueError mean
> exactly the same thing -- "some code inside this block raised
> ValueError" -- and ideally should be processed in exactly the same
> way. (Of course we can't quite achieve that due to backcompat issues,
> but the closer we can get, the better, I think?)
>
> If you need to distinguish between the AttributeError from
> 'obj.__getattr__("func")' vs the AttributeError from the call to
> func(), then there's already an obvious way to do that, that works for
> all functions, not just ones that happen to raise ExceptionGroups:
>
> try:
> f = obj.func
> except AttributeError:
> ...
> try:
> f()
> except ...:# or except *...:
> ...
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/W3GMOA7RVADLBL7L3VB2R3SZULS7QZ7W/
Code of Conduct: http://python.org/psf/codeofconduct/