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

[emmanuel . coirier]

Steven D'Aprano wrote:
[...]
> In any case, functional languages like Haskell, F# and ML are not the 
> only languages with pattern matching. Non-FP languages like C#, Swift, 
> Rust and Scala have it, and even Java has an extension providing pattern 
> matching:
> http://tom.loria.fr/wiki/index.php/Main_Page

I'm not against pattern matching at all. I think it's a very nice feature, but 
that one of its behavior which is variable capturing should be made more 
explicit, following the rules of the Zen of Python.

> It's been sometimes said that functional programmers are smarter, elite 
> programmers a level above the average OOP or procedural programmer, but 
> that's mostly said by functional programmers :-)

I would say there are fewer of them :-)

-- 
Emmanuel
___
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/RMUF5Q6B3UKPK67FB5ALQYILPZE2JJGZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[emmanuel . coirier]

Emily Bowman wrote:

> 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.

Currently, the following example is working without any error or warning on the 
current Guido's build. I'm aware that it is not the final version, but I didn't 
see anything for now guarding Final decorated values to be overwritten at 
runtime (either by an affectation or by a case clause).

from typing import Final
FIVE_VALUE: Final = 5

a = (7, 8)
match a:
case (FIVE_VALUE, 8):
print("in five value clause")
case _:
print("in default clause")

print(f"Value of FIVE_VALUE: {FIVE_VALUE}")

But I concede overwriting names that are Final could at least throw some 
warnings.

> 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.

My point is a bit deeper. I consider these rules a bit clumsy. I've undestood 
why they have been designed that way, but they didn't look pythonic. Like if 
scaffolding was still there.

> 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.

I'm sorry to disagree. Apple has built its brand on the fact that you didn't 
need the doc to succesfully use their products. I don't think that all features 
of the langage have to be that obvious, but the first look by some random dev 
should help them catch the thing, and avoid such a pitfall.

-- 
Emmanuel
___
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/6KDEVVVWBF57YQV3FI5HHDTKGJ5MCM6Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 constant value syntax idea

[Rob Cliffe via Python-Dev]

On 16/07/2020 08:16, Baptiste Carvello wrote:

Hello,

Le 15/07/2020 à 13:37, Mohammad Foroughi via Python-Dev a écrit :

Hi, I had an idea regarding the pattern matching issue of comparing with
a previous constant variable instead of assigning to a new local
variable. I'm not sure if this has been brought up before but instead of
using a symbol with the case statement what if we used a keyword.

[...]

Other ideas for the keyword are "const" or "static" but these 2 are more
difficult to recognise since they aren't in other parts of python but
the "global" keyword is already implemented so it would be easy to
understand.

What about simply "is", which is already a keyword?

AFAIK "is" has no meaning as a prefix operator as of now, so hopefully
it would not make the grammar ambiguous (how can one check that for sure?).

match color:
 case is RED:
 print("red")
 case is BLUE:
 print("blue")
 case other:
 print(f"unknown color {other}")

or with Rhodri James' example:

match value:
 case is x:
 print("value matches")
 case Point(is x, y):
 print("value matches x, y captured")
 case Line(Point(is x1, y1), Point(x2, is y2)):
 print("wouldn't call that pretty, but not ugly either")


Cheers,
Baptiste

P.S.: granted, it could mislead some users into thinking that the
comparison is done with "is" instead of "=="; but then, patterns are
special in many ways, users will have to just learn them…
Hm, plus ca change...  Your last paragraph inevitably suggests actually 
using '==' rather than 'is'.
Which is something I suggested way back, but I was firmly asked by Guido 
to "drop it".  (Which, up to now, I have.)

The specific objection he raised was that e.g. this example from the PEP
      case BinaryOp(left=Number(value=x), op=op, right=Number(value=y)):
would become
      case BinaryOp(left=Number(value===x), op===op, 
right=Number(value===y)):

which is unparseable.  Although I can't see why it couldn't be written
      case BinaryOp(left=Number(value=    ==x), op=    ==op, 
right=Number(value=   ==y)): # multiple spaces here for clarity

Rob Cliffe

___
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/TZEJHFALXL4OUBDYNQ5D6PEALUYHG57I/
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/MYNRDEMBDMUXKY7OPKWMAV4ULHL7U62G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: In case you're wondering about 3.5.10rc1

[Miro Hrončok]

On 04. 07. 20 9:01, Larry Hastings wrote:



It's held up on SSL.  Ubuntu 20.04 changed some security parameter tunings, 
which breaks some uses of the SSL module, and approximately eight modules in the 
test suite.  I assume this wasn't caught on the buildbots because they don't use 
Ubuntu--or at least not a build that fresh.  SSL and the test suite are all 
completely happy on older Ubuntu releases.


One could argue "it's fine, most people still using 3.5 are also using old OSes 
anyway".  But I don't want to release 3.5.10 if important functionality is 
broken on a popular OS.  So I'm waiting for help from the ssl module 
maintainer(s) who are very kindly looking into it.


My plan is to release 3.5.10rc1 once it passes the test suite on Ubuntu 20.04... 
whenever that is.  3.5.10 final will be automatically rescheduled for two weeks 
from that date.


Hey Larry.

Does any of the following patches help?

Fix test_alpn_protocols from test_ssl as openssl > 1.1.0f
changed the behaviour of the ALPN hook.
Fixed upstream: http://bugs.python.org/issue30714

https://src.fedoraproject.org/rpms/python3.5/blob/master/f/00270-fix-ssl-alpn-hook-test.patch


Not every target system may provide a crypt() function in its stdlibc
and may use an external or replacement library, like libxcrypt, for
providing such functions.
Fixed upstream: https://bugs.python.org/issue32635

https://src.fedoraproject.org/rpms/python3.5/blob/master/f/00290-cryptmodule-Include-crypt.h-for-declaration-of-crypt.patch



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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/GP57TGVLETOVQZRGVXWA4FYKHGDOI4NR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] How to customize CPython to a minimal set

[Huang, Yang]

Hi, all

There is a request to run python in a Linux-based embedded resource constrained 
system with sqlite3 support.

So many features are not required, like posixmodule, signalmodule, hashtable ...
But seems there are some dependencies among the 
Modules/Parser/Python/Objects/Programs...

Is there a way to tailor CPython 3 to a minimal set with sqlite3 (the less 
syscalls the better) ? 
Is it possible to do that?

Thank you.
___
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/ECPLKXQ42VNLHD5DP3RG57L3QTJ77FUT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How to customize CPython to a minimal set

[Guido van Rossum]

Have you considered starting with micropython? It’s made for embedded
systems and fully supports Python 3 syntax. Adding sqlite3 support to it
will be less work than stripping all the I/O from CPython.

—Guido

On Mon, Jul 20, 2020 at 06:48 Huang, Yang  wrote:

>
> Hi, all
>
> There is a request to run python in a Linux-based embedded resource
> constrained system with sqlite3 support.
>
> So many features are not required, like posixmodule, signalmodule,
> hashtable ...
> But seems there are some dependencies among the
> Modules/Parser/Python/Objects/Programs...
>
> Is there a way to tailor CPython 3 to a minimal set with sqlite3 (the less
> syscalls the better) ?
> Is it possible to do that?
>
> Thank you.
> ___
> 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/ECPLKXQ42VNLHD5DP3RG57L3QTJ77FUT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/ZIAH5VHJIFVXRKNIIS5DXBS4MMLHNTTM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] datetime module refactoring: folder vs parallel private modules

[Paul Ganssle]

Hi all,

I was hoping to get some feedback on a proposed refactoring of the
datetime module that should dramatically improve import performance.

The datetime module is implemented more or less in full both in pure
Python and in C; the way that this is currently achieved

is that the pure Python implementation is defined in datetime.py, and
the C implementation is in _datetime, and /after/ the full Python
version is defined, the C version is star-imported and thus any symbols
defined in both versions are taken from the C version; if the C version
is used, any private symbols used only in the pure Python implementation
are manually deleted (see the end of the file
).

This adds a lot of unnecessary overhead, both to define a bunch of
unused classes and functions and to import modules that are required for
the pure Python implementation but not for the C implementation. In the
issue he created about this , Victor
Stinner demonstrated that moving the pure Python implementation to its
own module would speed up the import of datetime by a factor of 4.

I think that we should indeed move the pure Python implementation into
its own module, despite the fact that this is almost guaranteed to break
some people either relying on implementation details or doing something
funky with the import system — I don't think it should break anyone
relying on the guaranteed public interface. The issue at hand is that we
have two options available for the refactoring: either move the pure
Python implementation to its own private top-level module (single file)
such as `_pydatetime`, or make `datetime` a folder with an `__init__.py`
and move the pure Python implementation to `datetime._pydatetime` or
something of that nature.

The decimal and zoneinfo modules both have this same issue; the decimal
module uses the first strategy with _pydecimal and decimal, the zoneinfo
module uses a folder with a zoneinfo._zoneinfo submodule. Assuming we go
forward with this, we need to decide which strategy to adopt for datetime.

In favor of using a datetime/ folder, I'd say it's cleaner to put the
pure Python implementation of datetime under the datetime namespace, and
also it gives us more freedom to play with the module's structure in the
future, since we could have lazily-imported sub-components, or we could
implement some logic common to both implementations in Python and import
it from a `datetime._common` module without requiring the C version to
import the entire Python version, similar to the way zoneinfo has the
zoneinfo._common

module.

The downside of the folder method is that it complicates the way
datetime is imported — /especially/ if we add additional structure to
the module, or add any logic into the __init__.py. Two single-file
modules side-by-side, one imported by the other doesn't change anything
about the nature of how the datetime module is imported, and is much
less likely to break anything.

Anyone have thoughts or strong preferences here? Anyone have use cases
where one or the other approaches is likely to cause a bunch of undue
hardship? I'd like to avoid moving this more than once.

Best,
Paul

P.S. Victor's PR moving this code to _pydatetime
 is currently done in such
a way that the ability to backport changes from post-refactoring to
pre-refactoring branches is preserved; I have not checked but I /think/
we should be able to do the same thing with the other strategy as well.



signature.asc
Description: OpenPGP digital signature
___
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/CCI7PDAL6G67XVVRKPP2FAYJ5YZYHTK3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: datetime module refactoring: folder vs parallel private modules

[Ivan Pozdeev via Python-Dev]

On 20.07.2020 20:58, Paul Ganssle wrote:


Hi all,

I was hoping to get some feedback on a proposed refactoring of the datetime 
module that should dramatically improve import performance.

The datetime module is implemented more or less in full both in pure Python and in C; the way that this is currently achieved 
 is that the pure Python 
implementation is defined in datetime.py, and the C implementation is in _datetime, and /after/ the full Python version is defined, the C 
version is star-imported and thus any symbols defined in both versions are taken from the C version; if the C version is used, any private 
symbols used only in the pure Python implementation are manually deleted (see the end of the file 
).


This adds a lot of unnecessary overhead, both to define a bunch of unused classes and functions and to import modules that are required 
for the pure Python implementation but not for the C implementation. In the issue he created about this 
, Victor Stinner demonstrated that moving the pure Python implementation to its own module would speed 
up the import of datetime by a factor of 4.


I think that we should indeed move the pure Python implementation into its own module, despite the fact that this is almost guaranteed to 
break some people either relying on implementation details or doing something funky with the import system — I don't think it should break 
anyone relying on the guaranteed public interface. The issue at hand is that we have two options available for the refactoring: either 
move the pure Python implementation to its own private top-level module (single file) such as `_pydatetime`, or make `datetime` a folder 
with an `__init__.py` and move the pure Python implementation to `datetime._pydatetime` or something of that nature.




What's the problem with

try:
    from _datetime import *
except ImportError:
    

?

Though

try:
    from _datetime import *
except ImportError:
    from _pydatetime import *

Would be more maintainable I guess.


The same goes for `pickle` then.


The decimal and zoneinfo modules both have this same issue; the decimal module uses the first strategy with _pydecimal and decimal, the 
zoneinfo module uses a folder with a zoneinfo._zoneinfo submodule. Assuming we go forward with this, we need to decide which strategy to 
adopt for datetime.


In favor of using a datetime/ folder, I'd say it's cleaner to put the pure Python implementation of datetime under the datetime namespace, 
and also it gives us more freedom to play with the module's structure in the future, since we could have lazily-imported sub-components, 
or we could implement some logic common to both implementations in Python and import it from a `datetime._common` module without requiring 
the C version to import the entire Python version, similar to the way zoneinfo has the zoneinfo._common 
 module.


The downside of the folder method is that it complicates the way datetime is imported — /especially/ if we add additional structure to the 
module, or add any logic into the __init__.py. Two single-file modules side-by-side, one imported by the other doesn't change anything 
about the nature of how the datetime module is imported, and is much less likely to break anything.


Anyone have thoughts or strong preferences here? Anyone have use cases where one or the other approaches is likely to cause a bunch of 
undue hardship? I'd like to avoid moving this more than once.


Best,
Paul

P.S. Victor's PR moving this code to _pydatetime  is currently done in such a way that the 
ability to backport changes from post-refactoring to pre-refactoring branches is preserved; I have not checked but I /think/ we should be 
able to do the same thing with the other strategy as well.



___
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/CCI7PDAL6G67XVVRKPP2FAYJ5YZYHTK3/
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/YK7UM5CSZTCMVPUWQHCY2JX4CZMMLIVK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 387: backwards compatibility policy

[Brett Cannon]

The SC has chosen to accept PEP 387!
https://www.python.org/dev/peps/pep-0387/

On Fri, Jun 12, 2020 at 2:44 PM Brett Cannon  wrote:

> Started at a discussion at
> https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421
> to try to finally resolve this PEP and our backwards compatibility policy.
>
___
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/22ESUSEF7QGZATKBMFBF3NCW4U4MVUU2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.8.5 released as a security hotfix. 3.9.0b5, the last beta before 3.9.0, also available

[Łukasz Langa]

This is a combined release of Python 3.8.5 and 3.9.0b5. Both are significant 
but for different reasons. Let’s dig in!

Security content in 3.8.5

We decided to release 3.8.5 ahead of schedule due to a number of 
security-related fixes. All details can be found in the change log 
 but 
the gist is:

CVE-2019-20907 : infinite loop in a 
maliciously created .tar file
BPO-41288 : segmentation fault during 
unpickling of objects using a crafted NEWOBJ_EX opcode
BPO-39603 : HTTP headers could be injected 
through a maliciously crafter method parameter in http.client
the original fix for CVE-2020-15801 caused a regression in 3.8.4 (see: 
BPO-41304 )
A small number of other urgent regression fixes and quality-of-life 
improvements are also present in the release. Get the release here:

https://www.python.org/downloads/release/python-385/ 


Maintenance releases for the 3.8 series will continue at the regular bi-monthly 
calendar, with 3.8.6 planned for mid-September 2020.
The last beta of Python 3.9.0 now also available

Python 3.9 is still in development. This release, 3.9.0b5, is the last of five 
planned beta release previews. Beta release previews are intended to give the 
wider community the opportunity to test new features and bug fixes and to 
prepare their projects to support the new feature release. You can get 3.9.0b5 
here:

https://www.python.org/downloads/release/python-390b5/ 


The next pre-release, the first release candidate of Python 3.9.0, will be 
3.9.0rc1. It is currently scheduled for 2020-08-10.
Call to action

We strongly encourage maintainers of third-party Python projects to test with 
3.9 during the beta phase and report issues found to the Python bug tracker 
 as soon as possible. While the release is planned to 
be feature complete entering the beta phase, it is possible that features may 
be modified or, in rare cases, deleted up until the start of the release 
candidate phase (2020-08-10). Our goal is have no ABI changes after beta 5 and 
as few code changes as possible after 3.9.0rc1, the first release candidate. To 
achieve that, it will be extremely important to get as much exposure for 3.9 as 
possible during the beta phase.

Please keep in mind that this is a preview release and its use is not 
recommended for production environments.

A reminder for core developers

To help make Python 3.9.0 the best possible release, our Development Cycle 
 section of the 
Python Developer’s Guide documents that:

A branch preparing for an RC release can only have bugfixes applied that have 
been reviewed by other core developers. Generally, these issues must be severe 
enough (e.g. crashes) that they deserve fixing before the final release. All 
other issues should be deferred to the next development cycle, since stability 
is the strongest concern at this point.

You cannot skip the peer review during an RC, no matter how small! Even if it 
is a simple copy-and-paste change, everything requires peer review from a core 
developer.

Major new features of the 3.9 series, compared to 3.8

Some of the new major new features and changes in Python 3.9 are:

PEP 584 , Union Operators in dict

PEP 585 , Type Hinting Generics In 
Standard Collections

PEP 593 , Flexible function and 
variable annotations

PEP 602 , Python adopts a stable 
annual release cadence

PEP 615 , Support for the IANA Time 
Zone Database in the Standard Library

PEP 616 , String methods to remove 
prefixes and suffixes

PEP 617 , New PEG parser for CPython

BPO 38379 , garbage collection does not 
block on resurrected objects;

BPO 38692 , os.pidfd_open added that allows 
process management without races and signals;

BPO 39926 , Unicode support updated to 
version 13.0.0;

BPO 1635741 , when Python is initialized 
multiple times in the same process, it does not leak memory anymore;

A number of Python builtins (range, tuple, set, frozenset, list, dict) are now 
sped up using PEP 590  vectorcall;

A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, 
_functools, _json, _locale, operator, resource, time, _weakref) n

[Python-Dev] Re: PEP 387: backwards compatibility policy

[Benjamin Peterson]

On Mon, Jul 20, 2020, at 13:50, Brett Cannon wrote:
> The SC has chosen to accept PEP 387! https://www.python.org/dev/peps/pep-0387/

Thank you, steering council! I am particularly grateful to Brett for pushing 
this PEP, in its eleventh year of existence, over the finish line.
___
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/QYEDYBJSGHOHHQIAGNVMFDLDNYZXDUY6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Rob Cliffe via Python-Dev]

On 16/07/2020 18:13, MRAB wrote:

On 2020-07-16 17:37, Steve Holden wrote:
While I understand the point of view that says that match ... : 
should encapsulate a sequence of indented suites, it seems to me that 
match/case/case/.../else has a natural affinity with 
try/except/except/.../finally/else, and nobody seems to think that 
the excepts should be indented. Or the finally. And naturally the 
match/else case are at the same indentation level, just as for/else, 
while/else and try/finally. So why, exactly, should case be indented?


My apologies for being a Bear of Very Little Brain.


[snip]
For all other statement structures (if, while, try, etc.), the first 
line ends with a colon and the second line is indented (and is a 
statement). Therefore the cases should be indented.


However, for all other statement structures (if, while, try, etc.), 
the other parts of the structure itself (elif, else, except, etc.) 
aren't indented. Therefore the cases shouldn't be indented.


Either way, it's inelegant.

Absolutely true.  However:

I think that equal indentation suggests suites of equal status. 
Increased indentation suggests suites are subordinate to a previous suite.

Consider these examples:

(1) if..elif...else: Suites are definitely co-equal (they are 
alternatives, only one of which is chosen).  So if/elif/else have equal 
indentation.
(2) for...else or while...else: It's arguable IMO (YMMV); Python has 
chosen to indent them equally.  I don't think it would have been 
outrageous to indent the 'else:';  one reason not to is that the 'else' 
might not stand out (it would typically be indented equally with the 
preceding line of code), unless it was allowed/forced to be indented 
*less than* 'for'.
(3) try...except...else:  IMO also arguable (at most one of 'except' and 
'else' can be executed).
(4) try...finally: The suites have equal status (both are always 
executed), so they have equal indentation.


Now to me, 'case' clauses are *subordinate* to 'match'.  After all, the 
value after 'match' applies to all the following 'case's.  So I would 
argue in favour of indenting 'case' statements.  This would make them 
stand out *more* (making a virtue out of 'match' *not* being followed by 
an indented suite).  A Good Thing.  One of the purposes of indentation 
is to make program structure clearly visible, which IMO this would do.


Or from a slightly different point of view: "match...case...case..." is 
a single construct, a self-contained program component. Indenting the 
'case's would stop them from distracting visually from other suites that 
are indented the same as 'match'.  (I.e. other program components of 
equal status.)


(If 'else' were allowed after 'match', I would argue that it should also 
be indented, for the same reasons, and because it is logically a case, 
albeit a special one.)


Rob Cliffe
___
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/3OAUJHV4THFUSBUPLVLULVWM4SADAW2B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Official joint communication from the Python Steering Council, PSF Board of Directors, and PSF Conduct WG

[Python Steering Council]

Recently, a series of discussions on this mailing list resulted in behavior 
that did not live up to the standards of the Python Community. The PSF Board of 
Directors, Python Steering Council, and the PSF Conduct Working Group would 
like to remind this community that our shared goal is to advance the Python 
language while simultaneously building a diverse, inclusive, and welcoming 
Python community. While the community has made progress in recent years, this 
discussion made it clear to many of us that we still have room to grow.

At the request of the PSF Board, the Steering Council, and members of the 
community, the PSF Conduct WG met to discuss these recent events and recommend 
action. As a result, warnings will be given to several members of the Python 
Community, and the Steering Council will be taking further action.

Especially during passionate discussions like these, we'd like to ask that all 
Pythonistas focus on being welcoming and respectful, and that we all try to act 
in the best spirit of the Python Community.

Thank you,
Python Steering Council
PSF Board of Directors
PSF Conduct WG
___
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/5NMO2XKYLCNUT7BTMIFQOPF57FDXLHTQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: datetime module refactoring: folder vs parallel private modules

[Guido van Rossum]

I would go with Ivan's second suggestion (_pydatetime.py). The Zen of
Python mentions "flat is better than nested" and a package seems overkill
here (I'm not sure why you chose a package for zoneinfo, but it looks like
it has a little more internal structure than a datetime package would have.)

On Mon, Jul 20, 2020 at 11:01 AM Paul Ganssle  wrote:

> Hi all,
>
> I was hoping to get some feedback on a proposed refactoring of the
> datetime module that should dramatically improve import performance.
>
> The datetime module is implemented more or less in full both in pure
> Python and in C; the way that this is currently achieved
> 
> is that the pure Python implementation is defined in datetime.py, and the C
> implementation is in _datetime, and *after* the full Python version is
> defined, the C version is star-imported and thus any symbols defined in
> both versions are taken from the C version; if the C version is used, any
> private symbols used only in the pure Python implementation are manually
> deleted (see the end of the file
> 
> ).
>
> This adds a lot of unnecessary overhead, both to define a bunch of unused
> classes and functions and to import modules that are required for the pure
> Python implementation but not for the C implementation. In the issue he
> created about this , Victor Stinner
> demonstrated that moving the pure Python implementation to its own module
> would speed up the import of datetime by a factor of 4.
>
> I think that we should indeed move the pure Python implementation into its
> own module, despite the fact that this is almost guaranteed to break some
> people either relying on implementation details or doing something funky
> with the import system — I don't think it should break anyone relying on
> the guaranteed public interface. The issue at hand is that we have two
> options available for the refactoring: either move the pure Python
> implementation to its own private top-level module (single file) such as
> `_pydatetime`, or make `datetime` a folder with an `__init__.py` and move
> the pure Python implementation to `datetime._pydatetime` or something of
> that nature.
>
> The decimal and zoneinfo modules both have this same issue; the decimal
> module uses the first strategy with _pydecimal and decimal, the zoneinfo
> module uses a folder with a zoneinfo._zoneinfo submodule. Assuming we go
> forward with this, we need to decide which strategy to adopt for datetime.
>
> In favor of using a datetime/ folder, I'd say it's cleaner to put the pure
> Python implementation of datetime under the datetime namespace, and also it
> gives us more freedom to play with the module's structure in the future,
> since we could have lazily-imported sub-components, or we could implement
> some logic common to both implementations in Python and import it from a
> `datetime._common` module without requiring the C version to import the
> entire Python version, similar to the way zoneinfo has the
> zoneinfo._common
> 
> module.
>
> The downside of the folder method is that it complicates the way datetime
> is imported — *especially* if we add additional structure to the module,
> or add any logic into the __init__.py. Two single-file modules
> side-by-side, one imported by the other doesn't change anything about the
> nature of how the datetime module is imported, and is much less likely to
> break anything.
>
> Anyone have thoughts or strong preferences here? Anyone have use cases
> where one or the other approaches is likely to cause a bunch of undue
> hardship? I'd like to avoid moving this more than once.
>
> Best,
> Paul
>
> P.S. Victor's PR moving this code to _pydatetime
>  is currently done in such
> a way that the ability to backport changes from post-refactoring to
> pre-refactoring branches is preserved; I have not checked but I *think*
> we should be able to do the same thing with the other strategy as well.
> ___
> 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/CCI7PDAL6G67XVVRKPP2FAYJ5YZYHTK3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to