[Python-Dev] Re: Can we change python -W option and PYTHONWARNINGS to use a regex for the message?

[Ivan Pozdeev via Python-Dev]

It'll probably be easier to change the warnings filter semantic 
(https://docs.python.org/3/library/warnings.html#the-warnings-filter)
to which those values are directly passed.

On 16.04.2021 16:07, Victor Stinner wrote:

Hi,

I propose to change the -W command line option and the PYTHONWARNINGS
environment variable to use the message as a regular expression in
Python 3.10. Or does anyone have a reason to keep the current behavior
as it is?

I created https://bugs.python.org/issue43862 for this change.

--

Python provides two ways to specify warnings filters:

* -W command line option: can be used multiple times
* PYTHONWARNINGS environment variable: can contain multiple options
separated by commas

While the Python API warnings.filterwarnings(action, message="", ...)
uses the message as a regular expression, -W and PYTHONWARNINGS
require to match *exactly* the *whole* message.

For example, if you only want to ignore the new distutils deprecation
warning, you must write exactly:

$ ./python -X dev -W 'ignore:The distutils package is deprecated and
slated for removal in Python 3.12. Use setuptools or check PEP 632 for
potential alternatives:DeprecationWarning' -c 'import distutils'

I use -X dev to show DeprecationWarning, or you can also use -Wdefault
if you prefer.

If the deprecation warning changes in Python or if you have a single
typo, the warning is not ignored. Example with a typo ("3.13" rather
than "3.12"):

$ ./python -X dev -W 'ignore:The distutils package is deprecated and
slated for removal in Python 3.13. Use setuptools or check PEP 632 for
potential alternatives:DeprecationWarning' -c 'import distutils'
:1: DeprecationWarning: The distutils package is deprecated
and slated for removal in Python 3.12. Use setuptools or check PEP 632
for potential alternatives

The PYTHONWARNINGS has another limitation: you cannot specify a
message if it contains a comma (","). Hopefully, Python doesn't raise
warnings containing comma, right? Well... Just one example:

Lib/distutils/sysconfig.py:554:warnings.warn('SO is
deprecated, use EXT_SUFFIX', DeprecationWarning, 2)

You cannot only ignore the message:

$ PYTHONWARNINGS='ignore:SO is deprecated, use
EXT_SUFFIX:DeprecationWarning' ./python -c 'import sys;
print(sys.warnoptions); print(len(sys.warnoptions))'
Invalid -W option ignored: invalid action: 'use EXT_SUFFIX'
['ignore:SO is deprecated', ' use EXT_SUFFIX:DeprecationWarning']
2

You can only try to use "module" and "lineno" parameters of a warning
filter, which are more fragile and hard to use to use.

Victor


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

[Python-Dev] Re: NamedTemporaryFile and context managers

[Ivan Pozdeev via Python-Dev]

On 08.04.2021 23:31, Ethan Furman wrote:

In issue14243 [1] there are two issues being tracked:

- the difference in opening shared files between posix and Windows
- the behavior of closing the underlying file in the middle of
 NamedTemporaryFile's context management

I'd like to address and get feedback on the context management issue.

```python
from tempfile import NamedTemporaryFile

with NamedTemporaryFile() as fp:
   fp.write(b'some data')
   fp = open(fp.name())
   data = fp.read()

assert data == 'some_data'
```

Occasionally, it is desirable to close and reopen the temporary file in order to read the contents (there are OSes that cannot open a temp 
file for reading while it is still open for writing). This would look like:




What's the problem with `NamedTemporaryFile(mode='w+b')`? (it's actually the 
default!)

You can both read and write without reopening.
If you don't want to seek() between reading and writing, you can dup() the descriptor and wrap it with another file object: 
`fp2=open(os.dup(fp.file.fileno()))`




```python
from tempfile import NamedTemporaryFile

with NamedTemporaryFile() as fp:
   fp.write(b'some data')
   fp.close()  # Windows workaround
   fp.open()
   data = fp.read()

assert data == 'some_data'
```

The problem is that, even though `fp.open()` is still inside the context manager, the `close()` call deletes the file [2].  To handle this 
scenario, my proposal is two-fold:


1) stop using the TEMPFILE OS attribute so the OS doesn't delete the file on 
close
2) add `.open()` to NamedTemporaryFile

A possible side effect of (1) is that temp files may accumulate if the interpreter crashes, but given the file-management abilities in 
today's software that seems like a minor annoyance at most.


The backwards compatibility issue of (1) is that the file is no longer deleted after a manual `close()` -- but why one would call close() 
and then stay inside the CM, outside of testing, I cannot fathom.  [3]


So, opinions on modifying NamedTemporaryFile to not delete on close() if inside 
a CM, and add open() ?

--
~Ethan~


[1] https://bugs.python.org/issue14243
[2] plus, the `.open()` doesn't yet exist
[3] feel free to educate me  :-)
___
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/DZNEIRHZ7LVQNQRQ2JL5B4AOC3HH3B6O/
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/SW4LRGEXYER6HDE3WBIKSQHENQRZLMRP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Ivan Pozdeev via Python-Dev]

On 24.03.2021 19:58, Antoine Pitrou wrote:

On Wed, 24 Mar 2021 19:45:49 +0300
Ivan Pozdeev via Python-Dev  wrote:

How does C++ fare in binary compatibility? Last time I checked it out (about 10 
years ago), there was completely none, every compiler's ABI
was a black box without any guarantees whatsoever.
For any software that's going to dynamically link and exchange binary types 
with other independently produced software, that's a deal breaker.

That depends if you use C++ internally or expose C++ bits in the public
API.
If you only use C++ internally, binary compatibility is presumably less
of an issue.


Python produces and accepts its internal types in API calls and allows extension modules to derive from them -- so it cannot "only use C++ 
internally" if those are going to become C++ types. (And if not, the point of using C++ is unclear.)



Regards

Antoine.


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

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Ivan Pozdeev via Python-Dev]

How does C++ fare in binary compatibility? Last time I checked it out (about 10 years ago), there was completely none, every compiler's ABI 
was a black box without any guarantees whatsoever.

For any software that's going to dynamically link and exchange binary types 
with other independently produced software, that's a deal breaker.

On 24.03.2021 12:54, redrad...@gmail.com wrote:

Hi all,

What about of using modern C++ in developing CPython ?

With C++ we can get the following benefits:
1) Readability - less code, most code is hidden by abstraction without losing 
performance
2) Maintainability - no code duplication in favor of using reusable classes
3) RAII - Resource Acquisition Is Initialization, predictable allocation and 
free resources
...
___
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/SMF4B2SOY6YG5BJCPEUNJVPNESA3MQOW/
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/DRMTE4LZYHDGZXEAAUSD532TZPJKSTAV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Tests now start with only 131 imported modules, instead of 233

[Ivan Pozdeev via Python-Dev]

I didn't quite get what the big effect is. Saving 30 milliseconds?

Also, how is the now-split-off funcionality to be invoked? Does it require two or more imports now, or it's imported on demand when one 
invokes an appropriate test.support entry?


On 23.03.2021 4:29, Victor Stinner wrote:

Hi,

tl;dr Tests of the Python Test Suite now start with 131 imported
modules, instead of 233. For example, asyncio, logging,
multiprocessing and warnings are no longer imported by default.

--

The Python test suite is run by a custom test runner called
"libregrtest" (test.libregrtest). It can detect reference leaks, write
the output as JUnit XML, run tests in parallel with multiple
processes, etc. Tests are written with test.support which is a
collection of helper functions.

Over the years, test.support got more and more functions, and
libregrtest got more and more features. The problem is that they
import more and more modules. For example, "import test.support"
imports 173 modules in Python 3.8!

$ python3.8

import sys, sys
before=set(sys.modules); import test.support; after=set(sys.modules)
len(after - before)

173

In these imports, you can find some "heavy" modules like asyncio and
multiprocessing. Moreover, some modules have "side effects" on import.
For example, "import logging" registers an "at fork" callback.

In April 2020, I worked with Hai Shi on Python 3.10 in bpo-40275 to
reduce the number of test.support imports from 171 to 25! test.support
was splitted into multiple sub-modules:

- bytecode_helper
- hashlib_helper
- import_helper
- logging_helper
- os_helper
- script_helper
- socket_helper
- threading_helper
- warnings_helper

I continued the work in bpo-41718 to reduce the number of libregrtest
imports, since libregrtest also imported many modules.

A dummy test which does nothing in the master branch now only has 131
modules in sys.modules, whereas in Python 3.9 it has 233 (+102)
modules! For example, asyncio, logging, multiprocessing and warnings
are no longer imported by default.

"import test.support" is now faster. master branch compared to Python
3.8 using ./python -c 'import test.support' command and Python built
in release mode:

[py38] 85.7 ms +- 6.8 ms -> [master] 32.4 ms +- 1.3 ms: 2.64x faster

More realistic command running a single test method: ./python -m test
test_os -m test_access

[py38] 136 ms +- 5 ms -> [master] 97.8 ms +- 2.4 ms: 1.39x faster

The only annoying point is that splitting test.support into
sub-modules was not backported to Python 3.8 and 3.9, and so it will
make backports a little bit more annoying. Sorry about that!

--

If you know that two modules should be tested together, please write a
dedicated test for that ;-)

Victor


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

[Python-Dev] Re: pth file encoding

[Ivan Pozdeev via Python-Dev]

On 17.03.2021 23:04, Steve Dower wrote:

On 3/17/2021 7:34 PM, Ivan Pozdeev via Python-Dev wrote:

On 17.03.2021 20:30, Steve Dower wrote:

On 3/17/2021 8:00 AM, Michał Górny wrote:

How about writing paths as bytestrings in the long term?  I think this
should eliminate the necessity of knowing the correct encoding for
the filesystem.


That's what we're trying to do, the problem is that they start as strings, and 
so we need to convert them to a bytestring.

That conversion is the encoding ;)

And yeah, for reading, I'd use a UTF-8 reader that falls back to locale on failure (and restarts reading the file). But for writing, we 
need the tools that create these files (including Notepad!) to use the encoding we want.




I don't see a problem with using a file encoding specification like in Python 
source files.
Since site.py is under our control, we can introduce it easily.

We can opt to allow only UTF-8 here -- then we wait out a transitional period and disallow anything else than UTF-8 (then the 
specification can be removed, too).


The only thing we can introduce *easily* is an error when the (exclusively third-party) tools that create them aren't up to date. Getting 
everyone to specify the encoding we want is a much bigger problem with a much slower solution.


I don't see a problem with either.
If we want to standardize something, we have to encourage, then ultimately 
enforce compliance, this way or another.



This particular file is probably the worst case scenario, but preferring UTF-8 and handling existing files with a fallback is the best we 
can do (especially since an assumption of UTF-8 can be invalidated on a particular file, whereas most locale encodings cannot). Once we 
openly document that it should be UTF-8, tools will have a chance to catch up, and eventually the fallback will become harmless.


Cheers,
Steve


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

[Python-Dev] Re: pth file encoding

[Ivan Pozdeev via Python-Dev]

On 17.03.2021 20:30, Steve Dower wrote:

On 3/17/2021 8:00 AM, Michał Górny wrote:

How about writing paths as bytestrings in the long term?  I think this
should eliminate the necessity of knowing the correct encoding for
the filesystem.


That's what we're trying to do, the problem is that they start as strings, and 
so we need to convert them to a bytestring.

That conversion is the encoding ;)

And yeah, for reading, I'd use a UTF-8 reader that falls back to locale on failure (and restarts reading the file). But for writing, we 
need the tools that create these files (including Notepad!) to use the encoding we want.




I don't see a problem with using a file encoding specification like in Python 
source files.
Since site.py is under our control, we can introduce it easily.

We can opt to allow only UTF-8 here -- then we wait out a transitional period and disallow anything else than UTF-8 (then the specification 
can be removed, too).



Cheers,
Steve

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

[Python-Dev] Re: New name for the development branch [was Steering Council update for February]

[Ivan Pozdeev via Python-Dev]

I think https://mail.python.org/archives/list/python-dev@python.org/message/GDAUZKYB6GP3A3ZGBSQ4KQ7R6QFIZHZC/ and 
https://mail.python.org/archives/list/python-dev@python.org/message/RE3V6Y7CPHOL6LGPPYSVS3XQFTIQRZ3J/ already explained the reasons in 
sufficient detail -- that "main" is a politically correct replacement for "master" and is supposed to take over as the default branch name 
in Git.


I'm against using a nonstandard default branch name because I have firsthand experience with one (in the Multibuild project) and it was 
really confusing.


On 10.03.2021 13:36, Mark Shannon wrote:

Hi,

Why choose "main" as a replacement for "master"?
It's the development branch, shouldn't we call it "development" or "dev"?

We give release branches meaningful names, so why give the development branch the 
not-so-meaningful name "main".
From a user's perspective the "main" branch is whatever their version of Python 
is built from.

Cheers,
Mark.
___
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/HRHPZSNZ7INSK2NLE6LNYMMP767AIVRT/
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/FKM4TPW3QXJJVZFWQ6C3IVMBXHYH6W45/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Steering Council update for February

[Ivan Pozdeev via Python-Dev]

On 10.03.2021 3:53, Chris Angelico wrote:

On Wed, Mar 10, 2021 at 11:47 AM Damian Shaw
 wrote:

Does 'master' confuse people?

There's a general movement to replace language from common programming 
practises that derive from, or are associated with, the dehumanization of 
people. Such as master and slave, as well as whitelist and blacklist.


Is that *actually* the origin of the term in this context, or is it
the "master", the pristine, the original from which copies are made?
There's no "slave" branch anywhere in the git repository.


It is, actually, the ultimate origin of the term.

A more immediate origin is the master-slave architecture (the master agent initiates some operation and slave agents respond to it and/or 
carry it out).



Anyway, this is yet another SJW non-issue (countries other than US don't have a modern history of slavery) so this change is a political 
statement rather than has any technical merit.




I detest these changes that create churn and don't actually solve any
problems. They allow people to feel good about themselves for having
"made a change", while actually making no useful change whatsoever
(are disadvantaged people's lives going to be improved by this
rename?). What next? Are we going to crack down on any courses that
proclaim to help you to "master the Python language"? Does that, too,
have to be renamed?

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

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

[Ivan Pozdeev via Python-Dev]

 * In https://www.python.org/dev/peps/pep-0654/#programming-without-except, the 
natural way isn't shown:

try:
    
except (MultiError, ValueError) as e:
    def _handle(e):
    if isinstance(e, ValueError):
        return None
    else:
    return exc
    MultiError.filter(_handle,e)

So a statement that the current handling is "cumbersome" and "unintuitive" is 
unconvincing.

If this results in lots of boilerplate code with isinstance(), filter() can be changed to e.g. accept a dict of exception types and 
handlers. Actually, I wonder why you didn't do that already if handling specific exception types and reraising the rest is the standard 
procedure!

Then the code would be reduced to:

try:
    
except (MultiError, ValueError) as e:
    MultiError.filter({ValueError: lambda _: None},
  e)


 * https://github.com/python-trio/trio/issues/611 says that it somehow causes 
problems with 3rd-party libraries -- but there's no
   explanation how -- either there or in the PEP.

If some code doesn't know about MultiError's, it should handle one like any other unknown exception that it cannot do anything intelligent 
about.
If it wishes to handle them, you need to split MultiError into a separate library that anyone could use without having to pull the entire 
`trio`.



On 23.02.2021 3:24, Irit Katriel via Python-Dev 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/L5Q27DVKOKZCDNCAWRIQVOZ5DZCZHLRM/
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/DY7BGNVB6GBYSDBLL3IVZQ7GWYEQCEI5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Maintenance burdem from unresolved process issues (was: Re: Re: Move support of legacy platforms/architectures outside Python)

[Ivan Pozdeev via Python-Dev]

This, and an earlier letter about the burned of a release manager, confirmes my suspicion that a large share of "maintenance burden" comes 
from unresolved process issues.


E.g. looks like Victor had been unconvinced that unreliable tests are a serious issue and cost the team so much (including himself since 
they cause ppl to ignore his buildbot issue reports right back) and had blocked the effort to disable them or whatnot (this is just my guess 
but Terry's message suggests that he was against resolving it).


I hope this convinces him and will let the team clear this issue at last!

Likewise, half of the bullet points in https://mail.python.org/archives/list/python-dev@python.org/message/LJ3E2UQBPDSFEH7ULNF3QVOYEQYRSAGI/ 
comes from either ppl trying to bypass the process, or the release manager doing others' jobs that should've already been done had the 
process been followed.


On 22.02.2021 19:48, Terry Reedy wrote:

On 2/22/2021 6:20 AM, Victor Stinner wrote:


To have an idea of the existing maintenance burden, look at emails sent to:
https://mail.python.org/archives/list/buildbot-sta...@python.org/

Every single email is basically a problem. There are around 110 emails
over the last 30 years:


30 days, not years.  The 20 visible messages are all have title f"Buildbot worker {worker} missing".  All the messages on a day are sent 
at the same time.  Replace with a daily "Builbot workers currently missing"?  The individual messages seem useless except possibly if sent 
to individual buildbot owners.

...

Multiple buildbots are "unstable": tests are failing randomly. Again,
each failure means a new email. For example, test_asyncio likes to
fail once every 10 runs (coarse average, I didn't check exactly).


I strongly feel that the individual repeatedly failing tests (only 3 or 4 I think) should be disabled and the asyncio people notified.  As 
I remember, you once insisted on keeping routinely failing tests.



By the way, these random failures are not only affecting buildbots,
but also CIs run on pull requests. It's *common* that these failures
prevent to merge a pull request and require manual actions to be able
to merge the PR (usually, re-run all CIs).


For backports, it means closing the backport and reopening by re-adding a backport label to the master PR.  This is why I really really 
want the repeatedly failing tests disabled.




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

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

[Ivan Pozdeev via Python-Dev]

IIRC I suggested earlier that buildsbots should be integrated into the PR workflow in order to make it the contributor's rather than a core 
dev's burden to fix any breakages that result from their changes.


On 22.02.2021 14:20, Victor Stinner wrote:

On Sun, Feb 21, 2021 at 8:57 PM Michał Górny  wrote:

The checker serves two purposes:

1) It gives users an opportunity to provide full PEP 11 support
(buildbot, engineering time) for a platform.

Does that mean that if someone offers to run the build bot for a minor
platform and do the necessary maintenance to keep it working, they will
be able to stay?  How much maintenance is actually expected, i.e. is it
sufficient to maintain CPython in a 'good enough' working state to
resolve major bugs blocking real usage on these platforms?

Maintaining a buildbot doesn't mean to look at it every 6 months. It
means getting emails multiple times per month about real bug which
must be fixed. My main annoyance is that every single buildbot failure
sends me an email, and I'm overwhelmed by emails (I'm not only getting
emails from buildbots ;-)).

Python has already a long list of buildbot workers (between 75 and
100, I'm not sure of the exact number) and they require a lot of
attention. Over the last 5 years, there is basically only Pablo
Galindo and me who pay attention to them.

I fear that if more buildbots are added, Pablo and me will be the only
ones to look at ones. FYI if nobody looks at buildbots, they are
basically useless. They only waste resources.

To have an idea of the existing maintenance burden, look at emails sent to:
https://mail.python.org/archives/list/buildbot-sta...@python.org/

Every single email is basically a problem. There are around 110 emails
over the last 30 years: 3.6 email/day in average. When a bug is
identified, it requires an investigation which takes between 5 minutes
and 6 months depending on the bug. I would say 2 hours in average.
Sometimes, if the investigation is too long, we simply revert the
change.

The buildbot configuration also requires maintenance. For example, 14
commits have been pushed since January 1st:
https://github.com/python/buildmaster-config/commits/master

Multiple buildbots are "unstable": tests are failing randomly. Again,
each failure means a new email. For example, test_asyncio likes to
fail once every 10 runs (coarse average, I didn't check exactly).
multiprocessing tests, tests using network like imaplib or nntplib,
and some other tests fail randomly. Some tests just fail because just
once, the buildbot became slower.

People have many ideas to automate bug triage from emails, but so far,
nobody came with a concrete working solution, and so emails are still
read manually one by one. Also, almost nobody is trying to fix tests
which are failing randomly.

For example, I called multiple times for help to fix test_asyncio, so
far it's still randomly every day:

* 2020: 
https://mail.python.org/archives/list/python-dev@python.org/message/Y7I5ADXAQEGK6DOFAPVDTKMBT6NUFNQ4/
* 2019: 
https://mail.python.org/archives/list/python-dev@python.org/message/R7X6NKGEOKWD3PBWIL2LPZWZ6MMRANN5/

By the way, these random failures are not only affecting buildbots,
but also CIs run on pull requests. It's *common* that these failures
prevent to merge a pull request and require manual actions to be able
to merge the PR (usually, re-run all CIs).

I'm not talking about exotic platforms with very slow hardware, but
platorms like Linux/x86-64 with "fast" hardware.

I expect more random errors on exotic platforms. For example, I
reported a crash on AIX one year ago, and nobody fixed it so far. I
pushed a few fixes for that crash, but it's not enough to fully fix
it:
https://bugs.python.org/issue40068

I pushed AIX fixes only because I was annoyed by getting buildbot
emails about AIX failures. Sometimes, I just turn off emails from AIX.

Since there is no proactive work on fixing AIX issues, I would even
prefer to *remove* the AIX buildbots.

Victor


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

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

[Ivan Pozdeev via Python-Dev]

On 22.02.2021 11:20, Michał Górny wrote:

On Sun, 2021-02-21 at 13:04 -0800, Gregory P. Smith wrote:

The main thing from a project maintenance perspective is for platforms
to
not become a burden to other code maintainers.  PRs need to be
reviewed.
Every #if/#endif in code is a cognitive burden.  So being a minor
platform
can come with unexpected breakages that need fixing due to other
changes
made in the codebase that did not pay attention to the platform.  As
we
cannot expect everyone working on code to care about anything beyond
the
tier-1 fully supported platforms, buildbot or not.


I have to disagree -- the support code (even if any is actually
necessary) does not have to be a burden.  Generally 'hobbyists' don't
have a problem that the support for their platform becomes broken
accidentally, or even deliberately because it blocks something else.
They understand that others don't have hardware, time or motivation
to maintain support for their platform properly.

They themselves have limited time to work on it.  So it's entirely fine
for things to break occasionally, and they provide fixes as their time
permits.  They don't ask others to maintain their code.  There's no real
maintenance burden involved.


But there is. As was pointed to above, the extra legacy code makes making _any_ changes in the corresponding part of the file more difficult 
-- because one has to think how to combine the changes with that code.
E.g.: at which side of that code to place the changes; if it's a part of a block statement, where in the block statement to place the 
changes; if I want to change the program structure, how to incorporate that code into the new structure -- all made much more difficult 
because I cannot be sure what changes would and wouldn't break the "legacy" code.
So, by your logic, it would be "blocking" any change to that file and will have to be removed anyway the first time we change that file. 
Now, if that's the case -- why should  we spent time and effort tracking which files were "cleansed" and which weren't (which we'll have to 
do because such cleansing is an unrelated change in a PR so a PR's author should know whether they need to look out to do any "cleansing" as 
well as making the change that does what they want) if we can cleanse them all at once and be done with it?




In fact, this whole thread feels like removing 80%-complete translations
from a program because they 'burden developers' and confuse users.  Even
if the translations are not actively updated and degenerates with
strings changing, some users find them helpful.


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

[Python-Dev] Re: PEP 597 bikeshedding: envvar / option name.

[Ivan Pozdeev via Python-Dev]

I see plenty of envvars with similarly long names at 
https://docs.python.org/3/using/cmdline.html .

So your initial name "PYTHONWARNDEFAULTENCODING" LGTM.

The first intuitive choice is often the right one ('cuz it's, well, intuitive).

On 15.02.2021 8:28, Inada Naoki wrote:

I am updating PEP 597 to include discussions in the thread.
Before finishing the PEP, I need to decide the option name.

I used PYTHONWARNDEFAULTENCODING (envvar name) /
warn_default_encoding (-X option and sys.flags name) before, but it
seems too long and hard to type, easy to misspell.

Currently, I use PYTHONWARNENCODING / warn_encoding, but it is not so explicit.

Which name is the best balance between explicitness and readability?

* PYTHONWARNENCODING / warn_ecoding
* PYTHONWARNOMITENCODING / warn_omit_encoding
* PYTHONWARNDEFAULTENCODING / warn_default_encoding
* Anything else

Regards,


--
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/2T2O2CNK4CQ67G4MZ2BT5KS26EWQEMY4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Ivan Pozdeev via Python-Dev]

How a standard by ANSI, ECMA and/or ISO is any better than a standard by the 
PSF?

Is PSF bad at "controlling its growth and avoiding featuritis" in your opinion 
or smth?

On 12.02.2021 21:33, 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/


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

[Python-Dev] Re: Change windows installation program name

[Ivan Pozdeev via Python-Dev]

You want to make a poll or something?

Discourse can do that: https://meta.discourse.org/t/how-to-create-polls/77548

On 08.02.2021 23:07, Barry Scott wrote:

I raise https://bugs.python.org/issue43156 that suggests that
new users on windows would be less confused if the name of the
installation program did not seem to imply it was the python program.

In a nutshell the proposal is to change from this:

   python-3.10.0a5.exe
   python-3.10.0a5-amd64.exe

to this (thanks to Matthew Barnett for the improved names:

   python-3.10.0a5-win32-setup.exe
   python-3.10.0a5-win64-setup.exe

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

[Python-Dev] Re: Concerns about PEP 634

[Ivan Pozdeev via Python-Dev]

On 07.02.2021 0:24, Paul Sokolovsky wrote:

Hello,

On Sun, 7 Feb 2021 00:00:41 +0300
Ivan Pozdeev via Python-Dev  wrote:


Who said "__future__"?

Other people said __future__. And yet other said "it's ok the way it
is, it's better to have it like that then keep not having it". And yet
other said something else (multiple else's).


I said "3rd-party library". Independent from
the CPython project. Maybe even a few of them -- to try out
conflicting visions that emerged in the discussions.

Such libraries exist for decade(s). MacroPy is a venerable, well-known
macro-capabilities-for-Python solution, which offers a kind of pattern
matching: https://macropy3.readthedocs.io/en/latest/pattern.html .
There're a bunch of other, grep github.

https://github.com/MegaIng/syntax-extensions-pep634 specifically
advertises itself as pure-Python implementation of PEP634 (using a
newer macro library), though I'm not sure how well it's development.
It also of course represents the right way to develop Python - in
Python itself. Sadly, "C" in "CPython" is stuck too deep in many
minds...


Bottom line is however: given the decade(s) old history of pattern
matching in *Python* (usual warning: don't mix up Python and CPython!),
arguing that very resourceful attempt to add pattern matching to the
reference implementation (that's where *CPython* finally pops up),
should be flushed down the toilet and the Python community should be
brought back into decade-long waiting state without a reference
implementation for pattern matching - umm, suggesting that doesn't seem
to be very productive.


That's not the impression I got from looking through the discussiuon and the 
PEP.

I don't see references to any of those existing implementations anywhere in the PEP as well as a summary of various existing approaches and 
solutions, their pros and cons etc. which the proposal proper would derive its particulars from.

Both the PEPs and the discussion look like they are trying to write the 
functionality completely from sctratch, by the seat of their pants.

And from how much discord there is about syntax and semantics, I conclude that these are far from being well-established and 
practice-proven. So if the existing solutions really have a "decades-long history" as you claim, that history must be spectacularly 
uneventful -- which suggests that the feature is either in low demand or was ultimately proven by practice to be inadequate for real-world use.






On 06.02.2021 23:58, Steve Holden wrote:

My suggestion that it be introduced via __future__ due to its
contentious nature met immediate resistance. No point going down
that road.

Kind regards,
Steve


On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev
mailto:python-dev@python.org>> wrote:

 With such a large new area of functionality that's at odds with
existing syntax and semantics and a lack of clear vision and
agreement, it sounds like this would be better first added as a
3rd-party library to let the syntax and semantics mature. (To allow
new syntax, it'll probably be parsing strings in that special
syntax.)

 (At https://www.python.org/dev/peps/pep-0634/
<https://www.python.org/dev/peps/pep-0634/>, there's no indication
that this option was considered.)


[]


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

[Python-Dev] Re: Concerns about PEP 634

[Ivan Pozdeev via Python-Dev]

Who said "__future__"? I said "3rd-party library". Independent from the CPython 
project.
Maybe even a few of them -- to try out conflicting visions that emerged in the 
discussions.

On 06.02.2021 23:58, Steve Holden wrote:

My suggestion that it be introduced via __future__ due to its contentious 
nature met immediate resistance. No point going down that road.

Kind regards,
Steve


On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> wrote:

With such a large new area of functionality that's at odds with existing 
syntax and semantics and a lack of clear vision and
agreement, it
sounds like this would be better first added as a 3rd-party library to let 
the syntax and semantics mature. (To allow new syntax, it'll
probably be parsing strings in that special syntax.)

(At https://www.python.org/dev/peps/pep-0634/ 
<https://www.python.org/dev/peps/pep-0634/>, there's no indication that this 
option was
considered.)

On 06.02.2021 18:44, Mark Shannon wrote:
> Hi,
>
> Since a decision on PEP 634 is imminent, I'd like to reiterate some 
concerns that I voiced last year.
>
> I am worried about the semantics and implementation of PEP 634.
> I don't want to comment on the merits of pattern matching in general, or 
the proposed syntax in PEP 634 (or PEP 640 or PEP 642).
>
> Semantics
> -
>
> 1. PEP 634 eschews the object model, in favour of adhoc instance checks, 
length checks and attribute accesses.
>
> This is in contrast to almost all of the the rest of the language, which 
uses special (dunder) methods:
>   All operators,
>   subscripting,
>   attribute lookup,
>   iteration,
>   calls,
>   tests,
>   object creation,
>   conversions,
>   and the with statement
>
> AFAICT, no justification is given for this.
> Why can't pattern matching use the object model?
>
> PEP 343 (the "with" statement) added the __enter__ and __exit__ methods 
to the object model, and that works very well.
>
>
> 2. PEP 634 deliberately introduces a large area of undefined behaviour 
into Python.
>
> 
https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior

<https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior>
>
> Python has, in general, been strict about not having undefined behaviour.
> Having defined semantics means that you can reason about programs, even 
non-idiomatic ones.
> [This is not unique to Python, it is really only C and C++ that have 
areas of undefined behaviour]
>
> I can see no good reason for adding undefined behaviour. It doesn't help 
anyone.
>
> The lack of precise semantics makes programs harder to understand, and it 
makes the language harder to implement.
> If the semantics aren't specified, then the implementation becomes the 
specification.
> This bakes bugs into the language and makes it harder to maintain,
> as bug-for-bug compatibility must be maintained.
>
>
> 3. Performance
>
> PEP 634 says that each pattern must be checked in turn.
> That means that multiple redundant checks must be performed on (for 
example) a sequence if there are several mapping patterns.
> This is unnecessarily slow.
>
>
> Implementation
> --
>
> My main concern with the implementation is that it does too much work 
into the interpreter.
> Much of that work can and should be done in the compiler.
> For example, deep in the implementation of the MATCH_CLASS instruction is 
the following comment:
> https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981
<https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981>
>
> Such complex control flow should be handled during compilation, rather 
than in the interpreter.
> Giant instructions like MATCH_CLASS are likely to have odd corner cases,
> and may well have a negative impact on the performance of the rest of the 
language.
> It is a lot easier to reason about a sequence of simple bytecodes, than 
one giant one with context-dependent behaviour.
>
> We have spent quite a lot of effort over the last few years streamlining 
the interpreter.
> Adding these extremely complex instructions would be a big backward step.
>
>
> Cheers,
> Mark.
> ___
> Python-Dev mailing list -- python-dev@python.org 
<mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-le...@python.org 
<mailto:pyth

[Python-Dev] Re: Concerns about PEP 634

[Ivan Pozdeev via Python-Dev]

With such a large new area of functionality that's at odds with existing syntax and semantics and a lack of clear vision and agreement, it 
sounds like this would be better first added as a 3rd-party library to let the syntax and semantics mature. (To allow new syntax, it'll 
probably be parsing strings in that special syntax.)


(At https://www.python.org/dev/peps/pep-0634/, there's no indication that this 
option was considered.)

On 06.02.2021 18:44, Mark Shannon wrote:

Hi,

Since a decision on PEP 634 is imminent, I'd like to reiterate some concerns 
that I voiced last year.

I am worried about the semantics and implementation of PEP 634.
I don't want to comment on the merits of pattern matching in general, or the 
proposed syntax in PEP 634 (or PEP 640 or PEP 642).

Semantics
-

1. PEP 634 eschews the object model, in favour of adhoc instance checks, length 
checks and attribute accesses.

This is in contrast to almost all of the the rest of the language, which uses 
special (dunder) methods:
  All operators,
  subscripting,
  attribute lookup,
  iteration,
  calls,
  tests,
  object creation,
  conversions,
  and the with statement

AFAICT, no justification is given for this.
Why can't pattern matching use the object model?

PEP 343 (the "with" statement) added the __enter__ and __exit__ methods to the 
object model, and that works very well.


2. PEP 634 deliberately introduces a large area of undefined behaviour into 
Python.

https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior

Python has, in general, been strict about not having undefined behaviour.
Having defined semantics means that you can reason about programs, even 
non-idiomatic ones.
[This is not unique to Python, it is really only C and C++ that have areas of 
undefined behaviour]

I can see no good reason for adding undefined behaviour. It doesn't help anyone.

The lack of precise semantics makes programs harder to understand, and it makes 
the language harder to implement.
If the semantics aren't specified, then the implementation becomes the 
specification.
This bakes bugs into the language and makes it harder to maintain,
as bug-for-bug compatibility must be maintained.


3. Performance

PEP 634 says that each pattern must be checked in turn.
That means that multiple redundant checks must be performed on (for example) a 
sequence if there are several mapping patterns.
This is unnecessarily slow.


Implementation
--

My main concern with the implementation is that it does too much work into the 
interpreter.
Much of that work can and should be done in the compiler.
For example, deep in the implementation of the MATCH_CLASS instruction is the 
following comment:
https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981

Such complex control flow should be handled during compilation, rather than in 
the interpreter.
Giant instructions like MATCH_CLASS are likely to have odd corner cases,
and may well have a negative impact on the performance of the rest of the 
language.
It is a lot easier to reason about a sequence of simple bytecodes, than one 
giant one with context-dependent behaviour.

We have spent quite a lot of effort over the last few years streamlining the 
interpreter.
Adding these extremely complex instructions would be a big backward step.


Cheers,
Mark.
___
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/HC6XDUASX2EELTA4L5R73BSYNJPTAYNL/
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/OGXG4TIZQ35QGZ23JNAP4OAGEEW4COUK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ivan Pozdeev via Python-Dev]

On 29.01.2021 20:15, Victor Stinner wrote:

Hi Mark,

I tried to use C11 _Thread_local (Thread Local Storage, TLS) only with
GCC and clang and I got issues on macOS:
https://github.com/python/cpython/pull/23976

My PR uses __thread if _Thread_local is not available.

I don't think that MSC (Visual Studio) implements C11 _Thread_local,
but it provides __declspec(thread). I tried it and I got issues with
DLL. I didn't dig into this issue. MSC loves C++ but seems stuck at
C99 (I'm not even sure if it's fully implemented).


According to https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-160#c-standards-support-1 
and https://docs.microsoft.com/en-us/cpp/overview/install-c17-support?view=msvc-160 , they only partially support C99, and C11 and C17 
support is available in the Insider Preview version.
The preview version supports all the required but no optional features (including optional features that were required in C99) and suggest 
to use features test macros.

They also say that the 2 standard modes are functonally equivalent except the 
version macro since C17 is a bugfix release.

AFAICS, this means that global C99 requirement is out of the question; C11/C17 can be considered when that MSVC version is released -- but 
alternative solutions are still needed for code chunks using optional features.





It seems like declaring a TLS in libpython and using it from an
extension module (another dynamic library) is causing issues depending
on the linker. It "should" work on macOS, but it doesn't.

See https://bugs.python.org/issue40522 for the produced machine code
on x86-64. In short, it's usually a single MOV using the FS register
(two MOV in the worst case).

Victor

On Thu, Jan 28, 2021 at 5:29 PM Mark Shannon  wrote:

Hi everyone,

PEP 7 says that C code should conform to C89 with a subset of C99 allowed.
It's 2021 and all the major compilers support C11 (ignoring the optional
parts).

C11 has support for thread locals, static asserts, and anonymous structs
and unions. All useful features.

Is there a good reason not to start using C11 now?

Cheers,
Mark.


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

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

[Ivan Pozdeev via Python-Dev]

Fortunately for, you :) , all this argument is not against the feature per se but only against its use to blindly filter module lists for 
automated bug reports.


On 26.01.2021 1:34, Victor Stinner wrote:

On Mon, Jan 25, 2021 at 11:22 PM Ivan Pozdeev via Python-Dev
 wrote:

That's not possible.

Stdlib can be arranged any way a user/maintainer wishes (zipped stdlib and virtual 
environments are just two examples), so there's no way to tell if the module's location 
is "right".
Dowstream changes are also standard practice so there's no way to verify a 
module's contents, either.

As such, there's no way to tell if any given module being imported is a 
standard or a 3rd-party one.

By the way, IMO it's also a legit use case on an old Python version to
override a stdlib module with a patched or more recent version, to get
a bugfix for example ;-) Even if it's an uncommon use case, it can
solve some practical issues.

Victor


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

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

[Ivan Pozdeev via Python-Dev]

That's not possible.

Stdlib can be arranged any way a user/maintainer wishes (zipped stdlib and virtual environments are just two examples), so there's no way to 
tell if the module's location is "right".

Dowstream changes are also standard practice so there's no way to verify a 
module's contents, either.

As such, there's no way to tell if any given module being imported is a 
standard or a 3rd-party one.

On 25.01.2021 20:33, Chris Jerdonek wrote:

On Mon, Jan 25, 2021 at 7:51 AM Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> wrote:

Just _names_? There's a recurring error case when a 3rd-party module 
overrides a standard one if it happens to have the same name. If you
filter such a module out, you're shooting yourself in the foot...


Would another use case be to support issuing a warning if a third-party module is imported whose name matches a standard one? A related 
use case would be to build on this and define a function that accepts an already imported module and return whether it is from the 
standard library. Unlike, the module_names attribute, this function would reflect the reality of the underlying module, and so not have 
false positives as with doing a name check alone.


—Chris




On 25.01.2021 16:03, Victor Stinner wrote:
> Hi,
>
> I just added a new sys.module_names attribute, list (technically a
> frozenset) of all stdlib module names:
> https://bugs.python.org/issue42955 <https://bugs.python.org/issue42955>
>
> There are multiple use cases:
>
> * Group stdlib imports when reformatting a Python file,
> * Exclude stdlib imports when computing dependencies.
> * Exclude stdlib modules when listing extension modules on crash or
> fatal error, only list 3rd party extension (already implemented in
> master, see bpo-42923 ;-)).
> * Exclude stdlib modules when tracing the execution of a program using
> the trace module.
> * Detect typo and suggest a fix: ImportError("No module named maths.
> Did you mean 'math'?",) (test the nice friendly-traceback project!).
>
> Example:
>
>>>> 'asyncio' in sys.module_names
> True
>>>> 'numpy' in sys.module_names
> False
>
>>>> len(sys.module_names)
> 312
>>>> type(sys.module_names)
> 
>
>>>> sorted(sys.module_names)[:10]
> ['__future__', '_abc', '_aix_support', '_ast', '_asyncio', '_bisect',
> '_blake2', '_bootsubprocess', '_bz2', '_codecs']
>>>> sorted(sys.module_names)[-10:]
> ['xml.dom', 'xml.etree', 'xml.parsers', 'xml.sax', 'xmlrpc', 'zipapp',
> 'zipfile', 'zipimport', 'zlib', 'zoneinfo']
>
> The list is opinionated and defined by its documentation:
>
>     A frozenset of strings containing the names of standard library
>     modules.
>
>     It is the same on all platforms. Modules which are not available on
>     some platforms and modules disabled at Python build are also listed.
>     All module kinds are listed: pure Python, built-in, frozen and
>     extension modules. Test modules are excluded.
>
>     For packages, only sub-packages are listed, not sub-modules. For
>     example, ``concurrent`` package and ``concurrent.futures``
>     sub-package are listed, but not ``concurrent.futures.base``
>     sub-module.
>
>     See also the :attr:`sys.builtin_module_names` list.
>
> The design (especially, the fact of having the same list on all
> platforms) comes from the use cases list above. For example, running
> isort should produce the same output on any platform, and not depend
> if the Python stdlib was splitted into multiple packages on Linux
> (which is done by most popular Linux distributions).
>
> The list is generated by the Tools/scripts/generate_module_names.py 
script:
> 
https://github.com/python/cpython/blob/master/Tools/scripts/generate_module_names.py

<https://github.com/python/cpython/blob/master/Tools/scripts/generate_module_names.py>
>
> When you add a new module, you must run "make regen-module-names,
> otherwise a pre-commit check will fail on your PR ;-) The list of
> Windows extensions is currently hardcoded in the script (contributions
> are welcomed to discover them, since the list is short and evolves
> rarely, I didn't feel the need to spend time that on that).
>
> Currently (Python 3.10.0a4+), there are 312 names in sys.module_names,
> stored in Python/module_names.h:
> https://github.com/python/cpython/blob/master/Python/module_names.h
<https://github.com/python/cpython/blob/master/Py

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

[Ivan Pozdeev via Python-Dev]

Just _names_? There's a recurring error case when a 3rd-party module overrides a standard one if it happens to have the same name. If you 
filter such a module out, you're shooting yourself in the foot...


On 25.01.2021 16:03, Victor Stinner wrote:

Hi,

I just added a new sys.module_names attribute, list (technically a
frozenset) of all stdlib module names:
https://bugs.python.org/issue42955

There are multiple use cases:

* Group stdlib imports when reformatting a Python file,
* Exclude stdlib imports when computing dependencies.
* Exclude stdlib modules when listing extension modules on crash or
fatal error, only list 3rd party extension (already implemented in
master, see bpo-42923 ;-)).
* Exclude stdlib modules when tracing the execution of a program using
the trace module.
* Detect typo and suggest a fix: ImportError("No module named maths.
Did you mean 'math'?",) (test the nice friendly-traceback project!).

Example:


'asyncio' in sys.module_names

True

'numpy' in sys.module_names

False


len(sys.module_names)

312

type(sys.module_names)




sorted(sys.module_names)[:10]

['__future__', '_abc', '_aix_support', '_ast', '_asyncio', '_bisect',
'_blake2', '_bootsubprocess', '_bz2', '_codecs']

sorted(sys.module_names)[-10:]

['xml.dom', 'xml.etree', 'xml.parsers', 'xml.sax', 'xmlrpc', 'zipapp',
'zipfile', 'zipimport', 'zlib', 'zoneinfo']

The list is opinionated and defined by its documentation:

A frozenset of strings containing the names of standard library
modules.

It is the same on all platforms. Modules which are not available on
some platforms and modules disabled at Python build are also listed.
All module kinds are listed: pure Python, built-in, frozen and
extension modules. Test modules are excluded.

For packages, only sub-packages are listed, not sub-modules. For
example, ``concurrent`` package and ``concurrent.futures``
sub-package are listed, but not ``concurrent.futures.base``
sub-module.

See also the :attr:`sys.builtin_module_names` list.

The design (especially, the fact of having the same list on all
platforms) comes from the use cases list above. For example, running
isort should produce the same output on any platform, and not depend
if the Python stdlib was splitted into multiple packages on Linux
(which is done by most popular Linux distributions).

The list is generated by the Tools/scripts/generate_module_names.py script:
https://github.com/python/cpython/blob/master/Tools/scripts/generate_module_names.py

When you add a new module, you must run "make regen-module-names,
otherwise a pre-commit check will fail on your PR ;-) The list of
Windows extensions is currently hardcoded in the script (contributions
are welcomed to discover them, since the list is short and evolves
rarely, I didn't feel the need to spend time that on that).

Currently (Python 3.10.0a4+), there are 312 names in sys.module_names,
stored in Python/module_names.h:
https://github.com/python/cpython/blob/master/Python/module_names.h

It was decided to include "helper" modules like "_aix_support" which
is used by sysconfig. But test modules like _testcapi are excluded to
make the list shorter (it's rare to run the CPython test suite outside
Python).

There are 83 private modules, name starting with an underscore
(exclude _abc but also __future__):


len([name for name in sys.module_names if not name.startswith('_')])

229

This new attribute may help to define "what is the Python stdlib" ;-)

Victor


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

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Ivan Pozdeev via Python-Dev]

On 13.01.2021 3:12, Senthil Kumaran wrote:

On Wed, Jan 13, 2021 at 02:53:30AM +0300, Ivan Pozdeev via Python-Dev wrote:

I support keeping same Sphinx version across all the supported python versions.

This is not a sustainable route since this way, there's no way to change the 
version at all.


By supported, I mean the active versions that we backport patches to.
Same as what Victor said.


That's what I meant, too.

E.g. when 3.11 comes out and 3.8 is EOL, it will still have to stick with the 
old sphinx because 3.9 and 3.10 do -- and so on ad infinum.




--
Senthil


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

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Ivan Pozdeev via Python-Dev]

On 13.01.2021 2:47, Senthil Kumaran wrote:

On Wed, Jan 13, 2021 at 12:28:42AM +0100, Victor Stinner wrote:


The alternative is to keep Sphinx 2 support, use
strip_signature_backslash and don't use :no-trim-doctest-flags: ?

+1. :no-trim-doctest-flags: was introduced to python docs only recently, so not
using that is a reasonable suggestion.

I support keeping same Sphinx version across all the supported python versions.


This is not a sustainable route since this way, there's no way to change the 
version at all.



--
Senthil
___
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/HS2OYF7QMSOEQDDYTXGEA7HRQDCYF6X6/
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/36DN32A233MURV5AECCPO2WUXLLJFGFA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Need help with python

[Ivan Pozdeev via Python-Dev]

This mailing list is for the development _of_ the Python language and its 
CPython implementation.

Please consult other resources for help with using or learning Python.

On 01.01.2021 11:58, hadi esmaeely wrote:

hi my name is hadi
i'm from iran (the country which filtering others and  be filtered by others)
i have started programming with python about 3 months and i'm very interested in learning programming and python language but duo to 
limitations of technologies and filtering the learning sources in my country i can not find proper source for learning programming(we can 
use vpn for some of websites but not effective enough). Because of that I must learn and  work in another country (In my country, 
programmers are not valued). I am very interested in learning and immigrating to the Netherlands(my dream country) for work and to meet 
with you and other great programmers. But I don't know where to begin and how I can learn programming and python language in the right way 
without wasting time.

I have studied 10 hours a day but I cannot conclude results.
i have read this books and articles:
beginning python from novice to professional
django 3 by example antonio mele
django for apis william s vincent
django for professionals
django web development with python - packt
fluent python
head first python
practical python design patterns apress(currently reading)
python in a nutshell(currently reading)
the self taught programmer
python 3 for absolute beginners
some django official documents
some python official documents
but i don't know how to use my learnings from books
If you help me to know how I can study in the right way ,I will appreciate you 
for my whole life
thank you and happy new year :)

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

[Python-Dev] Re: unittest of sequence equality

[Ivan Pozdeev via Python-Dev]

On 22.12.2020 22:59, Ivan Pozdeev via Python-Dev wrote:


In the light of this and https://github.com/python/cpython/blob/6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56/Lib/unittest/case.py#L970 (linked 
to from https://mail.python.org/archives/list/python-dev@python.org/message/AQRLRVY7EJT4LTOCV7CLOFK3FJJTVYYM/ )


I reckon that

*like the other code before it, `seq1 == seq2` should check for (TypeError, 
NotImplementedError)





and fall back to by-element comparison in such a case.*



Or just bail out ("resist the temptation to guess") and tell the user to 
compare their weird types themselves.



On 22.12.2020 22:50, Ivan Pozdeev via Python-Dev wrote:


Okay, I see that by "fails", you probably meant "raises this exception" rather 
than fails the usual way (i.e. raises anAssertionError).

On 22.12.2020 22:38, Alan G. Isaac wrote:

Here, `seq1 == seq2` produces a boolean array (i.e., an array of boolean 
values).
hth, Alan Isaac


On 12/22/2020 2:28 PM, Ivan Pozdeev via Python-Dev wrote:


You sure about that? For me, bool(np.array) raises an exception:

In [12]: np.__version__ Out[12]: '1.19.4'

In [11]: if [False, False]==np.array([False, False]): print("foo") <...> ValueError: The truth value of an array with more than one 
element is ambiguous.

Use a.any() or a.all()







On 22.12.2020 21:52, Alan G. Isaac wrote:

The following test fails because because `seq1 == seq2` returns a (boolean) 
NumPy array whenever either seq is a NumPy array.

import unittest import numpy as np 
unittest.TestCase().assertSequenceEqual([1.,2.,3.], np.array([1.,2.,3.]))

I expected `unittest` to rely only on features of a `collections.abc.Sequence`, which based on 
https://docs.python.org/3/glossary.html#term-sequence, I believe are satisfied by a NumPy array. Specifically, I see no requirement 
that a sequence implement __eq__ at all much less in any particular way.


In short: a test named `assertSequenceEqual` should, I would think, work for any sequence and therefore (based on the available 
documentation) should not depend on the class-specific implementation of __eq__.


Is that wrong?

Thank you, Alan Isaac ___ 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/6Z43SU2RPIHTRABYAXBOGRKWGTLIFJYK/ 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/74CUML37OCQXXKMVUFZORMSCOYP2W5GH/
Code of Conduct: http://python.org/psf/codeofconduct/

--
Regards,
Ivan

___
Python-Dev mailing list --python-dev@python.org
To unsubscribe send an email topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-dev@python.org/message/MKNN64A4JFKSBG37KZJ4HFYQ5TIE35AX/
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/WYHFEGPV5WBQZLZZFCQW4STVRGDXNGP3/
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/PTLTPR4YWS5L32D3SZHKD3QNIIIYKWOH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: unittest of sequence equality

[Ivan Pozdeev via Python-Dev]

In the light of this and https://github.com/python/cpython/blob/6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56/Lib/unittest/case.py#L970 (linked 
to from https://mail.python.org/archives/list/python-dev@python.org/message/AQRLRVY7EJT4LTOCV7CLOFK3FJJTVYYM/ )


I reckon that

*like the other code before it, `seq1 == seq2` should check for (TypeError, NotImplementedError) and fall back to by-element comparison in 
such a case.*


On 22.12.2020 22:50, Ivan Pozdeev via Python-Dev wrote:


Okay, I see that by "fails", you probably meant "raises this exception" rather 
than fails the usual way (i.e. raises anAssertionError).

On 22.12.2020 22:38, Alan G. Isaac wrote:

Here, `seq1 == seq2` produces a boolean array (i.e., an array of boolean 
values).
hth, Alan Isaac


On 12/22/2020 2:28 PM, Ivan Pozdeev via Python-Dev wrote:


You sure about that? For me, bool(np.array) raises an exception:

In [12]: np.__version__ Out[12]: '1.19.4'

In [11]: if [False, False]==np.array([False, False]): print("foo") <...> ValueError: The truth value of an array with more than one 
element is ambiguous.

Use a.any() or a.all()







On 22.12.2020 21:52, Alan G. Isaac wrote:

The following test fails because because `seq1 == seq2` returns a (boolean) 
NumPy array whenever either seq is a NumPy array.

import unittest import numpy as np 
unittest.TestCase().assertSequenceEqual([1.,2.,3.], np.array([1.,2.,3.]))

I expected `unittest` to rely only on features of a `collections.abc.Sequence`, which based on 
https://docs.python.org/3/glossary.html#term-sequence, I believe are satisfied by a NumPy array. Specifically, I see no requirement 
that a sequence implement __eq__ at all much less in any particular way.


In short: a test named `assertSequenceEqual` should, I would think, work for any sequence and therefore (based on the available 
documentation) should not depend on the class-specific implementation of __eq__.


Is that wrong?

Thank you, Alan Isaac ___ 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/6Z43SU2RPIHTRABYAXBOGRKWGTLIFJYK/ 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/74CUML37OCQXXKMVUFZORMSCOYP2W5GH/
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/MKNN64A4JFKSBG37KZJ4HFYQ5TIE35AX/
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/WYHFEGPV5WBQZLZZFCQW4STVRGDXNGP3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: unittest of sequence equality

[Ivan Pozdeev via Python-Dev]

Okay, I see that by "fails", you probably meant "raises this exception" rather 
than fails the usual way (i.e. raises anAssertionError).

On 22.12.2020 22:38, Alan G. Isaac wrote:

Here, `seq1 == seq2` produces a boolean array (i.e., an array of boolean 
values).
hth, Alan Isaac


On 12/22/2020 2:28 PM, Ivan Pozdeev via Python-Dev wrote:


You sure about that? For me, bool(np.array) raises an exception:

In [12]: np.__version__ Out[12]: '1.19.4'

In [11]: if [False, False]==np.array([False, False]): print("foo") <...> ValueError: The truth value of an array with more than one 
element is ambiguous.

Use a.any() or a.all()







On 22.12.2020 21:52, Alan G. Isaac wrote:

The following test fails because because `seq1 == seq2` returns a (boolean) 
NumPy array whenever either seq is a NumPy array.

import unittest import numpy as np 
unittest.TestCase().assertSequenceEqual([1.,2.,3.], np.array([1.,2.,3.]))

I expected `unittest` to rely only on features of a `collections.abc.Sequence`, which based on 
https://docs.python.org/3/glossary.html#term-sequence, I believe are satisfied by a NumPy array. Specifically, I see no requirement that 
a sequence implement __eq__ at all much less in any particular way.


In short: a test named `assertSequenceEqual` should, I would think, work for any sequence and therefore (based on the available 
documentation) should not depend on the class-specific implementation of __eq__.


Is that wrong?

Thank you, Alan Isaac ___ 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/6Z43SU2RPIHTRABYAXBOGRKWGTLIFJYK/ 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/74CUML37OCQXXKMVUFZORMSCOYP2W5GH/
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/MKNN64A4JFKSBG37KZJ4HFYQ5TIE35AX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: unittest of sequence equality

[Ivan Pozdeev via Python-Dev]

On 22.12.2020 21:52, Alan G. Isaac wrote:

The following test fails because because `seq1 == seq2` returns a (boolean) 
NumPy array
whenever either seq is a NumPy array.


You sure about that? For me, bool(np.array) raises an exception:

In [12]: np.__version__
Out[12]: '1.19.4'

In [11]: if [False, False]==np.array([False, False]): print("foo")
<...>
ValueError: The truth value of an array with more than one element is 
ambiguous. Use a.any() or a.all()




    import unittest
    import numpy as np
    unittest.TestCase().assertSequenceEqual([1.,2.,3.], np.array([1.,2.,3.]))

I expected `unittest` to rely only on features of a `collections.abc.Sequence`,
which based on https://docs.python.org/3/glossary.html#term-sequence,
I believe are satisfied by a NumPy array. Specifically, I see no requirement
that a sequence implement __eq__ at all much less in any particular way.

In short: a test named `assertSequenceEqual` should, I would think,
work for any sequence and therefore (based on the available documentation)
should not depend on the class-specific implementation of __eq__.

Is that wrong?

Thank you, Alan Isaac
___
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/6Z43SU2RPIHTRABYAXBOGRKWGTLIFJYK/
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/JG7VF7Z3WPHZENEECVPJDPJCB63KB4EH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Ivan Pozdeev via Python-Dev]

The best way to deal with EOL platforms that I've seen is "best effort": do not guarantee continued operability but accept patches that fix 
breakages -- as long as they don't add maintenance burden beyond a comfortable level.


So if there's a person willing to backport changes (and test them themselves since we're not testing on that old platform), I don't see a 
problem.


On 10.12.2020 0:28, Guido van Rossum wrote:

On Wed, Dec 9, 2020 at 12:15 PM Jakub Stasiak mailto:ja...@stasiak.at>> wrote:

I wouldn’t be surprised if there’s a group of people that won’t ever 
upgrade to 10.15+ for variety of reasons (including loss of
32-bit application support) so there’s also that.


In my experience Apple hardware is very reliable and way outlives the OS updates. Even if an OS updates is still available, the newer OS 
often needs more memory, which can be a problem (most Apple hardware is hard to add memory to). What are people supposed to do? Just throw 
away their expensive computer?


--
--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 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/MKYINSTDY6SUVMG6EA2VHMVOOUF5KBKT/
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/73RLAFWBBDKDSK3QMEDWUK3YWVYTU3ZL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: python.org doc portal question/bug

[Ivan Pozdeev via Python-Dev]

I just missed it, too, even though I specifically looked for it.

I was looking for "help"/"feedback"/"contact".
The page I found, https://www.python.org/about/help/, in a text specifically saying about getting help, mentions webmas...@python.org 
 but doesn't say a word about the tracker.


On 04.12.2020 2:38, Guido van Rossum wrote:

It's funny, that link is on every page, but nobody ever sees it. :-)

On Thu, Dec 3, 2020 at 3:35 PM Jonathan Goble mailto:jcgob...@gmail.com>> wrote:

On Thu, Dec 3, 2020 at 6:16 PM Guido van Rossum mailto:gu...@python.org>> wrote:

If you want to get the attention of the people who maintain the 
website, please look at the bottom of any page on python.org
 and file an issue at the GitHub tracker linked 
there.


Done: https://github.com/python/pythondotorg/issues/1697 
 Thanks for the pointer.



--
--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 topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-dev@python.org/message/U5IVOV2NS64LL4PGNBOCOXNPEORK7WMG/
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/57ESVPNLLU5PF3GB6XGFMBB43PR37CGW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Contribution to github repos.

[Ivan Pozdeev via Python-Dev]

See https://devguide.python.org/ .

On 06.11.2020 6:57, Manak Wadhwa wrote:

Hey Guys,
I am Manak Wadhwa. I have a good hand in python language, ML Algorithms, Web 
Dev (HTML5, CSS3, JS, PHP, AJAX, Bootstrap, JQuery). I want to contribute to 
python org can someone help as which repository should i start with or work on.
___
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/TEM5YNTZ5WDJMLA5RNAQ5KMCTMPLOVRH/
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/K6HKQBZQIIIBMJHHZKAL3I5QRZ7JPX5I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: os.scandir bug in Windows?

[Ivan Pozdeev via Python-Dev]

On 19.10.2020 14:47, Steve Dower wrote:

On 19Oct2020 1242, Steve Dower wrote:

On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote:

TLDR: In os.scandir directory entries, atime is always a copy of mtime rather 
than the actual access time.


Correction - os.stat() updates the access time to _now_, while os.scandir() 
returns the last access time without updating it.


Let me correct myself first :)

*Windows* has decided not to update file access time metadata *in directory entries* on reads. os.stat() always[1] looks at the file entry 
metadata, while os.scandir() always looks at the directory entry metadata.


Is this behavior documented somewhere?

Such weirdness certaintly something that needs to be documented but I really don't like describing such quirks that are out of our control 
and may be subject to change in Python documentation. So we should only consider doing so if there are no other options.





My suggested approach still applies, other than the bit where we might fix os.stat(). The best we can do is regress os.scandir() to have 
similarly poor performance, but the best *you* can do is use os.stat() for accurate timings when files might be being modified while your 
program is running, and don't do it when you just need names/kinds (and I'm okay adding that note to the docs).


Cheers,
Steve

[1]: With some fallback to directory entries in exceptional cases that don't 
apply here.
___
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/QHHJFYEDBANW7EC3JOUFE7BQRT5ILL4O/
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/VFXDBURSZ4QKA6EQBZLU6K4FKMGZPSF5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Performance benchmarks for 3.9

[Ivan Pozdeev via Python-Dev]

On 14.10.2020 17:04, M.-A. Lemburg wrote:

On 14.10.2020 16:00, Pablo Galindo Salgado wrote:

  Would it be possible to get the data for older runs back, so that

it's easier to find the changes which caused the slowdown ?

Unfortunately no. The reasons are that that data was misleading because
different points were computed with a different version of pyperformance and
therefore with different packages (and therefore different code). So the points
could not be compared among themselves.

Also, past data didn't include 3.9 commits because the data gathering was not
automated and it didn't run in a long time :(

Make sense.

Would it be possible rerun the tests with the current
setup for say the last 1000 revisions or perhaps a subset of these
(e.g. every 10th revision) to try to binary search for the revision which
introduced the change ?


Git has a facility for this called "bisection". It can be run in automated 
mode, exactly for a scenario like this.

https://git-scm.com/docs/git-bisect



On Wed, 14 Oct 2020 at 14:57, M.-A. Lemburg mailto:m...@egenix.com>> wrote:

 Hi Pablo,

 thanks for pointing this out.

 Would it be possible to get the data for older runs back, so that
 it's easier to find the changes which caused the slowdown ?

 Going to the timeline, it seems that the system only has data
 for Oct 14 (today):

 
https://speed.python.org/timeline/#/?exe=12=regex_dna=1=1000=off=on=on=none

 In addition to unpack_sequence, the regex_dna test has slowed
 down a lot compared to Py3.8.

 
https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_unpack_sequence.py
 
https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_regex_dna.py

 Thanks.

 On 14.10.2020 15:16, Pablo Galindo Salgado wrote:
 > Hi!
 >
 > I have updated the branch benchmarks in the pyperformance server and now 
they
 > include 3.9. There are
 > some benchmarks that are faster but on the other hand some benchmarks are
 > substantially slower, pointing
 > at a possible performance regression in 3.9 in some aspects. In 
particular
 some
 > tests like "unpack sequence" are
 > almost 20% slower. As there are some other tests were 3.9 is faster, is
 not fair
 > to conclude that 3.9 is slower, but
 > this is something we should look into in my opinion.
 >
 > You can check these benchmarks I am talking about by:
 >
 > * Go here: https://speed.python.org/comparison/
 > * In the left bar, select "lto-pgo latest in branch '3.9'" and "lto-pgo 
latest
 > in branch '3.8'"
 > * To better read the plot, I would recommend to select a "Normalization"
 to the
 > 3.8 branch (this is in the top part of the page)
 >    and to check the "horizontal" checkbox.
 >
 > These benchmarks are very stable: I have executed them several times 
over the
 > weekend yielding the same results and,
 > more importantly, they are being executed on a server specially prepared 
to
 > running reproducible benchmarks: CPU affinity,
 > CPU isolation, CPU pinning for NUMA nodes, CPU frequency is fixed, CPU
 governor
 > set to performance mode, IRQ affinity is
 > disabled for the benchmarking CPU nodes...etc so you can trust these 
numbers.
 >
 > I kindly suggest for everyone interested in trying to improve the 3.9 
(and
 > master) performance, to review these benchmarks
 > and try to identify the problems and fix them or to find what changes
 introduced
 > the regressions in the first place. All benchmarks
 > are the ones being executed by the pyperformance suite
 > (https://github.com/python/pyperformance) so you can execute them
 > locally if you need to.
 >
 > ---
 >
 > On a related note, I am also working on the speed.python.org
 
 >  server to provide more automation and
 > ideally some integrations with GitHub to detect performance regressions. 
For
 > now, I have done the following:
 >
 > * Recompute benchmarks for all branches using the same version of
 > pyperformance (except master) so they can
 >    be compared with each other. This can only be seen in the "Comparison"
 > tab: https://speed.python.org/comparison/
 > * I am setting daily builds of the master branch so we can detect 
performance
 > regressions with daily granularity. These
 >    daily builds will be located in the "Changes" and "Timeline" tabs
 > (https://speed.python.org/timeline/).
 > * Once the daily builds are working as expected, I plan to work on 
trying to
 > automatically comment or PRs or on bpo if
 > we detect that a commit has introduced some notable performance 
regression.
 >
 > Regards from sunny London,
 > Pablo Galindo Salgado.
 >
 > 

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

[Ivan Pozdeev via Python-Dev]

Possessive and obstructive behavior like Victor describes below is incompatible with the bazaar model of development (=a model where the dev 
team accepts contributions from a wide range of people).


I've dealt with projects that exert this kind of attitude (Tcl and Git for Windows are the latest examples), and it's invariably been 
miserable: maintainers that do this typically deem everyone else unworthy to get their code into the project, either at all or unless they 
do things exactly as the maintainer wants to -- thus effectively requiring one to read their mind and ignoring anything that's not on their 
mind. As a result, both sides lose: users don't get the features/bugfixes that they want (since their contributions are being rejected for 
no good reason), maintainers don't get contributions (since their requirements are unreasonable or outright impossible to meet), both sides 
waste a lot of time unproductively in the process.


For a testimony from someone with more experience at maintaining than me, see e.g. 
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s03.html and 
http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ar01s11.html .


AFAICS, Python uses the bazaar model as its development principle. As such, Stefan could be suspended even earlier, at one of the instances 
that Victor described, -- for sabotaging the project.


On 10.10.2020 16:46, Victor Stinner wrote:

Hi,

Le ven. 9 oct. 2020 à 21:02, Brett Cannon  a écrit :

Another way to look at this is to realize that Stefan's behaviour may have 
scared off people who would have been willing to contribute to the decimal 
module. As Christian pointed out, there is already one instance of a 
contributor who he felt needed to be followed up with to make sure they were 
okay. As much as we know they could have become a major contributor to 
'decimal' and this specific concern wouldn't even exist.

I dislike using Stefan as an example, but it seems like some people
don't understand the Steering Council decision. I hope that my email
will give a little bit more context. I don't want to discuss technical
changes, but more share my feedback on a specific behavior. The intent
of the Steering Council is to no longer tolerate specific behaviors,
rather than to ban arbitrary people.

I would like to share my own experience with the decimal module over
the last years. In short, I learnt the hard way to never attempt to
modify it (missing stair, see below) and I consider that it's an issue
(behavior which should no longer be tolerated in Python).

--

Multiple times, I wrote large PRs modifying tons of random files at
once to replace one pattern with another. For example, to use a new
faster C API. When one of my PR modified the decimal module, Stefan
always asked me to revert my changes on this specific module.
Honestly, I didn't even notice that the decimal module was modified,
since I ran an automated command on the whole Python code base.

The decimal module was always special and had special rules. Stefan
was not helpful in getting my changes merged, but asked me for extra
work to always exclude the decimal module from such "refactoring" PR.

Once, I wrote a decimal bugfix for a specific Unicode issue related to
the locale encoding for numbers. I wrote a test to prove that the
current code fails and that it just works with my change. I did all
the work (bugfix, manual test) but Stefan rejected my PR, considering
that it's worth it to fix this bug (don't support such locale
configuration). He used a third party test suite as a justification,
but even when I asked, he didn't explain to me how to get it. That
sounds unfair for people who want to contribute (to not have all
development tooling available).

I also wrote an optimization to speedup some decimal functions and
methods by using the new METH_FASTCALL calling convention. Stefan also
rejected my optimization, even if I proved that it makes decimal
faster. I don't recall the details, but the reason was something about
having the same code base in all Python branches. I didn't understand
this rationale. Most stdlib modules subtle differences between each
Python branch, to get new features, to use new Python features, etc.

I never tried to argue with Stefan to get my changes merged. I like
the decimal module, it's great, but it's not really my priority. Also,
when I saw how Stefan replied to other people on other issues, I
didn't want to go through similar bad interactions.

At some point, I decided that Stefan is a missing stair, someone that
I must avoid whenever I can:
https://en.wikipedia.org/wiki/Missing_stair

Stefan wants to work alone, don't attempt to touch his code base.
Well, some people were more lucky than me and got their changed into
the decimal module.

I was never comfortable with the fact that other contributors must
also avoid Stefan (missing stair) and so don't attempt to touch the
decimal module. I would prefer greater collaboration on 

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

[Ivan Pozdeev via Python-Dev]

On 09.10.2020 15:28, Christian Heimes wrote:

On 09/10/2020 04.04, Ivan Pozdeev via Python-Dev wrote:

I don't see the point of requiring to "write an apology", especially
*before a 12-month ban*. If they understand that their behavior is
wrong, there's no need for a ban, at least not such a long one; if they
don't, they clearly aren't going to write it, at least not now (they
might later, after a few weeks or months, having cooled down and thought
it over). So all it would achieve is public shaming AFAICS. Same issue
with the threat of "zero tolerance policy" -- it's completely
unnecessary and only serves to humiliate and alienate the recipient.


I have been the victim of Stefan's CoC violations on more than one
occasion. He added me to nosy list of a ticket just to offend and
humiliate me. For this reason I personally asked the SC to make a
sincere apology a mandatory requirement for Stefan's reinstatement as a
core dev.


As a requirement for _reinstatement_ , it does make sense.



I would have been fine with a private apology. However Stefan has also
verbally attacked non-core contributors. In one case another core dev
and I contacted the contribute in private to apologize and ensure that
the contributor was not alienated by Stefan's attitude. Therefore it
makes sense that the SC has requested a public, general apology.

Why are you more concerned with the reputation of a repeated offender
and not with the feelings of multiple victims of harassment? As a victim
of Stefan's behavior I feel that an apology is the first step to
reconcile and rebuild trust.

Christian
--
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/XPZI4CWHJ2FB4BLUIZ54II6WLHZQKUV3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

[Ivan Pozdeev via Python-Dev]

I don't see the point of requiring to "write an apology", especially *before a 12-month ban*. If they understand that their behavior is 
wrong, there's no need for a ban, at least not such a long one; if they don't, they clearly aren't going to write it, at least not now (they 
might later, after a few weeks or months, having cooled down and thought it over). So all it would achieve is public shaming AFAICS. Same 
issue with the threat of "zero tolerance policy" -- it's completely unnecessary and only serves to humiliate and alienate the recipient.


Cf. https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Purpose_and_goals, specifically: "blocks should not be punitive, blocks should 
be preventative".


(Btw thanks for publishing the letter. This is done very rarely so issues like 
this most often go unnoticed.)

On 09.10.2020 2:07, Thomas Wouters wrote:


Stefan did indeed receive, and was notified of, a 1-year ban from core development. This action was based on advice from the Conduct WG 
and our own deliberations. We wanted to have a discussion with him before we made this public. The SC sent him an email with details 
(quoted below), three weeks ago, CC'ing the Conduct WG. We had a brief back-and-forth last week. Unfortunately (and without telling us), 
Stefan apparently declined to address the matter in the way we asked.


For the record, the Steering Council followed the PEP 13 procedure for ejecting a core developer 
(https://www.python.org/dev/peps/pep-0013/#ejecting-core-team-members) and voted unanimously to eject Stefan, as we told Stefan we would 
do if he chose not to address the concerns we outlined below.


Our original message to Stefan:
"""
Dear Stefan,

The Python Steering Council and the PSF Conduct Working Group have received reports of your ongoing behavior in the Python core developer 
community. The Steering Council agrees with the Conduct Working Group’s findings that this behavior is unacceptable. While we appreciate 
your valuable technical contributions to CPython, that does not exempt you from the expected standards of behavior and the Code of Conduct.


Specifically, your behavior has displayed:

* Disrespectful, hostile, and unwelcoming communication in tone and content
* Harassment by needlessly adding people to issues
* A disregard of the directions and authority of the release manager

Some examples of the problematic behavior include:

* https://bugs.python.org/issue36839#msg344544
* https://bugs.python.org/issue40874#msg372616
* https://bugs.python.org/issue40874#msg372917
* https://bugs.python.org/issue40874#msg372922
* https://bugs.python.org/issue39542#msg372983

We are also aware that this is not new behavior. We know the PSF Conduct WG warned you on April 23, 2020 about your previous violations of 
the Code of Conduct.


As such, we are taking the action of suspending your participation in Python's development for 12 months starting today. You will lose 
access to:


* Python-committers
* Python-dev
* Python-ideas
* Core-mentorship
* bugs.python.org 
* discuss.python.org 
* The Python organization on GitHub

Along with the 12-month suspension, you will need to meet additional conditions 
in good faith:

* Please acknowledge that you have read and understand the Code of Conduct and 
promise to abide by it going forward
* You write an apology to your fellow core developers for your actions which we 
will publish on your behalf when announcing your suspension
* Acknowledge that future reinstatement will include a zero-tolerance conduct 
policy in regards to your future behavior

We offer you 14 days from today to meet these conditions and submit them to the 
Steering Council via email.

If you choose not to satisfy these conditions, the 12-month suspension will become a permanent ejection from the Python core developer 
community as per the procedures outlined in PEP 13.  You are then free to go through the Python core developer election process also as 
outlined in PEP 13, however the Steering Council will not consider approving any positive outcome of that vote until the 12-month 
suspension has elapsed.


- The Python Steering Council
"""

On behalf of the Steering Council,
Thomas.

On Wed, Oct 7, 2020 at 11:48 PM Antoine Pitrou mailto:anto...@python.org>> wrote:


Hello,

Apparently, Stefan Krah (core developer and author of the C _decimal
module) was silently banned or moderated from posting to python.org 

mailing-lists.  He asked me to forward the following message:



==
Hello,

Today I have left the Python organization.  It wasn't an easy decision,
after all there are so many amazing people here.

My vision of how development should be handled differs from many people
who are currently active.  Other projects are more aligned with my
preferences, so I prefer to 

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

[Ivan Pozdeev via Python-Dev]

Then, as Victor said, it will have to be bundled into Python's codebase.

On 05.09.2020 11:06, Emily Bowman wrote:

On Sat, Sep 5, 2020 at 12:37 AM Ivan Pozdeev via Python-Dev mailto: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.

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

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

[Ivan Pozdeev via Python-Dev]

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.


On 04.09.2020 14:28, Steve Dower wrote:

Hi all.

setuptools has recently adopted the entire codebase of the distutils module, so that they will be able to make improvements directly 
without having to rely on patching the standard library. As a result, we can now move forward with official deprecation (in 3.10) and 
removal (in 3.12) (noting that the distutils docs already recommend switching to setuptools).


Full text and discussion at 
https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134

I'm including the original text below, but won't be responding to all discussions here (though I'll periodically check in and skim read 
it, assuming things don't go way off track).


Also be aware that I already have some minor changes lined up that are not in this text. Refer to the discussion on Discourse if you need 
to see those.


Cheers,
Steve

---

PEP: 632
Title: Deprecate distutils module
Author: Steve Dower 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 03-Sep-2020
Post-History:


Abstract


The distutils module [1]_ has for a long time recommended using the
setuptools package [2]_ instead. Setuptools has recently integrated a
complete copy of distutils and is no longer dependent on the standard
library [3]_. Pip has silently replaced distutils with setuptools when
building packages for a long time already. It is time to remove it
from the (public part of the) standard library.


Motivation
==

distutils [1]_ is a largely undocumented and unmaintained collection
of utilities for packaging and distributing Python packages, including
compilation of native extension modules. It defines a configuration
format that describes a Python distribution and provides the tools to
convert a directory of source code into a source distribution, and
some forms of binary distribution. Because of its place in the
standard library, many updates can only be released with a major
release, and users cannot rely on particular fixes being available.

setuptools [2]_ is a better documented and well maintained enhancement
based on distutils. While it provides very similar functionality, it
is much better able to support users on earlier Python releases, and
can respond to bug reports more quickly. A number of platform-specific
enhancements already exist in setuptools that have not been added to
distutils, and there is been a long-standing recommendation in the
distutils documentation to prefer setuptools.

Historically, setuptools has extended distutils using subclassing and
monkeypatching, but has now taken a copy of the underlying code. [3]_
As a result, the second last major dependency on distutils is gone and
there is no need to keep it in the standard library.

The final dependency on distutils is CPython itself, which uses it to
build the native extension modules in the standard library (except on
Windows). Because this is a CPython build-time dependency, it is
possible to continue to use distutils for this specific case without
it being part of the standard library.

Deprecation and removal will make it obvious that issues should be
fixed in the setuptools project, and will reduce a source of bug
reports and test maintenance that is unnecessary. It will also help
promote the development of alternative build backends, which can now
be supported more easily thanks to PEP 517.


Specification
=

In Python 3.10 and 3.11, distutils will be formally marked as
deprecated. All known issues will be closed at this time.
``import distutils`` will raise a deprecation warning.

During Python 3.10 and 3.11, uses of distutils within the standard
library may change to use alternative APIs.

In Python 3.12, distutils will no longer be installed by ``make
install`` or any of the first-party distribution. Third-party
redistributors should no longer include distutils in their bundles or
repositories.

This PEP makes no specification on migrating the parts of the CPython
build process that currently use distutils. Depending on
contributions, this migration may occur at any time.

After Python 3.12 is started and when the CPython build process no
longer depends on distutils being in the standard library, the entire
``Lib/distutils`` directory and ``Lib/test/test_distutils.py`` file
will be removed from the repository.

Other references to distutils will be cleaned up. As of Python 3.9's
initial release, the following modules have references in code or
comments:

* Lib/ctypes/util.py
* Lib/site.py
* 

[Python-Dev] Re: PR stuck in Travis

[Ivan Pozdeev via Python-Dev]

(Whoops, replied only to Facundo by mistake. Resending with reply to the list 
as well.)

At first glance, it looks like Travis not acting upon a build request.

First, AFAICS from the UI, you can merge it regardless. But I suggest 
restarting the checks as it might be an actual problem for Travis build.

It's possible to restart checks with

* make an empty commit with `git commit --allow-empty`. As a member, you can 
push to PR branches yourself

* (not sure) close and reopen the PR

Recent build requests can be seen at https://travis-ci.com/github/python/cpython/requests . If there's a problem with build creation, you 
will see it there.



On 21.08.2020 21:18, Facundo Batista wrote:

Hello!

I want to land this PR:

   https://github.com/python/cpython/pull/21466

It's doc only, so it only run the docs part in GH actions. All fine,
except Travis, which is "required", but didn't finish. I'm not finding
a way to restart that job.

- from Github: I don't find any restart/resend job or similar (and in
the line corresponding to Travis in the checks list, I don't have a
"details").

- from Travis: I can not make that PR to appear in
https://travis-ci.com/github/python/cpython/pull_requests  , even if I
click on "show me more" a lot (a *lot*). I don't know if there's a
specific way to show the job "by PR", and not "by build" (which I
don't know).

- from git: I could tell the author to push an empty commit, that
probably would do it, but I'd consider this a last resource.

Did you suffer from this before? Which is the recommended course of action?

Thanks!

--
Regards,
Ivan



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

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

[Ivan Pozdeev via Python-Dev]

+10. See https://stackoverflow.com/questions/36825925/expressions-with-true-and-is-true-give-different-results/36826262#36826262 for 
concrete evidence where another semantically inconsistent operator overloading caused trouble and what Stroustroup has to say on the matter.


On 31.07.2020 13:42, Larry Hastings wrote:



On 7/31/20 12:36 AM, Tobias Kohn wrote:


And since pattern matching is really
a new feature to be introduced to Python, a feature that can
be seen in different lights, there is no 'Python-Programmer
intuition' that would apply in this case.

It's not fair to say "intuition doesn't apply because it's new syntax".  There are plenty of examples of intuition serving a Python 
programmer well when encountering new syntax.  A Python programmer's intuition is informed by existing syntax and conventions in the 
language.  When they see a new construct, its similarity to existing constructs can make understanding the new syntax quite intuitive indeed.


Take for example list comprehensions.  Python 1 programmers hadn't seen

a = [x for x in y]

But they knew what square brackets meant in that context, it meant "creates a new list".  And they knew what "for x in y" meant, that 
meant iteration.  Understanding those separate two concepts, a Python 1 programmer would be well on their way to guessing what the new 
syntax meant--and they'd likely be right. And once they understood list comprehensions, the first time they saw generator expressions and 
set and dict comprehensions they'd surely intuit what those did immediately.


The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks like existing Python syntax but frequently has wholly 
different semantics.  For example, a "class pattern" looks like it's calling a function--perhaps instantiating an object?--but the actual 
semantics and behavior is very different.  Similarly, a "mapping pattern" looks like it's instantiating a dict, but it does something very 
different, and has unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you can't use full expressions or 
undotted-identifiers when defining a key.  Add the "capture pattern" to both of these, and a Python programmer's intuition about what this 
syntax traditionally does will be of little help when encountering a PEP 622 match statement for the first time.


Cheers,


//arry/


___
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/Q5KULD7E3TZSSQ5CFUOQSJTGS5JQS4WM/
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/CGJFIX6APEH76NASM6KDFF5GUDEZRK5T/
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: [OT] I'm unsubscribing from this tire fire (formerly known as python-dev)

[Ivan Pozdeev via Python-Dev]

I'm using my mailer's "ignore thread" feature and counting on the fact that the 
flamers will eventually exhaust themselves (most already have).

On 06.07.2020 8:41, Christian Heimes wrote:

Y'all,

trigger warning: strong opinion

The Urban Dictionary defines the term "tire fire":

   A horrifying mess, either literally or figuratively
   foul-smelling, that seems to last forever.

The term describes my current view of python-dev perfectly. It has
always been a problematic and mentally draining place for, sometimes
even toxic. But the recent PEP-8 discussion trumps every past incident
(reference to US politics intended).


To every person still replying on the PEP-8 thread:

   You are making us sick and should be ashamed of yourself!

And I don't mean 'sick' in the figurative sense. You are literally
hurting people who are spending their free and personal time to develop
open source software for you. I know of at least three cases among
Python core developers with symptoms like sleep disorder, tremor,
anxiety, and panic attacks. One core dev wrote publicly that they were
forced to take psychotropic medicine to counter a panic attack after
they have read just a few messages.


At one point I have even considered to retire from Python core
development completely. I'm profoundly disgusted and appalled by the
racist attitudes and self-importance of some people as well as an
unrelated incident on BPO last week. The two reasons I'm not leaving are
  several core developers that I'm happy to call friends and Python
communities beyond predominantly male and Western participants on the
PEP-8 thread. Communities like PyLadies, PyCon Africa, PyLATAM, and
PyCon APAC make me proud and happy to be a member of the Python
community. I have met fantastic people at Python and OSS events in the
Caribbean, India, and East Europe. I don't want to abandon people I
cherish and grew fond of.


At least one other core developer has abandoned python-dev last week.
Others have stopped participating and posting on python-dev years ago. I
will follow their example now.

Goodbye
Christian
___
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/LR3RWME7NYAVAWGD2ZD5NPZAGL7VVI7K/
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/EE2JEIB2CPVLEQR4XTNGFDZWIZJ5LB2L/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ivan Pozdeev via Python-Dev]

On 04.07.2020 10: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.




Since it's in "security fixes only" mode, you can just claim that anything 
beyond that, compatibility with anything included, is not guaranteed.

You had no problems using that defense before in 
https://mail.python.org/archives/list/python-dev@python.org/thread/YUT66GNSDPWPUWDUHQ7KVTD2DNP3DQPU/#KB3MJSP4DH43R6MLNTT2W2BLHGLRAQBF



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.



Hold tight,


//arry/

p.s. Happy American Independence Day!


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

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Ivan Pozdeev via Python-Dev]

On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:

On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev mailto:v...@mail.mipt.ru>> wrote:

So what?

Unnecessary

They'll have to synchronise their history to ours to be able to make a PR. 
And if they don't, it doesn't matter for us what they do
with the data anyway since they are responsible for maintaining it and 
keeping it relevant if they need to, not us

That is not a very collaborative mindset.


I fail to see how. We provide all the tools to collaborate. If a person has a divergent history, they will see that when trying to 
collaborate (submit a PR or otherwise interact with our repo from theirs in any way) and will be able to fix that problem then and there.




Can somebody give an example of when we force-pushed before? Surely there should be a PEP outlining when we force push and how we 
communicate this to our "consumers" before/when we do so?


Plus, since it's the PEPs repo, it's tightly bould to the Python project -- 
the usefulness of a fork disconnected from it is pretty low.


It partially serves as documentation for the Python project, so mirroring it and its documentation (in git form or in its presented form) 
can definitely have a use, for example, if you are an environment that has no internet access (common in secret government work, and I am 
sure their IT team will be even less pleased that they have to do something by hand and overwrite history!).


--
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/4MQYGI44AZT66SOHZDDYQVQXZBZTNEEU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Ivan Pozdeev via Python-Dev]

On 03.07.2020 15:01, Henk-Jaap Wagenaar wrote:

On Fri, 3 Jul 2020 at 08:50, Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> wrote:


Per 
https://mail.python.org/archives/list/python-dev@python.org/message/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/,
 we're talking about an
infinitely
less impactful peps repo (per 
https://mail.python.org/archives/list/python-dev@python.org/message/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/,
only 6
people in the entire world would be affected).


It will not affect only 6 people.

That is just the number of people who have forks that we know about and even those who do not have forks but maintain a copy (for whatever 
reason) of the main branch will be affected: they will have to reset their branch or do some other malarkey to get this new "improved" 
history. This will be a much bigger group of people and also potentially software solutions that are mirroring the repo for one reason or 
another.


That's one of the prices you pay (or I would say benefit) for having a decentralized version control system: it makes it hard to rewrite 
(supposedly "improve") history.


So what? They'll have to synchronise their history to ours to be able to make a PR. And if they don't, it doesn't matter for us what they do 
with the data anyway since they are responsible for maintaining it and keeping it relevant if they need to, not us.


Plus, since it's the PEPs repo, it's tightly bould to the Python project -- the 
usefulness of a fork disconnected from it is pretty low.


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

[Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)

[Ivan Pozdeev via Python-Dev]

On 03.07.2020 3:10, Łukasz Langa wrote:

On 2 Jul 2020, at 21:38, Chris Angelico  wrote:

Formal proposal: Either request a new commit message from the original
author, or have someone rewrite it, and we go ahead and make the
change.

-1

This would be serious precedent to fiddling with publicly replicated repo 
history. This would require coordination with project admins as force-pushes 
are rightfully disabled for our repositories.

Commit messages aren't usually scrutinized to this extent. If you looked at the 
last 1000 commits in cpython, you'd find quite a few with messages that could 
be seriously improved. We don't though because commits are immutable. You can 
revert them but we never downright replace them with different ones. Otherwise 
what's the point in me signing release tags?


Per https://mail.python.org/archives/list/python-dev@python.org/message/T7CM4AUJFQN5WDZ5E4PIR7IIK7AOPRTE/, "commits are immutable" is just 
one point of view, as valid as the other one, and leaving this commit as is would be much more harmful than an average poorly-worded one.


Per https://mail.python.org/archives/list/python-dev@python.org/message/KQSHT5RZPPUBBIALMANFTXCMIBGSIR5Z/, we're talking about an infinitely 
less impactful peps repo (per https://mail.python.org/archives/list/python-dev@python.org/message/64LIUO4C3EWT45YCTRZLDA7B7IE33IXA/, only 6 
people in the entire world would be affected).


And, no-one suggested overwriting a Python release, comparing this to that is 
blowing it way out of proportion.



Is the commit message perfect? No. Is the intent explained better on the linked 
PR? Yes. Is the change itself good? Also yes.

Formal proposal: leave this alone.

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

[Python-Dev] Re: Re Re: Recent PEP-8 change (Ivan Pozdeev)

[Ivan Pozdeev via Python-Dev]

At https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_rebase_vs_merge, they say that the argument of whether to allow overwriting 
history in VCSes stems from two opposing views on what a project's history should be. One is that is shall be a raw, unedited record of 
events as they happened; the other is that is should be a (polished and adapted for future reading) story of how the project was made.



While I'm firmly in camp story (long story short, it makes history much more useful for everything except playing the blame game), in this 
case, there's a case-specific reason, too.



The remarks that stem the controversy have nothing to do with commit's intent in technical terms: clarifying wording that cause 
misunderstanding. They were simply speculations by the author (and misguided ones at that since Strunk & White are actually names).



Leaving this commit as it is will leave no trace of any "comment on the commit" and later discussion to a future onlooker. And as a commit 
is the official codebase, it will still appear as endorsed by the dev team. There'd be no clue that this is not the "final" thoughts on the 
matter and there something else, somewhere else, and who knows where.



While editing the message to just state facts (clarifying the wording) and omit specuilations, it will still serve its purpose -- while 
stating the actual, valid, endorsed by the team (since the concensus is that the change itself was useful and should not be reverted but 
could be improved further, as a separate initiative), clean from speculations intent of the edit.




On 02.07.2020 23:17, David Antonini wrote:

No contention to the contrary, but as a routine, post-merge git history 
rewrite, not a grand plan, from what I understand.

Oh the other hand, an 'official' comment on the commit, recognising the issue with the original commit message, the following discussion, 
and any conclusions that get reached, might be better, in my opinion. I prefer to recognise and critique, rather than erase,
'historical' history, as a rule (as opposed to git history). I think similar damage is done in this case, when the record, and opportunity 
to point to and learn from it, is erased.


David

---
Date: Thu, 2 Jul 2020 21:33:56 +0300
From: Ivan Pozdeev 
Subject: [Python-Dev] Re: Recent PEP-8 change (Antoine Pitrou)
To: python-dev@python.org
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed
On 02.07.2020 21:20, Chris Angelico wrote:
> On Fri, Jul 3, 2020 at 4:09 AM David Mertz  wrote:
>>> An issue is that commit messages are uneditable after merge, so something written somewhere suggesting consideration of this would be 
a good idea, with authors/mergers bearing this in mind, however unusual a change on this basis would be. This would be additional burden 
on the core dev team, but if commitment is to be made to inclusivity, it might be what's necessary.

>>
>> I don't think so. https://docs.github.com/en/github/committing-changes-to-your-project/changing-a-commit-message. Interactive rebasing 
is perfectly possible, isn't it. I admit my git-fu isn't that strong, but I've done something that I *think* is the same as this.  It's 
possible I'm missing some distinction between the trees I've modified and the current one, but I don't think so.

>>
> When you do that sort of rewriting, you're constructing a new and
> independent history and then saying "hey, this is the history I want
> everyone to respect now, thanks". It's full-on Back To The Future
> stuff, and can have annoying or serious consequences with everyone who
> has a clone or fork of the repo.
>
> It would be extremely annoying to anyone who has an open PR at the
> time of the rewrite, but the annoyance would be temporary (hopefully
> one-off).


If you are talking about rewriting the PEP8 commit, it has proven to cause so much damage that this is warranted despite the 
inconveniences IMO.


> ChrisA
> ___
> 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/A2XBFOH5WGEOASSXHHKRWEHMZBN625SU/
> 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/ZZKGBAROR7TR2M7TM4EYSIIHXTUBQB4Y/
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] Re: Recent PEP-8 change (Antoine Pitrou)

[Ivan Pozdeev via Python-Dev]

On 02.07.2020 21:20, Chris Angelico wrote:

On Fri, Jul 3, 2020 at 4:09 AM David Mertz  wrote:

An issue is that commit messages are uneditable after merge, so something 
written somewhere suggesting consideration of this would be a good idea, with 
authors/mergers bearing this in mind, however unusual a change on this basis 
would be. This would be additional burden on the core dev team, but if 
commitment is to be made to inclusivity, it might be what's necessary.


I don't think so. 
https://docs.github.com/en/github/committing-changes-to-your-project/changing-a-commit-message.
  Interactive rebasing is perfectly possible, isn't it.  I admit my git-fu 
isn't that strong, but I've done something that I *think* is the same as this.  
It's possible I'm missing some distinction between the trees I've modified and 
the current one, but I don't think so.


When you do that sort of rewriting, you're constructing a new and
independent history and then saying "hey, this is the history I want
everyone to respect now, thanks". It's full-on Back To The Future
stuff, and can have annoying or serious consequences with everyone who
has a clone or fork of the repo.

It would be extremely annoying to anyone who has an open PR at the
time of the rewrite, but the annoyance would be temporary (hopefully
one-off).



If you are talking about rewriting the PEP8 commit, it has proven to cause so 
much damage that this is warranted despite the inconveniences IMO.


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

[Python-Dev] Re: The Anti-PEP

[Ivan Pozdeev via Python-Dev]

On 25.06.2020 13:57, Mark Shannon wrote:

Hi,

I'd like to propose the "Anti-PEP".

As I'm sure you've all noticed, contentious PEPs like 572, and now 622, 
generate a lot of email discussion.
It's easy to feel that people's opinions are being dismissed and that 
legitimate criticisms aren't being heard.
Conversely, PEP authors may feel they are being bombarded with criticism, which 
can be overwhelming.

The acceptance, or rejection, of a PEP should be a cool technical decision. Whilst there may be considerations of aesthetics and usability 
that make it difficult to objective, the goal should be to choose what is best for the language in the long term.


When deciding on PEP 484, I had to decide between a formally written PEP on one hand, and a mass of emails and informal polls I had done 
at conferences, on the other.

I hope I made the right decision.

Whether the ultimate decision is made by the steering committee or by a PEP delegate, it is hard to make a decision between the pros and 
cons, when the pros are in a single formal document and the cons are scattered across the internet.


What prevents the cons from being included into a PEP, too?



An Anti-PEP is a way to ensure that those opposed to a PEP can be heard and, if 
possible, have a coherent voice.
Hopefully, it would also make things a lot less stressful for PEP authors.


The Anti-PEP


The Anti-PEP is a single document that describes why a particular PEP should be 
rejected.

An Anti-PEP is not a counter PEP. A counter PEP suggests an alternative solution to the same problem and will often share the same 
motivation as the original PEP. An Anti-PEP would usually reject the motivation or rationale, either as insufficient or as incorrect.


An example of a counter PEP is 576, which was a counter to 575. The motivation was the same, but means proposed was quite different. As a 
result of the ensuing to and fro, we ended up with PEP 590, which was a clear improvement.


I don't have an example of an Anti-PEP.

We could start with PEP 611, https://www.python.org/dev/peps/pep-0611/. There were many criticisms of it on this mailing list, and I can 
promise the PEP author won't be upset by an Anti-PEP :)

Anyone care to volunteer?

Cheers,
Mark.
___
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/JVKWNZEDRXR2IF3KM2JNUF6WT7WETUVK/
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/JRWRWMTFSUPXLBBEBMW52VKDTWLXTVXR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: REPL output bug

[Ivan Pozdeev via Python-Dev]

On 16.06.2020 1:40, Joseph Jenne via Python-Dev wrote:

On 2020-06-15 15:26, Ivan Pozdeev via Python-Dev wrote:


On 12.06.2020 11:01, Rob Cliffe via Python-Dev wrote:

If I run the following program (using Python 3.8.3 on a Windows 10 laptop):

import sys, time
for i in range(1,11):
    sys.stdout.write('\r%d' % i)
    time.sleep(1)

As intended, it displays '1', replacing it at 1-second intervals with '2', '3' 
... '10'.

Now run the same code inside the REPL:

Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
12
22
32
42
52
62
72
82
92
103
>>>

It appears that the requested characters are output, *followed by* the number 
of characters output
(which is the value returned by sys.stdout.write) and a newline.
Surely this is not the intended behaviour.
sys.stderr behaves the same as sys.stdout.



3.7.4 win64 works as expected (i.e. prints and overwrites only the numbers) and I see nothing relevant in 
https://docs.python.org/3/whatsnew/3.8.html


So I'd say this is a bug.



Python 2 does NOT exhibit this behaviour:

Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
10>>>
# displays '1', '2' ... '10' as intended.

Best wishes
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/T3BVZMBLWK3PMLRL2XCQFMLATGRTUPYE/
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/6BS3GXCS63PTXZMOMZSC6M5DHNAJO5FX/
Code of Conduct: http://python.org/psf/codeofconduct/


I just tested with 3.7.3 and got the same results as originally described. Is 
there something different about 3.7.4 on win7?



"Something different" is that I ran this in IPython :\


Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
12
22
32
42
52
62
72
82
92
103
(I also tested with 3.8.3 with the same results)

Joseph J
___
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/TOSIE4NBT3LVO2ZNUM7FDLTWIIYNJWSP/
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/YJXGEYC25GVGN4PA23DW2L4423KGBIMM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: REPL output bug

[Ivan Pozdeev via Python-Dev]

On 12.06.2020 11:01, Rob Cliffe via Python-Dev wrote:

If I run the following program (using Python 3.8.3 on a Windows 10 laptop):

import sys, time
for i in range(1,11):
    sys.stdout.write('\r%d' % i)
    time.sleep(1)

As intended, it displays '1', replacing it at 1-second intervals with '2', '3' 
... '10'.

Now run the same code inside the REPL:

Python 3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:20:19) [MSC v.1925 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
12
22
32
42
52
62
72
82
92
103
>>>

It appears that the requested characters are output, *followed by* the number 
of characters output
(which is the value returned by sys.stdout.write) and a newline.
Surely this is not the intended behaviour.
sys.stderr behaves the same as sys.stdout.



3.7.4 win64 works as expected (i.e. prints and overwrites only the numbers) and I see nothing relevant in 
https://docs.python.org/3/whatsnew/3.8.html


So I'd say this is a bug.



Python 2 does NOT exhibit this behaviour:

Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, time
>>> for i in range(1,11):
... sys.stdout.write('\r%d' % i)
... time.sleep(1)
...
10>>>
# displays '1', '2' ... '10' as intended.

Best wishes
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/T3BVZMBLWK3PMLRL2XCQFMLATGRTUPYE/
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/6BS3GXCS63PTXZMOMZSC6M5DHNAJO5FX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ivan Pozdeev via Python-Dev]

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] Re: How to specify optional support of arguments

[Ivan Pozdeev via Python-Dev]

(see an answer to the OP's specific question below)

I don't quite get the point for .supports_stuff. It seems 
well-intentioned but misguided.

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.


2. Support of a parameter is a characteristic of a function rather than a module. So information like this doesn't belong at module level. 
Moreover, object references can be moved around at will and they are all equal, there's no such thing as "one true reference" (you can get 
the object's lexical scope but there's no guarantee that it corresponds to the public interface).
    This is the structural conflict that Sergey ran into when he suddenly discovered that the functions and the flag are two completely 
unrelated objects that can be in completely different places.


    So any such flags, if they have the right to exist at all, should be 
attached to function objects.

On 14.06.2020 20:36, Serhiy Storchaka wrote:
In Python 3.3 a number of functions in the os module got the support of new options, like dir_fd or follow_symlinks. I well remember this 
because the initial reason of my contribution to CPython was related to this feature.


The support of new options was platform dependent. They were supported only on some Posix platforms, but not on Windows. Sets like 
supports_dir_fd and supports_follow_symlinks was added in the os module to specify which functions support which options. If say os.stat 
is contained in os.supports_dir_fd, then os.stat() supports keyword argument dir_fd.


Now I want to add the support of dir_fd to glob.glob() and some other functions. It will be platform-dependent, it requires os.open() and 
os.stat() supporting dir_fd and os.scandir supporting the file descriptor argument. How can I specify that glob.glob() supports dir_fd?


1. Add glob.glob in os.supports_dir_fd? It looks strange that importing the 
glob module modifies the value of the os module.

2. Introduce the glob.supports_dir_fd set and add glob.glob to it? We will need to add sets supports_dir_fd in all modules which contain 
functions which can support dir_fd. But what if the function is defined in one module, by normally is imported from other module? Should 
we merge sets supports_dir_fd from different modules?



This would be the way consistent with the current design.

If the public interface is to use the function from another module, the public interface module should have a parameter like this; whether 
the private module also has one and whether they are different objects is implementation detail.




Also, the common problem with two former options is that when we wrap the 
function, we need to add it to the corresponding set.

3. Or set the attribute glob.glob.supports_dir_fd = True or glob.glob.__supports_dir_fd__ = True (and add similar attributes to all os 
functions which support)?


What are your thoughts?
___
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/GCPDYSPB4656Q7TAMDLBFED6NQJCNLIP/
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/F4N5RY3VFSFEYT57RZMPA74J67XAGU45/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x

[Ivan Pozdeev via Python-Dev]

On 13.06.2020 3:49, Łukasz Langa wrote:



On 12 Jun 2020, at 19:51, Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> wrote:

I would doubt the quality of tags maintenance at Github, too. E.g.https://github.com/python/cpython/pull/12131is labeled 3.7 and 3.8 at 
BPO but has no backport tags whatsoever at GH.

So the search you gave is clearly insufficient.


Tags maintenance isn't about quality but rather about automation. Things without backport tags won't get backported unless somebody does 
it by hand. And even automatically created backports need to be created off of committed pull requests and need to pass tests to be 
mergeable. Given the limited time until the Monday cutoff, I'd say that almost all of your 700+ BPO open issues that list 3.7 as affected 
will miss the boat on the fixes.


Except they are not "mine" but everyone's.


I'll have some downtime next week so I could look into adding stuff to automatically update labels on existing issues and PRs upon release 
of a new major version to, say, bedevere. The lack of this is the reason for the discrepancy.





- Ł
--
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/MLDOEOYTKNZHCKTWMGI772Q7YLOVR4CZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x

[Ivan Pozdeev via Python-Dev]

On 12.06.2020 16:08, Ned Deily wrote:

On Jun 12, 2020, at 08:25, Ivan Pozdeev via Python-Dev  
wrote:

Why not take a look at the list of open issues for 3.7 with PRs then? There are 
702 as of now.

https://bugs.python.org/issue?%40sort0=creation&%40sort1=&%40group0=&%40group1=&%40columns=title%2Cid%2Cactivity%2Cstatus&%40filter=status%2Cversions%2Cstage=1=21=4&%40pagesize=50&%40startwith=0

Looking at open PRs is a good suggestion. Unfortunately, the version tags on 
the bug tracker are not consistently maintained and updated. Just because there 
is a PR attached  to an issue doesn’t mean that it would be applicable today to 
all the versions selected in the issue.
  
A more accurate approach is to look at open PRs that are either explicitly targeted for 3.7 or which have the “needs backport to 3.7” label.  By those metrics, we currently have no open 3.7-specific PRs (the last was merged yesterday) and there are 60 open PRs with the 3.7 backport label. But even that number is high because some of those will end up not getting merged to master at all, and thus not backported, and others will be merged to master for 3.10 and perhaps to 3.9 but deemed inappropriate to backport to 3.8 and/or 3.7.


I would doubt the quality of tags maintenance at Github, too. E.g. https://github.com/python/cpython/pull/12131 is labeled 3.7 and 3.8 at 
BPO but has no backport tags whatsoever at GH.

So the search you gave is clearly insufficient.


https://github.com/python/cpython/pulls?utf8=✓=is%3Apr+is%3Aopen+base%3A3.7

https://github.com/python/cpython/pulls?utf8=✓=is%3Apr+is%3Aopen+label%3A%22needs+backport+to+3.7%22

   --
 Ned Deily
 n...@python.org -- []
--
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/55NOEOVOTQUJYXCKGEAULIDY7I22BPRJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x

[Ivan Pozdeev via Python-Dev]

Why not take a look at the list of open issues for 3.7 with PRs then? There are 
702 as of now.

https://bugs.python.org/issue?%40sort0=creation&%40sort1=&%40group0=&%40group1=&%40columns=title%2Cid%2Cactivity%2Cstatus&%40filter=status%2Cversions%2Cstage=1=21=4&%40pagesize=50&%40startwith=0

On 12.06.2020 11:17, Ned Deily wrote:

We will be accecpting commits to the 3.7 branch until this coming Monday 06-15 
23:59 AOE. At that time, 3.7 will effectively enter security-fix mode. That 
will also be the deadline for any additional security-fixes for release in 
3.6.11. Release candidates will follow shortly thereafter. Assuming no 
release-blocker issues arise during the release candidate testing, 3.7.8 and 
3.6.11 will release on 06-27.

https://discuss.python.org/t/upcoming-cutoffs-for-3-9-3-8-3-7-and-3-6-releases-last-chance-for-3-7-bugfixes/4362

--
   Ned Deily
   n...@python.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/EKYBL5VG6TWSTTQUNBP56VJVHDR3GRM3/
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/OYXTIA7JJEAGJAH57OJWLDQKG5QTMHQZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Repr: where to place the address and additional info?

[Ivan Pozdeev via Python-Dev]

If you are going to give details, you'd better use the "equivalent expression" kind of repr. As I explained earlier in the "Enum._convert 
should change __repr__", the angle brackets repr doesn't actually give any information that the user can rely upon except the type and the 
address.


On 29.05.2020 23:02, Serhiy Storchaka wrote:

The default repr of Python object is formatted using the following pattern:

    <{typename} object at {address:#x}>

And many custom reprs use similar patterns, but add some additional type specific information. The type name first, followed by details 
and address. All is surrounded by angle quotes. The question is in what order to show address and other details? Should the address be at 
rear or in the middle?


    <{typename} {details} at {address:#x}>
    <{typename} at {address:#x} {details}>

There are examples of both ways in the stdlib. I am going to add new custom 
reprs [1] and need to know what pattern looks better.

Also, is "object" mandatory after the type name?

    <{typename} object {details} at {address:#x}>
    <{typename} object at {address:#x} {details}>

[1] https://bugs.python.org/issue24391
___
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/ANF7LRGBQ2AWP2KUJKHVY3GGQRH6PDYD/
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/2SK5LUEC6UZVFVCZF45W2BO7KPR2Y24Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Improvement to SimpleNamespace

[Ivan Pozdeev via Python-Dev]

On 16.04.2020 0:34, Glenn Linderman wrote:

On 4/15/2020 12:47 PM, Ivan Pozdeev via Python-Dev wrote:
When writing a proof-of-concept implementation, however, I bumped into the need to distinguish which of the child objects are containers 
(thus need to be wrapped as well) and which are the leaves (thus need to be returned as is). I guess this is going to be 
application-specific. And the same problem will arise with any implementation, not only a wrapper.


Do the child objects truly need to be wrapped, or just accessed?


They need to be wrapped on the fly, to support nested  ".key" accesses.



Thanks for your comments though, they inspired a thought.

The problem with the glom syntax versus the dotted syntax is that the minimal 
syntax is bulky.

obj.abc.def.ghi versus   glom( obj, 'abc.def.ghi')

The problem with attribute syntax is the conflict with regular attributes, and the limitation of valid identifier characters. Glom 
probably doesn't have these problems.


"Glom syntax" still excludes the delimiter, whatever it is, from use in keys. 
So it's still a further limitation compared to the JSON spec.



So my new thought is that we need a new syntax.  The minimal existing syntax 
might be

obj._('abc.def.ghi')     or maybe   obj['abc.def.ghi']

although the latter would conflict with regular dict lookups, but obj isn't a 
regular dict, so that might not matter.


A new syntax might be:

obj.'abc.def.ghi'


In any of these syntaxes, one could enhance it to use variables in some spots similarly to f-strings (but from the beginning, so no 'f' 
would be required)


foo = 'def'
obj.'abc.{foo}.ghi'

would access the same item as previous examples.
___
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/3A5V62LY3DAPAREZMB7MVRYX4432NR7F/
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/76BY73UZRU2QUTEMDQDD6J4TIVSOWKJ7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Improvement to SimpleNamespace

[Ivan Pozdeev via Python-Dev]

First of all, be aware of the limitations of this approach (which will need to 
be clearly documented if we go this way):

 * It only allows valid Python identifiers -- while JSON accepts any sequence 
of Unicode characters for keys
   (http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf, 
p.5)
 * It will clash with any regular attributes of whatever type implements this 
senantic
 * It's not very scalable and will upset static code checkers and IDEs as it's 
impossible to determine if the attribute name is valid or
   provide typing hints


Now, I think it's possible to make a class that would /wrap/ an existing 
mapping.
This would completely decouple the convenience syntax from the storage 
semantics and any specific modules and types.

When writing a proof-of-concept implementation, however, I bumped into the need to distinguish which of the child objects are containers 
(thus need to be wrapped as well) and which are the leaves (thus need to be returned as is). I guess this is going to be 
application-specific. And the same problem will arise with any implementation, not only a wrapper.


On 15.04.2020 5:59, Raymond Hettinger wrote:

SimpleNamespace() is really good at giving attribute style-access. I would like 
to make that functionality available to the JSON module (or just about anything 
else that accepts a custom dict) by adding the magic methods for mappings so 
that this works:

  catalog = json.load(f, object_hook=SimpleNamespace)
  print(catalog['clothing']['mens']['shoes']['extra_wide']['quantity']) 
 # currently possible with dict()
  print(catalog.clothing.mens.shoes.extra_wide.quantity]) # 
proposed with SimpleNamespace()
  print(catalog.clothing.boys['3t'].tops.quantity   
# would also be supported

I've already seen something like this in production; however, people are having 
to write custom subclasses to do it.  This is kind of bummer because the custom 
subclasses are a pain to write, are non-standard, and are generally somewhat 
slow.  I would like to see a high-quality version this made more broadly 
available.

The core idea is keep the simple attribute access but make it easier to load 
data programmatically:

 >>> ns = SimpleNamespace(roses='red', violets='blue')
 >>> thing = input()
 sugar
 >>> quality = input()
 sweet
 >>> setattr(ns, thing, quality)# current
 >>> ns['sugar'] = 'sweet'   # proposed

If the PEP 584 __ior__ method were supported, updating a SimpleNamespace would 
be much cleaner:

   ns |= some_dict

I posted an issue on the tracker: https://bugs.python.org/issue40284 .  There 
was a suggestion to create a different type for this, but I don't see the point 
in substantially duplicating everything SimpleNamespace already does just so we 
can add some supporting dunder methods.   Please add more commentary so we can 
figure-out the best way to offer this powerful functionality.


Raymond


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

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

[Ivan Pozdeev via Python-Dev]

On 10.04.2020 20:20, Victor Stinner wrote:

Hi,

Here is a first draft a PEP which summarize the research work I'm
doing on CPython C API since 2017 and the changes that me and others
already made since Python 3.7 towards an "opaque" C API. The PEP is
also a collaboration with developers of PyPy, HPy, Rust-CPython and
many others! Thanks to everyone who helped me to write it down!

Maybe this big document should be reorganized as multiple smaller
better defined goals: as multiple PEPs. The PEP is quite long and
talks about things which are not directly related. It's a complex
topic and I chose to put everything as a single document to have a
good starting point to open the discussion. I already proposed some of
these ideas in 2017: see the Prior Art section ;-)

The PEP can be read on GitHub where it's better formatted:
https://github.com/vstinner/misc/blob/master/cpython/pep-opaque-c-api.rst

If someone wants to work on the PEP itself, the document on GitHub is
the current reference.

Victor



PEP xxx: Modify the C API to hide implementation details


Abstract


* Hide implementation details from the C API to be able to `optimize
   CPython`_ and make PyPy more efficient.
* The expectation is that `most C extensions don't rely directly on
   CPython internals`_ and so will remain compatible.
* Continue to support old unmodified C extensions by continuing to
   provide the fully compatible "regular" CPython runtime.
* Provide a `new optimized CPython runtime`_ using the same CPython code
   base: faster but can only import C extensions which don't use
   implementation details. Since both CPython runtimes share the same
   code base, features implemented in CPython will be available in both
   runtimes.
* `Stable ABI`_: Only build a C extension once and use it on multiple
   Python runtimes and different versions of the same runtime.
* Better advertise alternative Python runtimes and better communicate on
   the differences between the Python language and the Python
   implementation (especially CPython).

Note: Cython and cffi should be preferred to write new C extensions.
This PEP is about existing C extensions which cannot be rewritten with
Cython.


Rationale
=

To remain competitive in term of performance with other programming
languages like Go or Rust, Python has to become more efficient.

Make Python (at least) two times faster
---

The C API leaks too many implementation details which prevent optimizing
CPython. See `Optimize CPython`_.

PyPy's support for Python's C API (pycext) is slow because it has to
emulate CPython internals like memory layout and reference counting. The
emulation causes memory overhead, memory copies, conversions, etc. See
`Inside cpyext: Why emulating CPython C API is so Hard
`_
(Sept 2018) by Antonio Cuni.

While this PEP may make CPython a little bit slower in the short term,
the long-term goal is to make "Python" at least two times faster. This
goal is not hypothetical: PyPy is already 4.2x faster than CPython and is
fully compatible. C extensions are the bottleneck of PyPy. This PEP
proposes a migration plan to move towards opaque C API which would make
PyPy faster.

Separated the Python language and the CPython runtime (promote
alternative runtimes)


The Python language should be better separated from its runtime. It's
common to say "Python" when referring to "CPython". Even in this PEP :-)

Because the CPython runtime remains the reference implementation, many
people believe that the Python language itself has design flaws which
prevent it from being efficient. PyPy proved that this is a false
assumption: on average, PyPy runs Python code 4.2 times faster than
CPython.

One solution for separating the language from the implementation is to
promote the usage of alternative runtimes: not only provide the regular
CPython, but also PyPy, optimized CPython which is only compatible with
C extensions using the limited C API, CPython compiled in debug mode to
ease debugging issues in C extensions, RustPython, etc.

To make alternative runtimes viable, they should be competitive in term
of features and performance. Currently, C extension modules remain the
bottleneck for PyPy.

Most C extensions don't rely directly on CPython internals
--

While the C API is still tidely coupled to CPython internals, in
practical, most C extensions don't rely directly on CPython internals.

The expectation is that these C extensions will remain compatible with
an "opaque" C API and only a minority of C extensions will have to be
modified.

Moreover, more and more C extensions are implemented in Cython or 

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

[Ivan Pozdeev via Python-Dev]

On 26.03.2020 19:24, Ethan Furman wrote:

On 03/25/2020 06:53 PM, Ivan Pozdeev via Python-Dev wrote:


A diagnostic is always done by the same algorithm:

1) Identify the exact place in code where the problem manifests itself
2) Examine the state of the program at that moment to find out which if the 
values are wrong
3) Track the wrong value back to its origin

Seeing an accurate repr() is required for step 2) -- to immediately detect if 
it's wrong or not.


Before Enum, the repr for socket.AF_UNIX was:

1

Not very useful for debugging.


On the contrary, it's perfect. I know everything I need: it's an integer 
constant, end of story.

When examining some live object, I would probably see that "1" and won't even 
need to look anything up to know what I'm dealing with.



If a repr() points to a reference rather than definition, I don't really know anything about the object that I'm looking at: that 
reference could as well be wrong, or could have been wrong at any moment in the past. I.e. such a repr() has negative informativity.


Whether it's

  

or

  

it has light-years more information than it used to  (okay, maybe only 
light-minutes  ;) )


More information is not better if that information is harmful rather than 
helpful.


Finding the definition, as opposed to merely a reference, is required for step 
3).


Before Enum, if you had tried to find AF_UNIX and did a full Lib/*.py search you would have found some comments and a couple lines of code 
-- never a definition.  And that's assuming you made the leap from 1 to AF_UNIX.


You should add searching for

  from ... import *

to your debugging list, because then you'll find:

  from _socket import *

To identify which code could have adversely affected the object's value, I must find both its implementation (for potential internal 
offenders) and references to it and objects of this type in general (for potential external offenders).


Finding the implementation might be a bit trickier with `socket.AF_UNIX', 
however:

$ grep AddressFamily.AF_UNIX *.py
...(crickets)...


I would rather search for "AddressFamily" (case-sensitive), and in the entire codebase, 
not just "*.py".
Long story short, this is a type name and looks like a very distinctive one. So that search is very likely going to readily find me anything 
directly related to that type, including its definition, with negligible noise -- however and wherever it's done.


I hope this serves as yet another demonstration why knowing the exact type is 
so crucial.


$ grep socket.AF_UNIX *.py
smtplib.py:    self.sock = socket.socket(socket.AF_UNIX, 
socket.SOCK_STREAM)
socketserver.py:    address_family = socket.AF_UNIX
socketserver.py:    address_family = socket.AF_UNIX
webbrowser.py:    s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)

Considering that stdlib Enums are almost all globally unique, and Enums created with _convert *are* globally unique, I think seeing the 
module instead of the class name is more helpful.

Speaking of which, adding help() to your debugging list would also be, um, 
helpful:

  --> help(socket.AF_UNIX)
  Help on AddressFamily in module socket object:

  class AddressFamily(enum.IntEnum)
   |  AddressFamily(value, names=None, *, module=None, qualname=None, 
type=None, start=1)
   |
   |  An enumeration.
   |
   |  ...


Examining repr() of a large number of objects (think dozens to hundreds) vs 
help() of each of them? I think we have a winner...
And help() doesn't even show the value!

You can't be serious suggesting me to do all this extra work (i.e. single-handedly increase diagnostic's labor intensity about 5x -- while 
problem diagnostic is a key activity during both development and ongoing use) just because someone wishes to playfully ignore an established 
standard specifically invented to make it unnecessary.


Pardon me if I misunderstood you, but I also find the offhand remarks: "adding this and that to your debugging list would also be, um, 
helpful" -- highly condescending and insulting and showing that you probably don't do much problem diagnostic and don't care at all about 
anyone who does -- i.e. about software developers and maintainers, your core audience.
All the while yourself being a Python core developer (if your StackOverflow profile is to be believed) -- a spokesperson for the dev team 
and a shining example of what every Python developer should strive to be.
If this is any representation of the prevalent attitude in the core team now, I'm probably wasting my time arguing here as well as 
supporting Python in general since our values clearly don't match anymore.




As a reminder, the change under discussion only affects enums created from 
globally unique constants using the Enum._convert helper utility.


I know. But it sets a precedent of screwing users over with poorly thought 
cosmetic changes done without thinking of them.
It becoming a pattern is the absolut

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

[Ivan Pozdeev via Python-Dev]

On 26.03.2020 11:59, Serhiy Storchaka wrote:

26.03.20 01:35, Ivan Pozdeev via Python-Dev пише:
E. g. in this case, AF_UNIX is a member of some entity called "AddressFamily" -- so I would search the code for "AddressFamily" to see 
what I'm looking at and what else I can do with it. The fact that it's also directly availabe from the `socket` module is incidental: it 
could be as easily made available from anywhere else -- not even a module.


AF_UNIX is and always was available from the socket module. It is not incidental. AddressFamily is an implementation detail, it is just a 
way to add fanny repr and other properties to this constant. In any case the information about AddressFamily and its members will be kept 
in the help output.


See my earlier replies to Chris Angelico why showing the implementation matters for repr() and how this misrepresentation breaks the 
documented repr() standard and debugging.



___
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/NNBYZBV7YAXKSSNDZIHK54F3XGBSFZMV/
Code of Conduct: http://python.org/psf/codeofconduct/
--
Regards,
Ivan



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

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

[Ivan Pozdeev via Python-Dev]

On 26.03.2020 4:10, Chris Angelico wrote:

On Thu, Mar 26, 2020 at 12:08 PM Ivan Pozdeev via Python-Dev
 wrote:


On 26.03.2020 2:41, Chris Angelico wrote:

On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev
 wrote:

I'm skeptical about anything that hides an object's "true nature": this is a 
major landmine in diagnostics because it lies to you about what
you are looking at and where to look for its implementation.

E. g. in this case, AF_UNIX is a member of some entity called "AddressFamily" -- so I 
would search the code for "AddressFamily" to see what
I'm looking at and what else I can do with it. The fact that it's also directly 
availabe from the `socket` module is incidental: it could be
as easily made available from anywhere else -- not even a module.


But if it's described as socket.AF_UNIX then you know where to go
looking for it,

No, I don't. https://docs.python.org/3/library/functions.html#repr sets the 
standard -- thus the expectation -- for user-defined types:
"...otherwise the representation is a string enclosed in angle brackets that 
contains the name of the type of the object together with
additional information often including the name and address of the object" -- 
which this suggestion would be breaking.

By this standard, "socket.AF_UNIX" looks like something defined directly at 
module level. So I'll be looking for a definition at module
level -- and not find it. At which point, I'd suspect shenanigans like a 
dynamic creation or assignment. Which can be absolutely anywhere!
And I'll be looking for the wrong thing still!


"""For many types, this function makes an attempt to return a string
that would yield an object with the same value when passed to
eval()..."""

That clause is for the case without angle brackets.
Then repr() must be exactly "socket.AF_INET", full stop. I.e. it will lose the 
integer value display.

socket.AF_UNIX



If the repr were "socket.AF_UNIX", then that would indeed be a string
that would yield an object with the same value. The current repr isn't
wrong by this definition, but nor is the proposed change. Is it
defined at module level? I couldn't care less; all that matters is
that it is *accessible* at module level.
Well, I do care a lot. For diagnostics, this is a critical distinction. An object is defined in one, fixed, place (even if you overwrite 
module contents, it retains lexical scope) and can be made, dynamically, accessible in any number of completely unrelated places.


A diagnostic is always done by the same algorithm:

1) Identify the exact place in code where the problem manifests itself
2) Examine the state of the program at that moment to find out which if the 
values are wrong
3) Track the wrong value back to its origin

Seeing an accurate repr() is required for step 2) -- to immediately detect if 
it's wrong or not.
If a repr() points to a reference rather than definition, I don't really know anything about the object that I'm looking at: that reference 
could as well be wrong, or could have been wrong at any moment in the past. I.e. such a repr() has negative informativity.


Finding the definition, as opposed to merely a reference, is required for step 3). To identify which code could have adversely affected the 
object's value, I must find both its implementation (for potential internal offenders) and references to it and objects of this type in 
general (for potential external offenders).




I don't have to say
"socket.AddressFamily.AF_UNIX".

ChrisA
___
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/4Q7SVP6ZXR4SAPMDWYGPH7OWX5YXI44M/
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/QXK7NEYVSRVLXGV6TWC42K7BPEZOLVCZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

[Ivan Pozdeev via Python-Dev]

On 26.03.2020 2:41, Chris Angelico wrote:

On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev
 wrote:

I'm skeptical about anything that hides an object's "true nature": this is a 
major landmine in diagnostics because it lies to you about what
you are looking at and where to look for its implementation.

E. g. in this case, AF_UNIX is a member of some entity called "AddressFamily" -- so I 
would search the code for "AddressFamily" to see what
I'm looking at and what else I can do with it. The fact that it's also directly 
availabe from the `socket` module is incidental: it could be
as easily made available from anywhere else -- not even a module.


But if it's described as socket.AF_UNIX then you know where to go
looking for it,


No, I don't. https://docs.python.org/3/library/functions.html#repr sets the standard -- thus the expectation -- for user-defined types: 
"...otherwise the representation is a string enclosed in angle brackets that contains the name of the type of the object together with 
additional information often including the name and address of the object" -- which this suggestion would be breaking.


By this standard, "socket.AF_UNIX" looks like something defined directly at module level. So I'll be looking for a definition at module 
level -- and not find it. At which point, I'd suspect shenanigans like a dynamic creation or assignment. Which can be absolutely anywhere! 
And I'll be looking for the wrong thing still!



and type() can tell you the type if you actually needit.


That's an additional, unnecessary, nonstandard step that I somehow need to know to make because this is not standard practice, as per above. 
I do not expect such treachery, I expect repr() to give me truthful and accurate information!


And even once I begin expecting it and additionally checking type() of everything that I examine from that point on (since I'll know that 
Python has crossed the line, I cannot trust repr() of anything any longer), that is lots of extra work, totally unwelcome and uncalled for! 
All for a tiny benefit, in one niche case.


+1 for changing the socket enums; -1 for changing enums in general.

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

[Python-Dev] Re: Enum._convert should change __repr__ and/or __str__ to use module name instead of class name

[Ivan Pozdeev via Python-Dev]

I'm skeptical about anything that hides an object's "true nature": this is a major landmine in diagnostics because it lies to you about what 
you are looking at and where to look for its implementation.


E. g. in this case, AF_UNIX is a member of some entity called "AddressFamily" -- so I would search the code for "AddressFamily" to see what 
I'm looking at and what else I can do with it. The fact that it's also directly availabe from the `socket` module is incidental: it could be 
as easily made available from anywhere else -- not even a module.


On 25.03.2020 22:54, Ethan Furman wrote:

Serhiy had the idea of having Enum._convert also modify the __str__ and
__repr__ of newly created enumerations to display the module name instead
of the enumeration name (https://bugs.python.org/msg325007):

--> socket.AF_UNIX
   ==>  

--> print(socket.AF_UNIX)
AddressFamily.AF_UNIX    ==>  socket.AF_UNIX

Thoughts?

--
~Ethan~
___
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/GMOJRM4GPJJJSBYFR4RZSDBVB2SYJAM4/
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/M2TLOP7O6JSQK5XXKIS6INUXYDONRWV5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Ivan Pozdeev via Python-Dev]

On 22.03.2020 7:46, Steven D'Aprano wrote:

On Sun, Mar 22, 2020 at 06:57:52AM +0300, Ivan Pozdeev via Python-Dev wrote:


Does it need to be separate methods?

Yes.

Overloading a single method to do two dissimilar things is poor design.

They are similar. We're removing stuff from an edge in both cases. The only difference is whether input is treated as a character set or as 
a raw substring.

As written in the PEP preface, the very reason for the PEP is that people
are continuously trying to use *strip methods for the suggested
functionality -- which shows that this is where they are expecting to find
it.

They are only expecting to find it in strip() because there is no other
alternative where it could be. There's nothing inherent about strip that
means to delete a prefix or suffix, but when the only other choices are
such obviously wrong methods as upper(), find(), replace(), count() etc
it is easy to jump to the wrong conclusion that strip does what is
wanted.




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

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Ivan Pozdeev via Python-Dev]

On 22.03.2020 6:38, Guido van Rossum wrote:

On Sat, Mar 21, 2020 at 6:46 PM Nick Coghlan mailto:ncogh...@gmail.com>> wrote:

On Sat., 21 Mar. 2020, 11:19 am Nathaniel Smith, mailto:n...@pobox.com>> wrote:

On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
mailto:sweeney.dennis...@gmail.com>> 
wrote:
> This is a proposal to add two new methods, ``cutprefix`` and
> ``cutsuffix``, to the APIs of Python's various string objects.

The names should use "start" and "end" instead of "prefix" and
"suffix", to reduce the jargon factor and for consistency with
startswith/endswith.


This would also be more consistent with startswith() & endswith(). (For folks 
querying this: the relevant domain here is "str builtin
method names", and we already use startswith/endswith there, not 
hasprefix/hassuffix. The most challenging relevant audience for new
str builtin method *names* is also 10 year olds learning to program in 
school, not adults reading the documentation)


To my language sense, hasprefix/hassuffix are horrible compared to startswith/endswith. If you were to talk about this kind of condition 
using English instead of Python, you wouldn't say "if x has prefix y", you'd say "if x starts with y". (I doubt any programming language 
uses hasPrefix or has_prefix for this, making it a strawman.)


*But*, what would you say if you wanted to express the idea or removing something from the start or end? It's pretty verbose to say 
"remove y from the end of x", and it's not easy to translate that into a method name. x.removefromend(y)? Blech! And x.removeend(y) has 
the double 'e', which confuses the reader.


The thing is that it's hard to translate "starts" (a verb) into a noun -- the "start" of something is its very beginning (i.e., in Python, 
position zero), while a "prefix" is a noun that specifically describes an initial substring (and I'm glad we don't have to use *that* :-).


I think the concern about stripstart() & stripend() working with 
substrings, while strip/lstrip/rstrip work with character sets, is
valid, but I also share the concern about introducing "cut" as yet another 
verb to learn in the already wide string API.


It's not great, and I actually think that "stripprefix" and "stripsuffix" are reasonable. (I found that in Go, everything we call "strip" 
is called "Trim", and there are "TrimPrefix" and "TrimSuffix" functions that correspond to the PEP 616 functions.)


I must note that names conforming to https://www.python.org/dev/peps/pep-0008/#function-and-variable-names would be "strip_prefix" and 
"strip_suffix".



The example where the new function was used instead of a questionable use 
of replace gave me an idea, though: what if the new
functions were "replacestart()" and "replaceend()"?

* uses "start" and "with" for consistency with the existing checks
* substring based, like the "replace" method
* can be combined with an extension of "replace()" to also accept a tuple 
of old values to match and replace to allow for consistency
with checking for multiple prefixes or suffixes.

We'd expect the most common case to be the empty string, but I think the 
meaning of the following is clear, and consistent with the
current practice of using replace() to delete text from anywhere within the 
string:

    s = s.replacestart('context.' , '')


This feels like a hypergeneralization. In 99.9% of use cases we just need to remove the prefix or suffix. If you want to replace the 
suffix with something else, you can probably use string concatenation. (In the one use case I can think of, changing "foo.c" into "foo.o", 
it would make sense that plain "foo" ended up becoming "foo.o", so s.stripsuffix(".c") + ".o" actually works better there.


This approach would also very cleanly handle the last example from the PEP:

    s = s.replaceend(('Mixin', 'Tests', 'Test'), '')


Maybe the proposed functions can optionally take a tuple of prefixes/suffixes, 
like startswith/endswith do?

The doubled 'e' in 'replaceend' isn't ideal, but if we went this way, I 
think keeping consistency with other str method names would be
preferable to adding an underscore to the name.


Agreed on the second part, I just really don't like the 'ee'.

Interestingly, you could also use this to match multiple prefixes or 
suffixes and find out *which one* matched (since the existing
methods don't report that):

    s2 = s.replaceend(suffixes, '')
    suffix_len = len(s) - len(s2)
    suffix = s[-suffix-len:] if suffix_len else None

Cheers,
Nick.


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

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Ivan Pozdeev via Python-Dev]

On 20.03.2020 21:52, Dennis Sweeney wrote:

Browser Link: https://www.python.org/dev/peps/pep-0616/

PEP: 616
Title: String methods to remove prefixes and suffixes
Author: Dennis Sweeney 
Sponsor: Eric V. Smith 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 19-Mar-2020
Python-Version: 3.9
Post-History: 30-Aug-2002


Abstract


This is a proposal to add two new methods, ``cutprefix`` and
``cutsuffix``, to the APIs of Python's various string objects.  In
particular, the methods would be added to Unicode ``str`` objects,
binary ``bytes`` and ``bytearray`` objects, and
``collections.UserString``.


Does it need to be separate methods? Can we augment or even replace *strip() 
instead?

E.g.

*strip(chars: str, line: str) -> str

As written in the PEP preface, the very reason for the PEP is that people are continuously trying to use *strip methods for the suggested 
functionality -- which shows that this is where they are expecting to find it.


(as a bonus, we'll be saved from bikeshedding debates over the names)

---

Then, https://mail.python.org/archives/list/python-id...@python.org/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/ suggests that the use of strip 
with character set argument may have fallen out of favor since its adoption.


If that's the case, it can be deprecated in favor of the new use, thus saving 
us from extra complexity in perspective.



If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has
been removed.  If ``s`` does not have ``pre`` as a prefix, an
unchanged copy of ``s`` is returned.  In summary, ``s.cutprefix(pre)``
is roughly equivalent to ``s[len(pre):] if s.startswith(pre) else s``.

The behavior of ``cutsuffix`` is analogous: ``s.cutsuffix(suf)`` is
roughly equivalent to
``s[:-len(suf)] if suf and s.endswith(suf) else s``.


Rationale
=

There have been repeated issues [#confusion]_ on the Bug Tracker
and StackOverflow related to user confusion about the existing
``str.lstrip`` and ``str.rstrip`` methods.  These users are typically
expecting the behavior of ``cutprefix`` and ``cutsuffix``, but they
are surprised that the parameter for ``lstrip`` is interpreted as a
set of characters, not a substring.  This repeated issue is evidence
that these methods are useful, and the new methods allow a cleaner
redirection of users to the desired behavior.

As another testimonial for the usefulness of these methods, several
users on Python-Ideas [#pyid]_ reported frequently including similar
functions in their own code for productivity.  The implementation
often contained subtle mistakes regarding the handling of the empty
string (see `Specification`_).


Specification
=

The builtin ``str`` class will gain two new methods with roughly the
following behavior::

 def cutprefix(self: str, pre: str, /) -> str:
 if self.startswith(pre):
 return self[len(pre):]
 return self[:]
 
 def cutsuffix(self: str, suf: str, /) -> str:

 if suf and self.endswith(suf):
 return self[:-len(suf)]
 return self[:]

The only difference between the real implementation and the above is
that, as with other string methods like ``replace``, the
methods will raise a ``TypeError`` if any of ``self``, ``pre`` or
``suf`` is not an instace of ``str``, and will cast subclasses of
``str`` to builtin ``str`` objects.

Note that without the check for the truthyness of ``suf``,
``s.cutsuffix('')`` would be mishandled and always return the empty
string due to the unintended evaluation of ``self[:-0]``.

Methods with the corresponding semantics will be added to the builtin
``bytes`` and ``bytearray`` objects.  If ``b`` is either a ``bytes``
or ``bytearray`` object, then ``b.cutsuffix()`` and ``b.cutprefix()``
will accept any bytes-like object as an argument.

Note that the ``bytearray`` methods return a copy of ``self``; they do
not operate in place.

The following behavior is considered a CPython implementation detail,
but is not guaranteed by this specification::

 >>> x = 'foobar' * 10**6
 >>> x.cutprefix('baz') is x is x.cutsuffix('baz')
 True
 >>> x.cutprefix('') is x is x.cutsuffix('')
 True

That is, for CPython's immutable ``str`` and ``bytes`` objects, the
methods return the original object when the affix is not found or if
the affix is empty.  Because these types test for equality using
shortcuts for identity and length, the following equivalent
expressions are evaluated at approximately the same speed, for any
``str`` objects (or ``bytes`` objects) ``x`` and ``y``::

 >>> (True, x[len(y):]) if x.startswith(y) else (False, x)
 >>> (True, z) if x != (z := x.cutprefix(y)) else (False, x)


The two methods will also be added to ``collections.UserString``,
where they rely on the implementation of the new ``str`` methods.


Motivating examples from the Python standard library

[Python-Dev] Re: [bpo-22699] Cross-compiling and fixing sysconfig

[Ivan Pozdeev via Python-Dev]

Last time I checked, distutils didn't support compilation for anything but the 
running Python instance, nor was it intended to. Should it?
If not, the efforts look misplaced, you should rather use a toolchain that 
does...

On 19.03.2020 23:22, Steve Dower wrote:
So over on https://bugs.python.org/issue22699 I've been talking to myself as I figure out all the ways that cross-compiling (on Ubuntu, 
targeting another Linux distro via an SDK) fails.


In short, it's either because sysconfig can't provide details about any CPython install other than the currently running one, or it's 
because our setup.py (for building the CPython extension modules) uses sysconfig.


Either way, I'm not about to propose a rewrite to fix either of them without finding those who are most involved in these areas. Please 
come join me on the bug.


Thanks,
Steve
___
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/6DBYMDCDLOS245XK57BD3E2GXGVDMBPX/
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/LFW7HQDBE4QZBO6GGTCYFEMOWHW6FA7L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Ivan Pozdeev via Python-Dev]

On 24.02.2020 8:30, Kyle Stanley wrote:
> (What is it with typos anyway? Why do people feel the need to invoke megabytes if not gigabytes of internet traffic to correct a word 
that every reader can easily correct in their mind?)


Speaking from personal experience to some degree, my first PR was an incredibly minimal documentation enhancement: 
https://github.com/python/cpython/pull/14069. It's not exactly a typo fix, but in retrospect, I'd consider it to be about equally 
impactful. I can't speak for everyone, but my own motivation was to do something very mildly helpful just to get a feel for the workflow. 
It eventually led to increasingly involved contributions. (:


I think some people might also consider grammatical corrections to be helpful for bolstering the "professionalism" of the documentation a 
bit, but it's hard to say for sure.


I can affirm that. Nothing says "amateurish" and "neglectful" like glaring grammatical errors. It shows that the author doesn't care about 
their users' convenience and likes to waste their time (the text _can_ be read but it's significantly _harder_ to read and otherwise use), 
and that other aspects of the work are likely similarly chaotic.


It's not even uncommon when they make the meaning unclear. Or e.g. typos or inconsistency in a term make it hard to locate other references 
to it or deduce if the phrase is being used as a term or as a common phrase.


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

[Python-Dev] Re: Merging PRs without CLA signed

[Ivan Pozdeev via Python-Dev]

On 24.02.2020 7:07, Kyle Stanley wrote:


For a full list of merged PRs to CPython with a "CLA not signed" label, see the following: 
https://github.com/python/cpython/pulls?utf8=%E2%9C%93=is%3Apr+state%3Amerged+label%3A%22CLA+not+signed%22


Note that if you open a PR, and _then_ sign the CLA, the label is not updated (at least, that's what I experienced before I did). So this 
list is likely inaccurate.

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

[Python-Dev] Merge bugs.python.org accounts

[Ivan Pozdeev via Python-Dev]

Who should I contact on subj? BPO UI doesn't have any contact information.

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

[Python-Dev] Re: Are PyObject_RichCompareBool shortcuts part of Python or just CPython quirks?

[Ivan Pozdeev via Python-Dev]

On 24.01.2020 5:36, Guido van Rossum wrote:

Good question!

I think this started with a valuable optimization for `x in `. I don't know if that was ever carefully documented, but I remember 
that it was discussed a few times (and IIRC Raymond was adamant that this should be so optimized -- which is reasonable).


I'm tempted to declare this implementation-defined behavior -- *implicit* calls to __eq__ and __ne__ *may* be skipped if both sides are 
the same object depending on the whim of the implementation.


This cannot be an implementation detail because it changes the outcome of 
operations.
Without it, things like `math.nan in seq` would always return False.
So it's not even an "optimization" but rather "behavior".

IMO a user should not rely on __eq__ to be called at any time so we shouldn't 
document that it could be skipped or whatever.

Instead, we should document that `in` (and whatever other public API uses PyObject_RichCompareBool) compares by identity first (and this is 
intended because `math.nan in seq` returning True if there are NaNs is more practical in the general case).




We should probably also strongly recommend that __eq__ and __ne__ not do what 
math.nan does.

However we cannot stop rich compare __eq__ implementations that return arrays of pairwise comparisons, since numpy does this. (And yes, it 
seems that this means that `x in y` is computed incorrectly if x is an array with such an __eq__ implementation and y is a tuple of such 
objects. I'm sure there's a big warning somewhere in the numpy docs about this, and I presume if y is a numpy array they make sure to do 
something better.)


On Thu, Jan 23, 2020 at 5:33 PM Tim Peters mailto:tim.pet...@gmail.com>> wrote:

PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut:  if x
and y are the same object, then equality comparison returns True and
inequality False.  No attempt is made to execute __eq__ or __ne__
methods in those cases.

This has visible consequences all over the place, but they don't
appear to be documented.  For example,

>>> import math
>>> ([math.nan] * 5).count(math.nan)
5

despite that `math.nan == math.nan` is False.

It's usually clear which methods will be called, and when, but not
really here.  Any _context_ that calls PyObject_RichCompareBool()
under the covers, for an equality or inequality test, may or may not
invoke __eq__ or __ne__, depending on whether the comparands are the
same object.  Also any context that inlines these special cases to
avoid the overhead of calling PyObject_RichCompareBool() at all.

If it's intended that Python-the-language requires this, that needs to
be documented.

Or if it's implementation-defined, then _that_ needs to be documented.

Which isn't straightforward in either case, in part because
PyObject_RichCompareBool isn't a language-level concept.

This came up recently when someone _noticed_ the list.count(NaN)
behavior, and Victor made a PR to document it:

https://github.com/python/cpython/pull/18130

I'm pushing back, because documenting it _only_ for .count() makes
.count() seem unique in a way it isn't, and doesn't resolve the
fundamental issue:  is this language behavior, or implementation
behavior?

Which I don't want to argue about.  But you certainly should ;-)
___
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/3ZAMS473HGHSI64XB3UV4XBICTG2DKVF/
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 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/X4ZIICG2EBMYPFUASI5TW4E6PIT2KR6M/
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/YKZYSRV2MJRBSMOBXB2BROKJIGLAN37U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Ivan Pozdeev via Python-Dev]

On 24.01.2020 11:08, Serhiy Storchaka wrote:

23.01.20 17:20, Victor Stinner пише:

Incompatible changes which require "if : (...) else: (...)"
or "try:  except (...): ":

* Removed tostring/fromstring methods in array.array and base64 modules
* Removed collections aliases to ABC classes
* Removed fractions.gcd() function (which is similar to math.gcd())
* Remove "U" mode of open(): having to use io.open() just for Python 2
makes the code uglier
* Removed old plistlib API: 2.7 doesn't have the new API


You had years to fix deprecation warnings in your code. And many projects did this long ago. If revert these removals in 3.9 because they 
break existing code we will have the same problem with removing them in 3.10, 13.11, etc.


I consider breaking unmaintained code is an additional benefit of removing deprecated features. For example pycrypto was unmaintained and 
insecure for 6 years, but has 4 million downloads per month. It will not work in 3.9 because of removing time.clock. Other example is 
nose, unmaintained for 5 years, and superseded by nose2.


AFAICS the justification for this proposition is the fact that the necessary fixes to existing code are much simpler if that code needs to 
support just 3.x-3.10 vs 2.7+3.x-3.10 .


In this light, with the breaking changes, we essentially tell the users: "abandon 
2.7 or do extra work".
Victor alleges that after a year, the option to abandon 2.7 and not do that 
extra work will be easier to choose.
So the dilemma is essentially how hard we push users to abandon 2.7 -- how much 
tax we incur on them for keeping its support.


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

[Python-Dev] Re: Why doesn't venv also install python3*-config?

[Ivan Pozdeev via Python-Dev]

On 13.01.2020 16:21, Daniel Haude wrote:


Am 12.01.2020 23:39 schrieb Ivan Pozdeev via Python-Dev:


Virtualenv does create `python-config` shim in Linux.


Python3 doesn't. Definetely. Not on RHEL7 and Debian, that's where I tested it.


You are right, I've got it mixed up. Virtualenv creates `python-config`. Venv 
doesn't.

$ pyenv local 3.6.9
$ pip install virtualenv
<...>
$ virtualenv test_vi
Using base prefix '/home/vmuser/.pyenv/versions/3.6.9'
New python executable in /home/vmuser/test_vi/bin/python3.6
Also creating executable in /home/vmuser/test_vi/bin/python
Installing setuptools, pip, wheel...
done.
$ python -m venv test_ve
$ ls test_ve/bin/
activate  activate.csh  activate.fish  easy_install easy_install-3.6  pip  pip3 
 pip3.6  python  python3
$ ls test_vi/bin/
activate  activate.fish  activate_this.py  easy_install pip   pip3.6  
python3    python-config
activate.csh  activate.ps1   activate.xsh  easy_install-3.6 pip3  python  
python3.6  wheel

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

[Python-Dev] Re: Why doesn't venv also install python3*-config?

[Ivan Pozdeev via Python-Dev]

On 12.01.2020 19:20, mus...@posteo.org wrote:

Hi guys,

after I got the whole list into a lather about the merits of
the python-config program, let me rephrase the question:

Is there a "canonical" way of automatically finding the correct
include files and Python runtime library when embedding the Python
interpreter, based on the current virtual environment (and not the
"installed" version)? Upon reding the docs there isn't.


 + '-config'

Is what 
https://docs.python.org/3/extending/embedding.html#compiling-and-linking-under-unix-like-systems
 seems to be suggesting to me.

This is not applicable to Windows


And maybe there
should't or cant be any. So if I want to try embedding Python under
different versions I have to either install those into different
directories and use python-config, or I write a trivial Python program
that finds the correct values for the current environment using
sysconfig and outpus those as compiler / linker flags. Easy enough, I
was just surprised that no such solution was already built into the
virtualenv setup mechanism


Virtualenv does create `python-config` shim in Linux.


Here's a quote from the docs
"""
If this procedure [using python-config] doesn’t work for you (it is not
guaranteed to work for all Unix-like platforms; however, we welcome bug
reports) you will have to read your system’s documentation about
dynamic linking and/or examine Python’s Makefile (use
sysconfig.get_makefile_filename() to find its location) and compilation
options. In this case, the sysconfig module is a useful tool to
programmatically extract the configuration values that you will want to
combine together. For example:


import sysconfig
sysconfig.get_config_var('LIBS')

'-lpthread -ldl  -lutil'

sysconfig.get_config_var('LINKFORSHARED')

'-Xlinker -export-dynamic'
"""
___
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/364Q6EZHSFN6DGUUDN3FKOMK4CDS3WJB/
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/EZ56AYUT52Y7PBV2ORHMFC7M4FNFWNE5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why doesn't venv also install python3*-config?

[Ivan Pozdeev via Python-Dev]

On 08.01.2020 14:26, Musbur wrote:

Hello,

I'm experimenting with package development on different versions of Python in different virtualenvs. After running "make" I don't do "make 
install", but rather I set up virtualenvs by running /path/to/source/python -m venv env_dir. This works for as long as I don't need to 
compile extensions. Once I do that I'm running into trouble because there is no python3-config binary in the venv, so it uses the "system" 
python3-config which of course returns results for the /usr(/local)/ tree.


This seems to go against the idea of an encapsulated and self-contained environment. And the venv created straight from the 
"not-installed" source tree works so well that having a venv/bin/python3-config whose output points into the source tree seems a logical 
step. Is this an omission or is there a rationale for not doing it?



AFAIK for _inside_ a virtual environment, the convention is `python', 
`python-`, `pip' etc. -- unversioned executables.

Versioned executables are the convention for UNIX _outside_ a virtual 
environment.

This is codified in https://www.python.org/dev/peps/pep-0394/.

Of course I can "properly" install different Python versions by using different "configure --prefix" directories. But I like the venv so 
much in general that this rubs me the wrong way.


Thanks!
___
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/KMG3USMQLQNI6AEX6UUS2WTNFIIIS2XY/
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/N3E26CJGWBI4IJ4VWNXIRAG3CCVYCFPF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Something wrong with the bug tracker?

[Ivan Pozdeev via Python-Dev]

On 22.12.2019 18:21, Martin (gzlist) via Python-Dev wrote:

Logging in with openid using launchpad just worked for me, so
transient or related to google's openid support presumably.


I have been unable to log in with google for a long time; had to reset the 
password to be able to log in without it.

So it's definitely not "transient".


Martin

On Sun, 22 Dec 2019 at 15:13, Mark Shannon  wrote:

Hi,

For some reason I can't log into the bug tracker with Google.
I just get the error message:

"""
An error has occurred

A problem was encountered processing your request.
The tracker maintainers have been notified of the problem.
"""

Whether I'm logged in or out of Google, or using a private tab, it makes
no difference.

Anyone else having problems?

Cheers,
Mark.
___
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/BXWXJYB2NDDRCM7CDWL2X3IWVDW7ZE7D/
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/KADR37G3JOAJWNB6VOJQDFNHSTZ2PH7Q/
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/VOGQL3IGE2PJQGDSX3K64WLGSZFIIXDE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Travis CI for backports not working.

[Ivan Pozdeev via Python-Dev]

On 25.11.2019 9:50, Terry Reedy wrote:

On 11/24/2019 7:30 PM, Ivan Pozdeev via Python-Dev wrote:


On 25.11.2019 1:10, Terry Reedy wrote:

Travis passed https://github.com/python/cpython/pull/17366
but a half hour later twice failed
https://github.com/python/cpython/pull/17370


This is build logic's fault, `python3.8` is not guaranteed to be present. I believe Configure is finding pyenv's shim which is present 
but returns 127 when run if there's no underlying executable to invoke. This is proven by "pyenv: python3.8: command not found".



https://github.com/python/cpython/pull/17371


This looks like Travis' fault, 3.7.1 should be preinstalled in Xenial with `language: c` according to my findings: 
https://github.com/travis-ci/docs-travis-ci-com/pull/2413/files#diff-fb862f5208fb2361d2280b621831f6b3


I reported this: 
https://github.com/travis-ci/docs-travis-ci-com/pull/2413#issuecomment-557942367


Thank you for reporting.  8 hrs later it is still down.  Maybe tomorrow 
something will happen.


Don't count on this being fixed fast: I said that this is not even an official 
guarantee yet.

Either move to Bionic where python 3.7 is available from Apt, or use `language: python`+`python: 3.7` or `language: generic` (where 3.7.1 is 
hopefully more reliably preinstalled) and install Clang 7 from Apt.




But note that the text stating that is not yet in the official documentation. (Current text says that it should be preinstalled but not 
for which languages.)



saying
pyenv: python3.8: command not found
pyenv: version `3.7.1' not installed




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

[Python-Dev] Re: Travis CI for backports not working.

[Ivan Pozdeev via Python-Dev]

On 25.11.2019 1:10, Terry Reedy wrote:

Travis passed https://github.com/python/cpython/pull/17366
but a half hour later twice failed
https://github.com/python/cpython/pull/17370


This is build logic's fault, `python3.8` is not guaranteed to be present. I believe Configure is finding pyenv's shim which is present but 
returns 127 when run if there's no underlying executable to invoke. This is proven by "pyenv: python3.8: command not found".



https://github.com/python/cpython/pull/17371


This looks like Travis' fault, 3.7.1 should be preinstalled in Xenial with `language: c` according to my findings: 
https://github.com/travis-ci/docs-travis-ci-com/pull/2413/files#diff-fb862f5208fb2361d2280b621831f6b3


I reported this: 
https://github.com/travis-ci/docs-travis-ci-com/pull/2413#issuecomment-557942367

But note that the text stating that is not yet in the official documentation. (Current text says that it should be preinstalled but not for 
which languages.)



saying
pyenv: python3.8: command not found
pyenv: version `3.7.1' not installed


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

[Python-Dev] Re: python3 -bb and hash collisions

[Ivan Pozdeev via Python-Dev]

On 10.09.2019 21:12, Chris Angelico wrote:

On Wed, Sep 11, 2019 at 12:47 AM Daniel Holth  wrote:

On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka  wrote:

22.06.19 01:08, Daniel Holth пише:

Thanks. I think I might like an option to disable str(bytes) without
disabling str != bytes. Unless the second operation would also corrupt
output.

Came across this kind of set in the hyper http library which uses a set
to accept certain headers with either str or bytes keys.

Does that library support Python 2?  If it is true than you have a
problem, because u'abc' == b'abc' in Python 2 and u'abc' != b'abc' in
Python 3.

If it is Python 3 only, you can just ignore BytesWarning. It was added
purely to help to catch subtle bugs in transition to Python 3. In
future, after Python 2 be out of use, BytesWarning will become deprecated.


I stopped using Python 3 after learning about str(bytes) by finding it in my 
corrupted database. Ever since then I've been anxious about changing to the new 
language, since it makes it so easy to convert from bytes to unicode by 
accident without specifying a valid encoding. So I would like to see a future 
where str(bytes) is effectively removed. I started working on a pull request 
that adds an API to toggle str(bytes) at runtime with a thread local (instead 
of requiring a command line argument), so you could do with no_str_bytes(): if 
you were worried about the feature, but got a bit stuck in the internals.


Python has, for as long as I've known it, permitted you to call str()
on literally any object - if there's no other string form, you get its
repr. Breaking this would break all manner of debugging techniques.

Isn't repr() the API intended for "all manner of debugging techniques"?

ChrisA
___
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/74W36BRRQZ7JDAPP5X37NZVXENLORZPF/


--
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/3W72OXGDFILI7OKAFE2L6O4LQALIJAEO/

[Python-Dev] Re: Missing license for file Modules/ossaudiodev.c

[Ivan Pozdeev via Python-Dev]

On 19.08.2019 23:30, Terry Reedy wrote:

On 8/19/2019 3:19 PM, Jeff Allen wrote:

This is undoubtedly the right answer for someone wanting to *use* code *from* 
CPython.

When one signs up to contribute code to the PSF, one is asked to write on  contributed software that it has been "Licensed to the PSF 
under a Contributor Agreement" (see https://www.python.org/psf/contrib/contrib-form/). The XXX comment may signal an intention to return 
and insert such words.


The form says specifically "adjacent to Contributor's valid copyright notice".  *If* the contribution comes with a separate explicit 
copyright notice (most do not), then it should be followed by the contribution notice.


ossaudiodev.c has 3 copyright notices, the last being by PSF in 2002, long before he current Contributor Agreement, and apparently never 
challenged.  Hence Guido's claim that the module is covered by the general PSF license.



The text has "All rights reserved" in all three lines which is _not_ a 
copyright notice but a license grant.
It's those license grants, including PSF's, that are untrue.

Compare with e.g. Tools/msi/bundle/bootstrap/pch.h and Modules/_hashopenssl.c in which a copyright notice correctly comes bare and is 
followed by a license grant compatible with PSFLA.


--
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/NX2IJXGR4S6N6X6EW2J2Z3U3XGOYBKVY/

[Python-Dev] Re: PEP 572 TargetScopeError

[Ivan Pozdeev via Python-Dev]

On 08.08.2019 20:54, Barry Warsaw wrote:

On Aug 8, 2019, at 10:41, Tim Peters  wrote:


Whereas SyntaxError would give no clue whatsoever, and nothing useful
to search for.  In contrast, a search for TargetScopeError would
presumably find a precisely relevant explanation as the top hit
(indeed, it already does today).

I don't care because it's unlikely an error most people will make at
all - or, for those too clever for their own good, make more than once
;-)

I agree it’s probably going to be a rare occurrence.  I suppose it just bothers 
me that when it does happen, we’ll present an obscurely named exception that 
will essentially force users to search for it.  But maybe they’ll have to 
anyway.  OTOH, maybe we can find an even better name, like EggManError or 
KooKooKaChooError.


It looks like you are forgetting that an exception presented to the user is 
accompanied with an explanation text.

Something like "Cannot assign `i` because this name is already used as a comprehension's loop variable" would clarify what exactly they did 
wrong.



I-am-the-Walrus-lyrics-won’t-help-you-at-all-ly y’rs,
-Barry


___
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/SSPDFUPPCLLNOWGHWPB5JK2ZIFRL6J44/


--
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/GCS24S5ADTQCOZUHOBR3TGSBPLWYJ7CT/

[Python-Dev] Re: What to do about invalid escape sequences

[Ivan Pozdeev via Python-Dev]

On 05.08.2019 7:22, raymond.hettin...@gmail.com wrote:

We should revisit what we want to do (if anything) about invalid escape 
sequences.

For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning which 
is visible by default.  The intention is to make it a SyntaxError in Python 3.9.


I don't see a problem with the DeprecationWarning approach. It's our standard procedure for removing features. Just make it an error in a 
later release -- whoever didn't heed the warning can't say we didn't warn them well in advance that this will stop working in the future.


It doesn't matter if this was a "perfectly working code": we change Python over time and what worked in the past may stop in the future. 
That's not something unexpected and we don't guarantee compatibility between minor releases.


It looks like either the core team has no unifying vision on what the deprecation process is and/or what each warning is for, or that this 
was a user experience experiment and Raymond's complaint is a part of its feedback (so the Mysterious Omniscient Council is probably going 
to incorporate it into other feedback and decide what they want to do next).




This once seemed like a reasonable and innocuous idea to me; however, I've been 
using the 3.8 beta heavily for a month and no longer think it is a good idea.  
The warning crops up frequently, often due to third-party packages (such as 
docutils and bottle) that users can't easily do anything about.  And during 
live demos and student workshops, it is especially distracting.

I now think our cure is worse than the disease.  If code currently has a non-raw 
string with '\latex', do we really need Python to yelp about it (for 3.8) or 
reject it entirely (for 3.9)?   If someone can't remember exactly which special 
characters need to be escaped, do we really need to stop them in their tracks 
during a data analysis session?  Do we really need to reject ASCII art in 
docstrings: ` \---> special case'?

IIRC, the original problem to be solved was false positives rather than false 
negatives:  filename = '..\training\new_memo.doc'.  The warnings and errors 
don't do (and likely can't do) anything about this.

If Python 3.8 goes out as-is, we may be punching our users in the nose and 
getting almost no gain from it.  ISTM this is a job best left for linters.  For 
a very long time, Python has been accepting the likes of 'more \latex markup' 
and has been silently converting it to 'more \\latex markup'.  I now think it 
should remain that way.  This issue in the 3.8 beta releases has been an almost 
daily annoyance for me and my customers. Depending on how you use Python, this 
may not affect you or it may arise multiple times per day.


Raymond

P.S.  Before responding, it would be a useful exercise to think for a moment 
about whether you remember exactly which characters must be escaped or whether 
you habitually put in an extra backslash when you aren't sure.  Then see:  
https://bugs.python.org/issue32912


I use raw strings whenever I have literals with backslashes. Very rarely, I 
need to insert \n-as-newline -- which I do into a regular string.
Since the first one appears in regexes and parameters that are Windows paths 
and the second one in output messages, they do not intersect.


___
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/ZX2JLOZDOXWVBQLKE4UCVTU5JABPQSLB/


--
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/LQWWXWY7OJP7PKHP7NMO27PKXUIF4WSL/

[Python-Dev] Re: Comparing dict.values()

[Ivan Pozdeev via Python-Dev]

On 23.07.2019 23:59, Kristian Klette wrote:


Hi!

During the sprints after EuroPython, I made an attempt at adding support for
comparing the results from `.values()` of two dicts.

Currently the following works as expected:

```
d = {'a': 1234}

d.keys() == d.keys()
d.items() == d.items()
```

but `d.values() == d.values()` does not return the expected
results. It always returns `False`. The symmetry is a bit off.

In the bug trackers[0] and the Github PR[1], I was asked
to raise the issue on the python-dev mailing list to find
a consensus on what comparing `.values()` should do.

I'd argue that Python should compare the values as expected here,
or if we don't want to encourage that behaviour, maybe we should
consider raising an exception.
Returning just `False` seems a bit misleading.

What are your thoughts on the issue?

Since a hash table is an unordered container and keys(), items() and values() are iterators over it, *I would expect the results of any of 
the comparisons to be undefined.*


While Python 3 dicts preserve order, it's _insertion_ order, so there's no guarantee that two equal dicts will iterate over the items in the 
same order.


*Comparing the sequences that iterators produce goes beyond the job of iterators* (i.e. requires iterating from start to finish under the 
hood and constructing temporary containers), so it shouldn't be a part of their functionality.
The implemented comparisons were specifically intended as convenience methods that go beyond the job of an iterator AFAICS but they fell 
short since in the case of `values()`, the task turned out to have too much computational complexity.


So *the comparion logic, if kept at all, should be reduced to comparing things that are intrinsic to iterators themselves:* whether they 
point to the same object and have the same internal state.
If someone needs to specifically compare the resulting sequences, they should use separate logic dedicated to comparing sequences -- with 
the associated quadratic complexity et al if then need to compare regardless or order. *The current logic encourages using iterators for 
things they aren't designed for so it's actively confusing and harmful.*



[0]: https://bugs.python.org/issue37585
[1]: https://github.com/python/cpython/pull/14737
___
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/R2MPDTTMJXAF54SICFSAWPPCCEWAJ7WF/


--
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/QWOL2YGLSDLCTBNXC3GUSINUB2E5ODEU/

[Python-Dev] Re: Python 3.7.4, Visual Studio versions for building modules from source

[Ivan Pozdeev via Python-Dev]

On 22.07.2019 18:25, Kacvinsky, Tom wrote:

HI,

Not sure if this is the right place to ask, but I am trying to build 
pywin32-224 from source for Python 3.7.4.  I think this might
be the right list as this seems to be a generic problem I am having, but I want 
to focus on one particular module.  First, I know
I could get this via 'pip install', but I want to build from source to see what 
it takes in terms of the Windows SDK and Visual Studio
versions for some other work I am doing.

I am using Python 3.7.4, and I have Visual Studio 2017 15.9 (released July of 
this year).

I see this when running 'python setup.y build':


error: Microsoft Visual C++ 14.1 is required. Get it with "Microsoft Visual C++ 
Build Tools": https://visualstudio.microsoft.com/downloads/

I have tried various compilers from that link (VS 2015, VS 2017, and even VS 
2019), but no joy.  I also have the Windows
SDK 8.1 and 10 installed (pywin32 wants the 8.1 SDK)

Does anyone have any ideas as to what I am doing wrong, or if there is some 
weird underlying issue with setuptools and/or
distutils?


Distutils supports the same compiler setup that is used to build Python itself.
As such, it can be seen in PCBuild/readme.txt in the source code 
(https://github.com/python/cpython/blob/3.7/PCbuild/readme.txt).

If the error says that "Microsoft Visual C++ 14.1 is required", be sure to select "v141 tools" in VS installer (readme.txt doesn't say this 
explicitly but it's a mandatory component when selecting VC++ support).


Setuptools supports more compiler setups. They don't see to be listed in the docs but are listed in 
https://github.com/pypa/setuptools/blob/master/setuptools/msvc.py .


---

Last time I checked, the information about supported compiler setups was 
gathered at https://wiki.python.org/moin/WindowsCompilers.
I see that it doesn't have an entry for MSVC 14.1.

Documentation on distutils.msvccompiler 
(https://docs.python.org/3/distutils/apiref.html?highlight=msvccompiler#module-distutils.msvccompiler) also mentions versions but it's 
severely outdated.

Should it refer to readme.txt?


--
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/SJPMTBXZWVKPZ72C5T52DRBG6KZWE77J/

[Python-Dev] Re: What is a public API?

[Ivan Pozdeev via Python-Dev]

On 13.07.2019 23:56, Serhiy Storchaka wrote:

I thought that the name in a module is in the public interface if:

* It doesn't start with an underscore and the module does not have __all__.
* It is included in the module's __all__ list.
* It is explicitly documented as a part of the public interface.

help() uses more complex rules, but it believes __all__ if it defined.

But seems there are different views on this.

* Raymond suggested to add an underscore the two dozens of names in the 
calendar module not included in __all__.
https://bugs.python.org/issue28292#msg347758

I do not like this idea, because it looks like a code churn and makes the code 
less readable.

* Gregory suggests to document codecs.escape_decode() despite it is not 
included in __all__.
https://bugs.python.org/issue30588

I do not like this idea, because this function always was internal, its only purpose was implementing the "string-escape" codec which was 
removed in Python 3 (for reasons). In Python 3 it is only used for supporting the old pickle protocol 0.


Could we strictly define what is considered a public module interface in Python?

Is "what is present in the reference documentation" insufficient?
Documenting all the official guarantees (which the public interface is a part 
of) is the whole purpose of a reference documentation.
(https://softwareengineering.stackexchange.com/questions/373439/technical-documentation-vs-software-design-documentation/373442#373442)

___
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/SJWR73UOGRSVC3HKHR4SZEJ3KINH32PQ/


--
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/7R6ADYJMEAXI7PPJ5R3VLVVNH4UFSGAY/

[Python-Dev] Re: [Possibly off-topic] Python-Announce floods and delays

[Ivan Pozdeev via Python-Dev]

On 08.07.2019 23:10, Jonathan Goble wrote:

On Mon, Jul 8, 2019, 3:56 PM Barry Warsaw mailto:ba...@python.org>> wrote:

On Jul 8, 2019, at 12:27, Jonathan Goble mailto:jcgob...@gmail.com>> wrote:

> Is there a solution to this that would enable moderators to approve
> more frequently?

Volunteers are welcome! :)

-Barry


I'd offer to volunteer, but I am merely a lurker and not active in the community, and I feel like someone more active and known in the 
community should take that role. Speaking of which, it looks like an -ideas mod has volunteered for -announce, so maybe that will help. :)



The requirement here is not prior fame but free time for the job (and a minimal 
amount of common sense if that could be called a requirement).



___
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/DIPEU26LK5JE5B2QH3LSHVSC44FGDMP7/


--
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/PYIZNVIGHSPSQ6T37UN62SSWHDAOI4N7/

[Python-Dev] Re: Removing dead bytecode vs reporting syntax errors

[Ivan Pozdeev via Python-Dev]

On 06.07.2019 0:28, Pablo Galindo Salgado wrote:

Hi,

Recently, we moved the optimization for the removal of dead code of the form

if 0:


to the ast so we use JUMP bytecodes instead (being completed in PR14116). The 
reason is that
currently, any syntax error in the block will never be reported. For example:

if 0:
return

if 1:
 pass
else:
 return

while 0:
 return

at module level do not raise any syntax error (just some examples), In 
https://bugs.python.org/issue37500 it was reported
that after that, code coverage will decrease as coverage.py sees these new 
bytecodes (even if they are not executed). In general,
the code object is a bit bigger and the optimization now it requires an JUMP 
instruction to be executed, but syntax errors are reported.

The discussion on issue 37500 is about if we should prioritize the optimization 
or the correctness of reporting syntax errors. In my opinion,
SyntaxErrors should be reported with independence of the value of variables 
(__debug__) or constant as is a property of the code being written
not of the code being executed. Also, as CPython is the reference implementation of Python, the danger here is that it could be 
interpreted that

this optimization is part of the language and its behavior should be mirrored 
in every other Python implementation. Elsewhere we have always
prioritize correctness over speed or optimizations.

I am writing this email to know what other people think. Should we revert the 
change and not report Syntax Errors on optimized blocks? Someone
sees a viable way of reporting the errors and not emitting the bytecode for 
these block?



"Correctness over speed" is Python's core value, so any syntax errors must be 
reported.

Is this optimization so important anyway? `if 0:' seems a niche use case (yes, it's in site.py which is in every installation but the gain 
there is pretty small)


If it is, why not kill two birds with one stone and discard the subtree, but 
_after_ it has passed scrunity?

AFAIK the standard approach to optimization is to construct a raw tree first 
and only then apply any equivalence transformations to it.

--
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/Q3HT6IRKC4X6UUYRZVANPJI4AJZNQQHM/

[Python-Dev] Re: Annoying user on GitHub

[Ivan Pozdeev via Python-Dev]

On 02.07.2019 19:09, Steve Dower wrote:

On 02Jul2019 0840, Mariatta wrote:
I've used the "Report abuse" feature on GitHub for such situations. Most of the time I see the user suspended, and the associated 
comments deleted.

Our GitHub admins can delete comments too.

On Tue, Jul 2, 2019, 1:42 AM Victor Stinner mailto:vstin...@redhat.com>> wrote:

    Hi,

    Sometimes, I get an email notification about strange comments
    (unrelated
    or make no sense) on commits made 6 months ago if not longer.
    Usually, I
    go to the user profile page and I click on "Block or report user":
    "Report abuse". I'm not sure what happens in this case. I never checks
    if these strange comments are removed by GitHub.


Maybe there's also a way to automatically lock conversations on commits and old 
issues?


https://github.com/apps/lock

But I'm solidary with Victor that unless this is a sizeable problem, it would 
do more harm than good.

Obviously we can lock them manually, but simply disallowing conversation in places where we don't want to have to pay attention to will 
force people towards the places where we are paying attention.


Cheers,
Steve
___
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/X5TYHVAORL72RFZLYIPFZR72FS2OLIRI/


--
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/AFUAX5W67PB4OKXMQWOPFSOLZAWPY5CB/

[Python-Dev] Re: Change SystemError to NOT inherit from Exception

[Ivan Pozdeev via Python-Dev]

On 01.07.2019 12:25, Jeroen Demeyer wrote:
A SystemError is typically raised from C to indicate serious bugs in the application which shouldn't normally be caught and handled. It's 
used for example for NULL arguments where a Python object is expected. So in some sense, SystemError is the Python equivalent of a 
segmentation fault.


Since these exceptions should typically not be handled in a try/except Exeption block, I suggest to make SystemError inherit directly from 
BaseException instead of Exception. 


https://docs.python.org/3/library/exceptions.html#SystemError:


Raised when the interpreter finds an internal error, but the situation does not look 
so serious to cause it to abandon all hope. <...>

You should report this to the author or maintainer of your Python interpreter.

For cases where the interpreter deems it too dangerous to continue, there's 
Py_FatalError().

And if it's safe to continue, the exception can be handled -- and since no-one specifically expecs SystemError, will be either logged, or 
ignored if the author explicitly doesn't mind if the particular code fails -- whether for this reason or any other.


--

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/5AFZBPYFCUB6JQV4G2OKE36WJVPJ55A3/

[Python-Dev] Re: Sponsoring Python development via the PSF

[Ivan Pozdeev via Python-Dev]

On 26.06.2019 10:41, Pau Freixes wrote:

Hi,

Why not the other way around? Having from the very beginning a clear goal with a speculative budget, companies would have visibilitty 
about the end goal of their donations. Otherwise is a bit a leap of faith.


+1. That's why I never donate to charity. I can't see or control what my money 
is going to be used for.



On Wed, Jun 26, 2019, 02:15 Brett Cannon mailto:br...@python.org>> wrote:

Victor Stinner wrote:
> That's great!
> "The PSF will use Python development fundraising to support CPython
> development and maintenance."
> Does someone have more info about that? Who will get the money, how, etc.?

No because we have to see how much money we get first. ;) Without knowing 
how much we will get then you can probably assume it will go
towards core dev sprint sponsorships like the page states. After that 
probably the PM role we have been talking about on the steering
council to help sunset Python 2, then a PM-like role to help with GitHub 
issue migration. That's as far as the steering council has
discussed things with the PSF in terms of short-term, concrete asks for 
money and staffing.

After that it's my personal speculation, but I would hope something like 
the Django fellowship program. If we could get enough money
to fund like 4 people to work on Python full-time it would be amazing and 
help us stay on top of things like pull requests.

But all of this depends on companies actually giving money in the proper 
amounts in order to be able to do anything like this. I've
been told by companies they have been wanting to donate money for ages but 
wanted to make sure it was helping Python's development.
Well, this is their chance to prove they actually meant it. ;)

> Victor
> Le lundi 24 juin 2019, Brett Cannon br...@python.org...
> a écrit :
> > We now have https://www.python.org/psf/donations/python-dev/...
> > for anyone
> > to make donations via the PSF for directly supporting Python development
> > (and we have the Sponsor button at https://github.com/python/cpython...
> > pointing to this link).
> > --
> Night gathers, and now my watch begins. It shall not end until my death.
___
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/BGZI7NPQTCSHI3JNMKTSPV4XM7FPI7HZ/


___
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/TDORWU57QJDTAOCJVX6VHZBACPU2QX4I/


--
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/PBZP2BX26WWCSEVLMTHKC4LP4DGEIWUS/

[Python-Dev] Re: python3 -bb and hash collisions

[Ivan Pozdeev via Python-Dev]

On 22.06.2019 1:08, Daniel Holth wrote:
Thanks. I think I might like an option to disable str(bytes) without disabling str != bytes. Unless the second operation would also 
corrupt output.


You can't compare str to bytes without knowing the encoding the bytes are supposed to be in (see 
https://stackoverflow.com/questions/49991870/python-default-string-encoding for details).


And if you do know the encoding, you can as well compare `str.encode(encoding) 
!= bytes` / `str != bytes.decode(encoding)`.



Came across this kind of set in the hyper http library which uses a set to 
accept certain headers with either str or bytes keys.

On Tue, Jun 18, 2019, 13:05 Christian Heimes mailto:christ...@python.org>> wrote:

On 18/06/2019 18.32, Daniel Holth wrote:
> set([u"foo", b"foo]) will error because the two kinds of string have the
> same hash, and this causes a comparison. Is that correct?

Yes, it will fail with -bb, because it turns comparison between str and
bytes into an error. This can also happen with other strings when
hash(u'somestring') & mask == hash(b'otherbytes') & mask. The mask of a
set starts with PySet_MINSIZE - 1 == 8 and increases over team.

Christian


___
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/ZIF2MRBWSMSCFP6E7PZOBI5KYP46QZPK/


___
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/R6E7FAR36UO6XHQSIAVF4DIM7G23ADJP/


--
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/XAN44UH5X5PYNSHY5ONULXIJF4DLBXF6/

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

[Ivan Pozdeev via Python-Dev]

On 27.05.2019 4:55, Steven D'Aprano wrote:

On Sun, May 26, 2019 at 04:03:11PM +0300, Ivan Pozdeev via Python-Dev wrote:

On 24.05.2019 9:55, Steven D'Aprano wrote:

I don't know if this is a good idea or a terrible idea or somewhere in
between, so I'm throwing it out to see if anyone likes it.

[...]


This would greately damage Python's image as a mature, reliable product,
something that you can bank on for your critical tasks.

By including something into the offer, we implicitly endorse it and claim
that we want out users to use that rather than competing offers.

Do we? I don't think that is the case for everything -- we certainly
don't want people using private or undocumented functions, nor do we
want them using deprecated code.


But we do. We promise that everything works as documented. Even if something is deprecated, one is supposed to be able to rely on it while 
it's (still) in.




[...]

You may argue that marking it as unsupported would do the same but it
wouldn't. This mean I'll have to be constantly on the lookout for hidden
notes and such,

Is "from unmaintained import module" enough to tell you that the
module is unmaintained?

This comes with its own set of drawbacks:
* compatibility break
* "unmaintained" is a judgement call, actual usability can change back and 
forth depending on the amount of interest
* it's still a blow to Python's credibility if the team feels the need to lug a 
truckload of dead code around

--
Regards,
Ivan

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

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

[Ivan Pozdeev via Python-Dev]

On 24.05.2019 9:55, Steven D'Aprano wrote:

I don't know if this is a good idea or a terrible idea or somewhere in
between, so I'm throwing it out to see if anyone likes it.

Let's add a third option to PEP 594 between "keep" and "remove":
explicitly flagging a module as unmaintained. Unmaintained modules:

- will raise a warning when imported that they are unmaintained;

- will have their tests disabled;

- possibly we move them into a seperate namespace:
   ``from unmaintained import aardvark``

- bug reports without patches will be closed Will Not Fix;

- bug reports with patches *may* be accepted if some core dev is
   willing to review and check it in, but there is no obligation
   to do so;

- should it turn out that someone is willing to maintain the module,
   it can be returned to regular status.


Plus side:

- reduce the maintenance burden (if any) from the module;

- while still distributing the module and allowing users to use
   it: "no promises, but here you go";

- other implementations are under no obligation to distribute
   unmaintained modules.

Minus side:

- this becomes a self-fulfilling prophesy: with tests turned off,
   bit-rot will eventually set in and break modules that currently
   aren't broken.



Thoughts?


This would greately damage Python's image as a mature, reliable product, 
something that you can bank on for your critical tasks.

By including something into the offer, we implicitly endorse it and claim that 
we want out users to use that rather than competing offers.

You may look at the archives where I relied on TKinter for an important project 
and it let me down big time.
I would very much prefer Python to honestly admit that there's not enough interest in this module and drop it so I would look elsewhere 
right off the bat and don't.


You may argue that marking it as unsupported would do the same but it wouldn't. This mean I'll have to be constantly on the lookout for 
hidden notes and such, I will forever lose confidence that I can just take whatever is in Python and run with it, being confident that the 
Python team has my back.


--
Regards,
Ivan

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

Re: [Python-Dev] Python in next Windows 10 update

[Ivan Pozdeev via Python-Dev]

On 22.05.2019 23:52, Steve Dower wrote:

On 22May2019 1309, Ivan Pozdeev via Python-Dev wrote:

As someone whose job is to diagnose and fix problems with running software:
Are there patches in your release? Do you provide corresponding sources and 
debug symbols for it?


You can find the sources at https://github.com/python/cpython :)


For Anaconda, this is not so, they apply private patches. So I had to make sure.


I'm working on getting debug symbols packaged for the next release, but once I do that they'll be exactly the same binaries as in the 
traditional installer on python.org. (Right now they are two separate builds of the same source.)


The package on the Store is not a Microsoft build or release of Python - it's published by whoever the Windows build manager is at the 
time. Just to be confusing, it's me right now, but the actual install is not owned or managed by Microsoft - just endorsed and linked.


Cheers,
Steve


--
Regards,
Ivan

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

Re: [Python-Dev] Python in next Windows 10 update

[Ivan Pozdeev via Python-Dev]

On 21.05.2019 23:30, Steve Dower wrote:

Hi all

Just sharing this here because I think it's important for us to be aware of it - I'm not trying to promote or sell anything here :) (Those 
who were at the language summit have seen this already.)


In the next Windows 10 update that starts rolling out today, we (Microsoft) have added "python.exe" and "python3.exe" commands that are 
installed on PATH *by default* and will open the Microsoft Store at the page where we (Python core team) publish our build.


This makes it a 1-2 click process to get from a clean machine to having a usable Python install ("python.exe" -> opens Store -> "Get it 
Free" -> "python.exe" now works!)


The associated blog post:

https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/

Here are answers to a few questions that I assume will come up, at least from 
this audience that understands the issues better than most:

* if someone had installed Python and put it on PATH with our installer, this 
new command *does not* interfere
* if someone had manually modified their own PATH, they *may* see some 
interference (but we [Microsoft] decided this was an acceptable risk)
* the Python 3.7 installed from the store will not auto-update to 3.8, but when 3.8 is released we (Microsoft) will update the redirect to 
point at it
* if you pass arguments to the redirect command, it just exits with an error code - you only get the Store page if you run it without 
arguments
* once the Store package is installed, the redirect command is replaced (this required a new feature in the OS). If you install with the 
regular installer and update PATH, or active a venv, it will add it *before* the redirect. So these scenarios should be all good.


I'm happy to answer other questions here. The long-term contact for this integration is python (at) microsoft.com, which right now will 
come to me.



As someone whose job is to diagnose and fix problems with running software:
Are there patches in your release? Do you provide corresponding sources and 
debug symbols for it?


And on a personal note, I'm very excited that we (Microsoft) got the approval to do this. Getting *anything* added to Windows is a big 
task, so it's a reflection of the popularity and support for Python that's growing within Microsoft that we were able to make this happen. 
That's due to every contributor, both to the core runtime and the ecosystem. I hope this will only help us improve the availability of 
Python for users and make it an easier choice for dev tasks in the future.


Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


--
Regards,
Ivan

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

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Ivan Pozdeev via Python-Dev]

On 15.05.2019 11:48, Antoine Pitrou wrote:

On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw  wrote:


As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of 
the Steering Council, I hereby Accept this PEP.

For future reference, is it possible to post the Steering Council's
reflection and rationale on the PEP?
+1. Specifically, I'd like to know if the risks and the potential for GitHub missing any needed features were estimated. The PEP says 
nothing about this.

Thank you

Regards

Antoine.


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


--
Regards,
Ivan

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