date:20190521

On Tue, 21 May 2019 at 04:30, Antoine Pitrou  wrote:

>
> NNTP is still quite used (often through GMane, but probably not only) so
> I'd question the removal of nntplib.

I concur nntplib should be left alone. There are possibly even less used
network protocols such as telnet (tenetlib) which are not targeted by this
PEP but could have been by following the same logic. FTP is another one
that despite no longer popular, still has a constant user base (you’d be
surprised by the amount of traffic we got over FTP in the last company I
worked for). Overall, I think the bar for a module removal should be set
very high, especially for “standard” things such as these network
protocols, that despite being old are not likely to change. That means that
also the maintenance burden for python-dev will be low or close to none
after all.

It seems to me also spwd/crypt modules fall into this category (all UNIX
platforms have the shadow password db, which is nice to have in python out
of the box). In that case the removal appears to be more justified by the
security implications than them being not widely used though, so I would
use more caution and treat them differently (eg. opt for doc warning +
investigate a possible replacement). Also note that spwd could be used to
parse /etc/passwd, despite I admit its primary use case is password
checking. Certain users may even not care about the additional security
provided by PAM (eg. internal devop scripts).
-- 
Giampaolo - http://grodola.blogspot.com
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Robert Collins

This vector exists today for all new stdlib modules: once added, any
existing dependency could include that name to cater it to be imported on
prior python versions.

Rob

On Wed, 22 May 2019, 17:03 Stephen J. Turnbull, <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Christian Heimes writes:
>
>  > It's all open source. It's up to the Python community to adopt
>  > packages and provide them on PyPI.
>  >
>  > Python core will not maintain and distribute the packages. I'll
>  > merely provide a repository with packages to help kick-starting the
>  > process.
>
> This looks to me like an opening to a special class of supply chain
> attacks.  I realize that PyPI is not yet particularly robust to such
> attacks, and we have seen "similar name" attacks (malware uploaded
> under a name similar to a popular package).  ISTM that this approach
> to implementing the PEP will enable "identical name" attacks.  (By
> download count, stdlib packages are as popular as Python. :-)
>
> It now appears that there's been substantial pushback against removing
> packages that could be characterized as "obsolete and superseded but
> still in use", so this may not be a sufficient great risk to be worth
> addressing.  I guess this post is already a warning to those who are
> taking care of the "similar name" malware that this class of attacks
> will be opened up.
>
> One thing we *could* do that would require moderate effort would be to
> put them up on PyPI ourselves, and require that would-be maintainers
> be given a (light) vetting before handing over the keys.  (Maybe just
> require that they be subscribers to the Dead Parrot SIG? :-)
>
> 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/robertc%40robertcollins.net
>
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Random832

On Tue, May 21, 2019, at 14:17, Christian Heimes wrote:
> thanks for bringing this topic up. Initially I considered http.server, 
> too. But as Guido put it, it's both used and useful for local testing 
> and quick hacks. I'm already facing opposition for modules that are 
> less controversial and useful than http.server, too. 

Could the high-level functionality of http.server (and perhaps socketserver as 
a whole) be rebuilt on top of asyncio, with serve_forever implicitly starting 
an asyncio loop with the server as the only task? Or are the paradigms too 
different?
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Stephen J. Turnbull

Christian Heimes writes:

 > It's all open source. It's up to the Python community to adopt
 > packages and provide them on PyPI.
 > 
 > Python core will not maintain and distribute the packages. I'll
 > merely provide a repository with packages to help kick-starting the
 > process.

This looks to me like an opening to a special class of supply chain
attacks.  I realize that PyPI is not yet particularly robust to such
attacks, and we have seen "similar name" attacks (malware uploaded
under a name similar to a popular package).  ISTM that this approach
to implementing the PEP will enable "identical name" attacks.  (By
download count, stdlib packages are as popular as Python. :-)

It now appears that there's been substantial pushback against removing
packages that could be characterized as "obsolete and superseded but
still in use", so this may not be a sufficient great risk to be worth
addressing.  I guess this post is already a warning to those who are
taking care of the "similar name" malware that this class of attacks
will be opened up.

One thing we *could* do that would require moderate effort would be to
put them up on PyPI ourselves, and require that would-be maintainers
be given a (light) vetting before handing over the keys.  (Maybe just
require that they be subscribers to the Dead Parrot SIG? :-)

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/archive%40mail-archive.com

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

2019-05-21 Thread Arfrever Frehtes Taifersar Arahesis

2019-05-21 00:06 UTC+02:00, Christian Heimes  wrote:
> On 20/05/2019 23.27, Antoine Pitrou wrote:
>> Removing the crypt module would remove support for system-standard
>> password files.  I don't understand the rationale.
>
> Applications *must* not access system-standard password files directly. On
> any sanely and securely configured systems, application cannot even access
> system password files like /etc/shadow. Access restrictions and system
> security policies will prevent read access. Also applications cannot assume
> that users are present in any user file. They may come from LDAP, SSSD,
> ActiveDirectory, or other sources.
>
> The correct way to interact with system users is to use the proper APIs,
> that are NSS (name service switch) and PAM (pluggable authentication
> modules). NSS looks up and enumerate users and groups. PAM performs password
> validation and much, much, much more. The pwd and grp modules use the
> correct APIs to interact with NSS. If you need to check or change passwords,
> you must go through PAM.

It is possible to have a modern Linux desktop system with PAM not
installed at all, and therefore not used.

Examples of packages in Gentoo Linux which have OPTIONAL dependency on PAM:
shadow, sudo, openssh, libcap, systemd, util-linux, screen, cronie,
polkit, cups, sddm, kscreenlocker, xscreensaver
(So a KDE Plasma desktop environment and its direct and indirect
dependencies can be installed without PAM.)

The suggested substitutes for spwd module, i.e. python-pam and
simpleplam, look like they would not work on a PAM-free system.

--
Arfrever Frehtes Taifersar Arahesis
___
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: Removing dead batteries from the standard library

On Tue., May 21, 2019, 13:07 Neil Schemenauer, 
wrote:

> On 2019-05-21, Terry Reedy wrote:
> > The problem with this argument, taken by itself, it that it would argue
> for
> > adding to the stdlib 100s or 1000s of modules or packages that would be
> > useful to many more people than the modules proposed to be dropped.
>
> I don't think it does.  We are not talking about 100s or 1000s of
> modules.  We are talking about modules which have been in Python's
> stdlib for years or decades.  If I have a script that uses one of
> these modules and it gets removed, my script breaks.
>
> Installing it from PyPI is not really a great solution.  We are
> going to be breaking working scripts just like if we add new
> language keywords, etc.  I think we need to be extremely careful
> with trying to maintain backwards compatibility, at least as far as
> we reasonably can.
>
> The problem I have with this PEP is that I think it both too
> aggressive and too conservative at the same time.  For almost all
> modules on the list, I'm sure there will be many people who are
> harmed by its removal.  OTOH, having to maintain all of the modules
> in the stdlib is a heavy burden.  Also, new users can be lured into
> using a module that is not really the best solution anymore.
>
> Here is an alternative, straw man, proposal.  Split the CPython repo
> into two parts:
>
> - core Python: minimal possible stdlib
> - everything else
>
> When Python is released, provide installers for a Python that only
> includes the "core" part and a second installer that includes
> everything else.  I realize this is more work for the release team.
> Hopefully with some scripting, it will not be too labour intensive.
>
> The core Python installer should become the recommended installer.
> People who need backwards compability with older versions of Python
> can download the big installer package.
>

How to this lighten the burden of maintaining those modules which aren't in
the core install? Are you suggesting modules in the core install get
serious focus and the rest is more of a legacy, unsupported release for
some time to give people an extended period to shift to the core install?
Or do you have something else in mind?

-Brett



> To help the people who need 100s or 1000s of extra PyPI packages, we
> could develop a tool that creates a "sumo" Python installer,
> grabbing packages from PyPI and building a installer package.  To
> install that package, you would not need network access.  That
> doesn't need to happen right away.  Also, maybe other Python
> distributions can fill that need if core Python devs don't want to
> build it.
>
> Regards,
>
>   Neil
> ___
> 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/brett%40python.org
>
___
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] Unrelated PRs linked to issues on bugs.python.org

2019-05-21 Thread Mariatta

One possible reason is when we wrote the wrong boo number in the PR, and
then changed it to the correct one. Not sure if this was the case.

The linking of PR number in boo is done in bpo. There was a similar issue:
https://github.com/python/bugs.python.org/issues/25

On Wed, May 22, 2019, 12:21 AM Victor Stinner  wrote:

> Hi,
>
> Since one or two weeks, I noticed that the bot which links GitHub pull
> requests to bugs.python.org issues started to link PRs to unrelated
> issues.
>
> Example: https://github.com/python/cpython/pull/13148 (merged 2 hours
> ago) just added to https://bugs.python.org/issue35363 (closed at the
> end of last year).
>
> I cannot find "35363" (bpo number) in
> https://github.com/python/cpython/pull/13148 nor in
> https://github.com/python/cpython/pull/13148/files
>
> Does anyone have an idea why unrelated PRs are added to issues?
>
> I don't know which bot is responsible for this task, nor who operates
> this bot. So in case of doubt, I chose to send a message to
> python-dev.
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/mariatta%40python.org
>
___
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: update 1

I repeat my position: on an omnibus PEP like this, if there's this much
debate about one module, it should be struck from the list.

On Tue, May 21, 2019 at 5:46 PM Brett Cannon  wrote:

>
>
> On Tue., May 21, 2019, 11:29 Antoine Pitrou,  wrote:
>
>>
>> Le 21/05/2019 à 20:16, Brett Cannon a écrit :
>> >
>> >
>> > On Tue., May 21, 2019, 09:10 Christian Heimes, > > > wrote:
>> >
>> > On 21/05/2019 17.31, Antoine Pitrou wrote:
>> > >
>> > > As I said, if the main annoyance with nntplib is the sporadic test
>> > > failures, then the relevant tests can be disabled on CI.
>> > >
>> > > NNTP itself is still used, even if less and less.
>> >
>> > I don't like the idea to drop a third of the test cases for nntplib
>> > -- and the 30% that actually test that Python's NNTP library can
>> > talk to an actual NNTP server. IMHO it's more beneficial for core
>> > development and for nntplib to have it maintained by somebody that
>> > cares about the library.
>> >
>> >
>> > Ditto for me. If the code isn't going to be properly tested then it's
>> > already unsupported, at which point we're back to wanting to deprecate
>> it.
>>
>> So I should never have added those tests and then we wouldn't be talking
>> about removing nntplib.
>>
>
> Not necessarily. I suspect it still would have been listed, you would have
> objected, and someone may have looked at the tests to point out it was only
> unit tests with no integration tests against a live service like e.g. the
> pythontest.net-related tests and so it was already neglected.
>
> It also doesn't help that no one is listed in the experts index for the
> module either.
>
> -Brett
>
>
>> 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/brett%40python.org
>>
> ___
> 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/guido%40python.org
>


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

___
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 544 and dunder methods

2019-05-21 Thread Eric Snow

On Tue, May 21, 2019, 12:00 Guido van Rossum  wrote:

> My guess, without delving into the implementation, is that a Protocol is
> *always* about the class, and that this is entirely a red herring.
>

I think you're right.  It makes sense.  I must have missed it somehow.

FYI, some protocols (like pickle) are looked up on the instance.  I'm on my
phone or I'd point you to the BPO issue. :)

-eric

>
___
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: update 1

On Tue., May 21, 2019, 11:29 Antoine Pitrou,  wrote:

>
> Le 21/05/2019 à 20:16, Brett Cannon a écrit :
> >
> >
> > On Tue., May 21, 2019, 09:10 Christian Heimes,  > > wrote:
> >
> > On 21/05/2019 17.31, Antoine Pitrou wrote:
> > >
> > > As I said, if the main annoyance with nntplib is the sporadic test
> > > failures, then the relevant tests can be disabled on CI.
> > >
> > > NNTP itself is still used, even if less and less.
> >
> > I don't like the idea to drop a third of the test cases for nntplib
> > -- and the 30% that actually test that Python's NNTP library can
> > talk to an actual NNTP server. IMHO it's more beneficial for core
> > development and for nntplib to have it maintained by somebody that
> > cares about the library.
> >
> >
> > Ditto for me. If the code isn't going to be properly tested then it's
> > already unsupported, at which point we're back to wanting to deprecate
> it.
>
> So I should never have added those tests and then we wouldn't be talking
> about removing nntplib.
>

Not necessarily. I suspect it still would have been listed, you would have
objected, and someone may have looked at the tests to point out it was only
unit tests with no integration tests against a live service like e.g. the
pythontest.net-related tests and so it was already neglected.

It also doesn't help that no one is listed in the experts index for the
module either.

-Brett


> 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/brett%40python.org
>
___
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 587 "Python Initialization Configuration" version 4

Hi,

Le lun. 20 mai 2019 à 21:36, Antoine Pitrou  a écrit :
> - Since PyInitError can be "ok", I'd rather call it "PyInitStatus".

Oh, I like this name :-)

By the way, I'm not comfortable with "PyInitError_Failed()" name since
it's true if it's an error (failure) ... or "an exit". What do you
think of the name "PyInitStatus_IsDone()"? It would give the pattern:

PyInitStatus status = Py_InitializeFromConfig(&config);
if (PyInitStatus_IsDone(status)) {
PyConfig_Clear(&config);
Py_ExitInitStatus(status);
}

Does it make more sense than the current code below?

PyInitError err = Py_InitializeFromConfig(&config);
if (PyInitError_Failed(err)) {
PyConfig_Clear(&config);
Py_ExitInitError(err);
}


> - The PyConfig example sets "module_search_paths" but not
>   "module_search_paths_set".  Is it an error?

If "module_search_paths_set" is set to 1, PyConfig_Read() leaves
"module_search_paths" unchanged. So it becomes possible to use Python
with sys.path = [].

Extract of the mentioned example (simplified):
---
PyConfig_Read(&config);
PyWideStringList_Append(&config.module_search_paths, L"/path/to/more/modules");
---

PyConfig_Read() is responsible to set "module_search_paths_set" to 1.
So if PyConfig_Read() is called again (which is always the case in
Py_InitializeFromConfig() to ensure that all PyConfig fields are set),
our customized module_search_paths is preserved.


> - "PyConfig_InitPythonConfig" vs "PyConfig_InitIsolatedConfig": why not
>   "PyConfig_InitConfig" and "PyConfig_InitIsolatedConfig"?

You should read "PyConfig_InitPythonConfig" as: same configuration
than regular Python executable.

Python 3.7 Py_Initialize() doesn't provide you exactly the same
configuration than regular Python executable: command line arguments
of sys.argv are not parsed, C standard streams are not configured,
etc.

Moreover, maybe someone will come up with a 3rd flavor of config, so I
prefer to give them explicit names ;-)

A single default configuration doesn't fit with all use cases, so PEP
587 provides two different flavors :-)


> - Why is there an "isolated" field in addition to the "IsolatedConfig"
>   functions?

There is a single PyConfig structure in the API. It makes more sense
for the Python Configuration which is *not* isolated by default. So
you can opt-in for an isolated Python configuration, as shown in the
example:
https://www.python.org/dev/peps/pep-0587/#python-configuration

Moreover, well, I have to store the information somewhere :-)

The idea of the "Isolated Configuration" is to start from the most
isolated configuration, but then to can tune it for your needs. You
might want to opt-in for isolated=0 to have a behavior closer to the
regular Python.


> - PyConfig.isolated is not documented.

Oops, fixed (in my current draft).


> - "Configuration files are still used with this configuration": why is
>   this?  Shouldn't they be ignored in an isolated configuration?

In short, I didn't touch the Path Configuration. You have to
explicitly set 5 fields to prevent Python to compute the Path
Configuration:

* exec_prefix
* executable
* prefix
* module_search_paths_set
* module_search_paths

https://www.python.org/dev/peps/pep-0587/#path-configuration


> - In "Comparison of Python and Isolated Configurations": what does -1
>   mean here?

Hum, the most complete documentation for the all configuration fields
currently lives at:
https://github.com/python/cpython/blob/master/Include/cpython/coreconfig.h

The design of the PEP 587 is that fields "explicitly" by the user
prevents Python to override them.

The -1 value means "unset": Python reads the value from the
environment. For example, dev_mode equals to -1 means that
PYTHONDEVMODE env var and -X dev command line variables are checked:
they set dev_mode to 1 is present, otherwise dev_mode is set to 0.
Setting dev_mode to 0 ensures that it cannot be enabled.


> Overall, this looks like a great improvement.  My only worry is that
> interactions between the various options seem complicated and
> difficult to understand.  Perhaps we will need some detailed
> documentation and examples.

"interactions between the various options" should be documentation at:
https://www.python.org/dev/peps/pep-0587/#priority-and-rules

My plan is also to move PEP 587 into the documentation, around:
http://docs.python.org/dev/c-api/init.html

The documentation can be enhanced later.

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

2019-05-21 Thread Steve Dower


On 21May2019 1621, MRAB wrote:

Does it behave nicely with py.exe?


This is still something of an open issue with the Store package for 
Python - py.exe doesn't look for the registry keys in a way that will 
find them (due to some very obscure compatibility quirks).


The Store package does not include py.exe though, so this only comes up 
if you install a second copy with the regular installer. And that would 
have to be a 3.8 alpha release to have any chance of getting the fix, 
since if you install a 3.7 release along with the 3.7 Store package then 
the regular install is likely going to shadow the Store package anyway, 
and I wasn't planning on adding to 3.6's launcher at this stage.


So far I haven't heard much feedback about this being a real issue - 
it's almost all been theoretical questions rather than "why did py.exe 
just fail?" issues. I expect they'll come up, and when they do I'm sure 
they'll point towards a good solution.


Earlier this year I installed an extension in Visual Studio Code for 
programming Arduino. It installed its own version of Python 2.7 (I'm on 
Python 3) and changed the file associations to point to that, thus 
breaking my scripts. (I wasn't keen on its customised icons, either.) I 
was somewhat unhappy at that...


The Store package should change otherwise unassigned file associations 
to point at it when it is installed. If you already have file 
associations, you might get a prompt next time you double-click a .py 
file, but it shouldn't just steal them.


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/archive%40mail-archive.com

Re: [Python-Dev] Python in next Windows 10 update

2019-05-21 Thread MRAB


On 2019-05-21 21:30, Steve Dower wrote:
[snip]

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.


Does it behave nicely with py.exe?

Earlier this year I installed an extension in Visual Studio Code for 
programming Arduino. It installed its own version of Python 2.7 (I'm on 
Python 3) and changed the file associations to point to that, thus 
breaking my scripts. (I wasn't keen on its customised icons, either.) I 
was somewhat unhappy at that...

___
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

2019-05-21 Thread Ethan Furman


On 05/21/2019 01:30 PM, Steve Dower wrote:


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


This is great!  I'm now actually looking forward to an update!  :-)

--
~Ethan~
___
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] Parser module in the stdlib

Le ven. 17 mai 2019 à 00:44, Nathaniel Smith  a écrit :
> Will the folks using forks be happy to switch to the stdlib version?
> For example I can imagine that if black wants to process 3.7 input
> code while running on 3.6, it might prefer a parser on PyPI even if
> the stdlib version were public, since the PyPI version can be updated
> independently of the host Python.

Pablo wrote:
> I think is missing an important gap in the stdlib and the closest thing we 
> have
> (the current parser module) is not useful for any of that. Also, the core to 
> generating
> the hypothetical new package (with some new API over it may be) is already 
> undocumented
> as an implementation detail of lib2to3 (and some people are already using it 
> directly).

IMHO it's way better to first mature a module on PyPI to ensure that it becomes:

* battle-tested
* have a well defined and *stable* API
* have a good test suite

Right now, everything looks too vague to me.

Reminder: the stdlib basically only gets a release every 2 years. If
you forget a super important feature, you have to wait 2 years to add
it.

Even for bugfixes, you also have to wait months if not years until all
vendors upgrade their Python package...

I'm not sure that putting it directly in the stdlib is a good idea.

Victor



--
Night gathers, and now my watch begins. It shall not end until my death.
___
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: Removing dead batteries from the standard library


On 5/21/2019 2:00 PM, Nathaniel Smith wrote:

On Tue, May 21, 2019 at 10:43 AM Glenn Linderman  wrote:

After maintaining my own version of http.server to fix or workaround some of 
its deficiencies for some years, I discovered bottle.py. It has far more 
capability, is far better documented, and is just as quick to deploy. While I 
haven't yet converted all past projects to use bottle.py, it will likely happen 
in time, unless something even simpler to use is discovered, although I can 
hardly imagine that happening.

bottle.py uses http.server for its local development mode (the one you
see in their quickstart example at the top of their README). Same with
flask, django, and probably a bunch of other frameworks. It's *very*
widely used.

-n

The source for bottle.py version 0.13-dev has an import for http.client, 
but not http.server. I hadn't tracked down every indirect dependency in 
the bottle.py source code, but it seems that if one uses the "default 
server" for bottle, that it is "wsgiref", imported from 
wsgiref.simple_server, and that in turn does import 
BaseHTTPRequestHandler and HTTPServer from http.server.


It is the higher-level code in http.server that has significant 
deficiencies that have caused me problems over the years... a 
"SimpleHTTPRequestHandler" that is so simple it doesn't do POST, PUT or 
PASTE, a "CGIHTTPRequestHandler" that only implements part of the CGI 
protocol, only CGI support in POST, no support for PUT or PASTE, and no 
support for https, and not much bug fix activity in those areas.


Maybe http.server should be split into the "basic parts" (used by 
bottle.py, and other frameworks), and the "higher-level parts", which 
could then be discarded by this PEP! At this point, though, I'd have to 
agree that the whole should not be discarded. Thanks for making me dig 
deeper.




___
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: Removing dead batteries from the standard library

Le mar. 21 mai 2019 à 23:05, Nathaniel Smith  a écrit :
> If the tests don't work and the module is unmaintained, then maybe we
> should disable the tests and put a prominent notice in the docs saying
> that it's unmaintained and any use is at your own risk. It's not a
> pleasant thing to do, but if that's the reality of the situation then
> it's probably better to be up front about it than to stick our fingers
> in our ears and waste folks time with spurious test failures. And
> perhaps someone would actually step up to maintain it.

Well, I already did that in the past.

Lib/test/test_ftplib.py:@skipUnless(False, "FIXME: bpo-32706")
=> skipped since 2018-01-29

Lib/test/test_nntplib.py:@unittest.skipIf(True, "FIXME: see bpo-32128")
=> skipped since 2017-11-25.

Oh, I even closed https://bugs.python.org/issue32128. Well, I'm kind
of tired of waiting for fixes in nntplib, so I decided to immediately
close the issue. I'm quite sure that nobody will fix it "soon" :-)
(hint: there FIXME is still there)

I'm not sure about documenting the module as "unmaintained".

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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

[Python-Dev] Unrelated PRs linked to issues on bugs.python.org

Hi,

Since one or two weeks, I noticed that the bot which links GitHub pull
requests to bugs.python.org issues started to link PRs to unrelated
issues.

Example: https://github.com/python/cpython/pull/13148 (merged 2 hours
ago) just added to https://bugs.python.org/issue35363 (closed at the
end of last year).

I cannot find "35363" (bpo number) in
https://github.com/python/cpython/pull/13148 nor in
https://github.com/python/cpython/pull/13148/files

Does anyone have an idea why unrelated PRs are added to issues?

I don't know which bot is responsible for this task, nor who operates
this bot. So in case of doubt, I chose to send a message to
python-dev.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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

On 21/05/2019 22.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/

Thanks for doing this and lowering the entree barrier for every Windows user. :)

Christian
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Nathaniel Smith

On Tue, May 21, 2019 at 4:25 AM Victor Stinner  wrote:
>
> Le mar. 21 mai 2019 à 13:18, André Malo  a écrit :
> > There's software in production using both. (It doesn't mean it's on pypi or
> > even free software).
> >
> > What would be the maintenance burden of those modules anyway? (at least for
> > nntp, I guess it's not gonna change).
>
> The maintenance burden is real even if it's not visible. For example,
> test_nntplib is causing frequently issues on our CI:
>
> https://bugs.python.org/issue19756
> https://bugs.python.org/issue19613
> https://bugs.python.org/issue31850
>
> It's failing frequently since 2013, and nobody managed to come with a
> fix.. in 6 years.

If the tests don't work and the module is unmaintained, then maybe we
should disable the tests and put a prominent notice in the docs saying
that it's unmaintained and any use is at your own risk. It's not a
pleasant thing to do, but if that's the reality of the situation then
it's probably better to be up front about it than to stick our fingers
in our ears and waste folks time with spurious test failures. And
perhaps someone would actually step up to maintain it.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Nathaniel Smith

On Tue, May 21, 2019 at 10:43 AM Glenn Linderman  wrote:
> After maintaining my own version of http.server to fix or workaround some of 
> its deficiencies for some years, I discovered bottle.py. It has far more 
> capability, is far better documented, and is just as quick to deploy. While I 
> haven't yet converted all past projects to use bottle.py, it will likely 
> happen in time, unless something even simpler to use is discovered, although 
> I can hardly imagine that happening.

bottle.py uses http.server for its local development mode (the one you
see in their quickstart example at the top of their README). Same with
flask, django, and probably a bunch of other frameworks. It's *very*
widely used.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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

2019-05-21 Thread Eric V. Smith

That’s great, Steve. Thanks for all of the work (by you and others) on this. 

--
Eric V. Smith
True Blade Systems, Inc
(301) 859-4544

> On May 21, 2019, at 4:30 PM, 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.
> 
> 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/eric%2Ba-python-dev%40trueblade.com

___
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: Removing dead batteries from the standard library


On 5/21/2019 11:15 AM, Christian Heimes wrote:

On 21/05/2019 18.29, Glenn Linderman wrote:

On 5/20/2019 2:20 PM, Christian Heimes wrote:

On 20/05/2019 23.12, Andrew Svetlov wrote:

socketserver.py is also questionable

I briefly though about the module, but didn't consider it for removal. The 
http.server, xmlrpc.server, and logging configuration server are implemented on 
top of the socketserver. I don't want to remove the socketserver module without 
a suitable replacement for http.server in the standard library.

But http.server could be on the remove list too... it gets mighty little 
support, has very little functionality, and implements a CGI interface 
(although that also has very little functionality), and you have the CGI tools 
on the remove list, rendering the CGI interface implemented by http.server less 
easily usable.

Further, it doesn't directly support https:, and browsers are removing/reducing 
support for http:.

I can't speak to xmlrpc or logging configuration.

Hi,

thanks for bringing this topic up. Initially I considered http.server, too. But 
as Guido put it, it's both used and useful for local testing and quick hacks. 
I'm already facing opposition for modules that are less controversial and 
useful than http.server, too.


Indeed. That's why they were created in the first place (http.server, 
and those other modules). But these days there are better alternatives. 
That's the point of the PEP, if I understand correctly... get rid of the 
junkware, point to the betterware, and avoid the need to learn the 
betterware later, because you wasted time and effort using the junkware 
at first, because it was "included".



I have two remarks:

1) The http.server does not act as a CGI server by default. In CGI server mode, 
it does not depend on the cgi module.


CGIHTTPRequestHandler is part of the package. While it does not depend 
on the cgi module, its existence encourages the users to search for, 
find, and use the cgi and cgitb modules when using 
CGIHTTPRequestHandler. I certainly did in past projects, prior to 
finding bottle.py.



2) The lack of HTTPS support is not a major problem for connections on localhost. There 
is a RFC draft to consider any connection to "localhost" as secure, 
https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06


Which certainly didn't exist when Chrome (noting the author's 
organization) and other browsers first started implementing feature 
restrictions for http, and while I haven't tested this since the RFC you 
mention was published, it was certainly a difficulty I faced when 
attempting to use features with security restrictions for local testing 
a couple years ago.



Christian


___
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

[Python-Dev] Python in next Windows 10 update

2019-05-21 Thread Steve Dower


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.


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/archive%40mail-archive.com

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

2019-05-21 Thread Neil Schemenauer

On 2019-05-21, Terry Reedy wrote:
> The problem with this argument, taken by itself, it that it would argue for
> adding to the stdlib 100s or 1000s of modules or packages that would be
> useful to many more people than the modules proposed to be dropped.

I don't think it does.  We are not talking about 100s or 1000s of
modules.  We are talking about modules which have been in Python's
stdlib for years or decades.  If I have a script that uses one of
these modules and it gets removed, my script breaks.

Installing it from PyPI is not really a great solution.  We are
going to be breaking working scripts just like if we add new
language keywords, etc.  I think we need to be extremely careful
with trying to maintain backwards compatibility, at least as far as
we reasonably can.

The problem I have with this PEP is that I think it both too
aggressive and too conservative at the same time.  For almost all
modules on the list, I'm sure there will be many people who are
harmed by its removal.  OTOH, having to maintain all of the modules
in the stdlib is a heavy burden.  Also, new users can be lured into
using a module that is not really the best solution anymore.

Here is an alternative, straw man, proposal.  Split the CPython repo
into two parts:

- core Python: minimal possible stdlib
- everything else

When Python is released, provide installers for a Python that only
includes the "core" part and a second installer that includes
everything else.  I realize this is more work for the release team.
Hopefully with some scripting, it will not be too labour intensive.

The core Python installer should become the recommended installer.
People who need backwards compability with older versions of Python
can download the big installer package.

To help the people who need 100s or 1000s of extra PyPI packages, we
could develop a tool that creates a "sumo" Python installer,
grabbing packages from PyPI and building a installer package.  To
install that package, you would not need network access.  That
doesn't need to happen right away.  Also, maybe other Python
distributions can fill that need if core Python devs don't want to
build it.

Regards,

  Neil
___
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: Removing dead batteries from the standard library

On 21/05/2019 20.35, Guido van Rossum wrote:
> On Tue, May 21, 2019 at 11:17 AM Christian Heimes  > wrote:
> 
> I'm already facing opposition for modules that are less controversial and 
> useful than http.server, too.
> 
> 
> There's another argument here. This is an "omnibus" PEP, meaning it proposes 
> many unrelated changes. In order to get a consensus to pass the PEP, it may 
> be necessary to compromise. IOW I would recommend removing modules from the 
> PEP that bring up strong opposition, *even* if you yourself feel strongly 
> that those modules should be removed.
> 
> The vast majority of modules on the list hasn't elicited any kind of feedback 
> at all -- those are clearly safe to remove (many people are probably, like 
> myself, hard-pressed to remember what they do). I'm not saying drop anything 
> from the list that elicits any pushback, but once the debate has gone back 
> and forth twice, it may be a hint that a module still has fans. Threatening 
> to open a CVE is more likely to reduce support for the PEP than it is to 
> convince anyone.

It was not a threat, but an illustration how critical the flaw with spwd + 
crypt is. The approach performs only authentication and completely bypasses any 
authorization. It does not take any login restrictions into account like 
account enabled flag, host/service based access control, IP restriction, 
credential strength, and so on. I would give the issue a CVSS rating between 
8.3 (high) to 9.6 (critical), perhaps 
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L

By the way, Giampaolo and I have known each other for many years. I know that 
he'll address the issue and file a CVE himself.
___
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 544 and dunder methods

(I did see your post in the moderation queue and let it through -- however
the mypy team, which would be most responsible for answering your question,
has been busy fighting some fires.)

I'm trying to understand what the PEP is saying and how you're
interpreting, and I'm not getting very far. I know for a fact that
Protocols work great with dunder methods. In fact the very first example in
the PEP uses `__len__` and `__iter__`, and there are several other examples
using `__iter__`, so I also know that this isn't an accident of mypy's
implementation. And mypy knows about the special rules for dunder method
lookup.

So what's left to figure out is what the bullet you quote means, and
whether it should be clarified, or whether it is literally correct (about
what the implementation does).

My guess, without delving into the implementation, is that a Protocol is
*always* about the class, and that this is entirely a red herring.

Looking at the implementation (e.g. the Python 3 implementation at
https://github.com/python/typing/blob/master/typing_extensions/src_py3/typing_extensions.py#L1077)
doesn't give me much clarity. The code seems to be highly optimized and not
so readable. But I do see, at line 1159, what looks like the check that the
bullet refers to. The point here is simply to make sure that a protocol
doesn't inherit from a non-protocol class. Besides `object` there are
several other exceptions that appear to me to be related to internals of
the runtime typing implementation.

If you are still not satisfied, I recommend that you try to construct a
counter-example and test it against the typing_extensions modules in Python
3.7 or 3.8.

Thanks!

--Guido

On Tue, May 21, 2019 at 8:40 AM Eric Snow 
wrote:

> [originally I sent this to typing-sig but I guess it got caught up in
> moderation.]
>
> In PEP 554 [1] it says:
>
>
>- Implement metaclass functionality to detect whether a class is a
>protocol or not. Add a class attribute _is_protocol = True if that is
>the case. Verify that a protocol class only has protocol base classes in
>the MRO (except for object).
>
> The phrase "except for object" implies that having "type" in the MRO would
> not be allowed.  Was that intentional?
>
> Perhaps I've misunderstood semantics with typing stuff (I haven't followed
> much of the discussion), but there seems to be a disconnect with how
> special ("dunder") methods are looked up (i.e. on classes).  Effectively,
> an object's *class* has to implement the relevant "protocol".  So
> disallowing "type" in the MRO means not using the PEP's functionality for
> "special method" protocols (as well as metaclasses in general).  Have I
> understood that right?  Is that on purpose?
>
> Thanks for working on this, BTW.  It's a nice addition. :)
>
> -eric
>
>
> [1] https://www.python.org/dev/peps/pep-0544/#implementation-details
> ___
> 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/guido%40python.org
>

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

___
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: Removing dead batteries from the standard library

On Tue, May 21, 2019 at 11:17 AM Christian Heimes 
wrote:

> I'm already facing opposition for modules that are less controversial and
> useful than http.server, too.

There's another argument here. This is an "omnibus" PEP, meaning it
proposes many unrelated changes. In order to get a consensus to pass the
PEP, it may be necessary to compromise. IOW I would recommend removing
modules from the PEP that bring up strong opposition, *even* if you
yourself feel strongly that those modules should be removed.

The vast majority of modules on the list hasn't elicited any kind of
feedback at all -- those are clearly safe to remove (many people are
probably, like myself, hard-pressed to remember what they do). I'm not
saying drop anything from the list that elicits any pushback, but once the
debate has gone back and forth twice, it may be a hint that a module still
has fans. Threatening to open a CVE is more likely to reduce support for
the PEP than it is to convince anyone.

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

___
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: update 1

On 21/05/2019 20.18, Giampaolo Rodola' wrote:
> No, the statement is correct. I may have to explain this even further.
> 
> The approach in pyftpdlib is the wrong and IMO deserves a CVE. The 
> crypt() + spwd() approach is flawed on multiple levels. For example it 
> bypasses account restriction, access control, and login session. It also 
> requires you to run the service as root and with SELinux disabled or an 
> unconfined context -- a bad combination. There is only one correct way to 
> perform a credential check: use PAM.
> 
> spwd can't be fixed. It could only be replaced with a completely 
> different API that wraps PAM and Windows's authentication API.
> 
> Christian
> 
> PS: Authentication, authorization, and identity management are part of my 
> day job at Red Hat.
> 
> 
> Got it. I had no idea. Since you mentioned the CVE it looks like spwd/crypt 
> doc deserve a warning. This is probably out of the scope of the PEP, but I 
> wonder if the 3 third-party alternatives mentioned in the PEP are mature 
> enough and could be evaluated for stdlib inclusion (the part re. PAM / 
> password-checking at least). Perhaps spwd/crypt could be deprecated in 3.8 
> and the alternative added in 3.9 before the 3.10 removal.

Sorry, I didn't even occur to me that anybody was still using spwd. I would 
have added a warning much earlier. There is now 
https://bugs.python.org/issue36997 to track the problem.

Could you do me a favor and open a feature request?
___
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: update 1


Le 21/05/2019 à 20:16, Brett Cannon a écrit :
> 
> 
> On Tue., May 21, 2019, 09:10 Christian Heimes,  > wrote:
> 
> On 21/05/2019 17.31, Antoine Pitrou wrote:
> >
> > As I said, if the main annoyance with nntplib is the sporadic test
> > failures, then the relevant tests can be disabled on CI.
> >
> > NNTP itself is still used, even if less and less.
> 
> I don't like the idea to drop a third of the test cases for nntplib
> -- and the 30% that actually test that Python's NNTP library can
> talk to an actual NNTP server. IMHO it's more beneficial for core
> development and for nntplib to have it maintained by somebody that
> cares about the library.
> 
> 
> Ditto for me. If the code isn't going to be properly tested then it's
> already unsupported, at which point we're back to wanting to deprecate it.

So I should never have added those tests and then we wouldn't be talking
about removing nntplib.

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/archive%40mail-archive.com

Re: [Python-Dev] PEP 594: update 1

On Tue, 21 May 2019 at 23:26, Christian Heimes  wrote:

> On 21/05/2019 18.08, Giampaolo Rodola' wrote:
> >
> >
> > On Tue, 21 May 2019 at 21:13, Christian Heimes  > wrote:
> >
> > crypt
> > ~
> >
> > The `crypt `_ module
> implements
> > password hashing based on ``crypt(3)`` function from ``libcrypt`` or
> > ``libxcrypt`` on Unix-like platform. The algorithms are mostly old,
> of poor
> > quality and insecure. Users are discouraged to use them.
> >
> > * The module is not available on Windows. Cross-platform application
> need
> >   an alternative implementation any way.
> > * Only DES encryption is guarenteed to be available. DES has an
> extremely
> >   limited key space of 2**56.
> > * MD5, salted SHA256, salted SHA512, and Blowfish are optional
> extension.
> >   SSHA256 and SSHA512 are glibc extensions. Blowfish (bcrypt) is the
> only
> >   algorithm that is still secure. However it's in glibc and
> therefore not
> >   commonly available on Linux.
> > * Depending on the platform, the ``crypt`` module is not thread
> safe. Only
> >   implementations with ``crypt_r(3)`` are thread safe.
> > * The module was never useful to interact with system user and
> password
> >   databases.
> >
> >
> > This is actually not true. Their main use case is to compare passwords
> against the shadowed password db:
> >
> https://github.com/giampaolo/pyftpdlib/blob/ee7b36c701b78b2d36e938c42d08dbfbad55a34f/pyftpdlib/authorizers.py#L413
> > A quick search on searchcode.com  shows both
> spwd and crypt modules are used. I am no security expert (and I wasn’t
> aware they are insecure until now, since the doc doesn’t mention it) but I
> would prefer seeing these 2 fixed or improved rather than bluntly removed.
>
> No, the statement is correct. I may have to explain this even further.
>
> The approach in pyftpdlib is the wrong and IMO deserves a CVE. The crypt()
> + spwd() approach is flawed on multiple levels. For example it bypasses
> account restriction, access control, and login session. It also requires
> you to run the service as root and with SELinux disabled or an unconfined
> context -- a bad combination. There is only one correct way to perform a
> credential check: use PAM.
>
> spwd can't be fixed. It could only be replaced with a completely different
> API that wraps PAM and Windows's authentication API.
>
> Christian
>
> PS: Authentication, authorization, and identity management are part of my
> day job at Red Hat.
>

Got it. I had no idea. Since you mentioned the CVE it looks like spwd/crypt
doc deserve a warning. This is probably out of the scope of the PEP, but I
wonder if the 3 third-party alternatives mentioned in the PEP are mature
enough and could be evaluated for stdlib inclusion (the part re. PAM /
password-checking at least). Perhaps spwd/crypt could be deprecated in 3.8
and the alternative added in 3.9 before the 3.10 removal.


-- 
Giampaolo - http://grodola.blogspot.com
___
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: update 1

On Tue., May 21, 2019, 09:10 Christian Heimes,  wrote:

> On 21/05/2019 17.31, Antoine Pitrou wrote:
> >
> > As I said, if the main annoyance with nntplib is the sporadic test
> > failures, then the relevant tests can be disabled on CI.
> >
> > NNTP itself is still used, even if less and less.
>
> I don't like the idea to drop a third of the test cases for nntplib -- and
> the 30% that actually test that Python's NNTP library can talk to an actual
> NNTP server. IMHO it's more beneficial for core development and for nntplib
> to have it maintained by somebody that cares about the library.
>

Ditto for me. If the code isn't going to be properly tested then it's
already unsupported, at which point we're back to wanting to deprecate it.

-Brett


> Even a deprecation in 3.8 means that the module has to be maintained until
> EOL of 3.9, which is around 2026.
>
> Christian
> ___
> 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/brett%40python.org
>
___
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: Removing dead batteries from the standard library

On 21/05/2019 16.46, Guido van Rossum wrote:
> +1. Let's keep colorsys then.

I let colorsys off the hock, https://github.com/python/peps/pull/1070

Thanks for your feedback, Walter and Petr!

Christian
___
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: update 1

2019-05-21 Thread Terry Reedy


On 5/21/2019 10:12 AM, Christian Heimes wrote:


---
PEP: 594
Title: Removing dead batteries from the standard library


'dead' seems controversial.  'nearly useless' should be less so.  I 
think 'after 2.7 end-of-life' is worth adding, as the schedule hinges 
around that.  Result:


"Removing nearly useless batteries from the standard library after 2.7 
end-of-life."



Abstract




Rationale
=


Part of the point of the PEP is to gather together nearly all proposals 
in one place so users can respond in a timely fashion.



Deprecation schedule



I think it worth adding that some modules were deprecated years ago but 
kept until after 2.7 end-of-life to ease 3.x transition.  Removing 
modules is not a sudden new idea.


Also, the proposed schedule (with one exception) is a slower alternative 
than proposals to add a deprecation warning (if not one already) in 3.8 
and remove in 3.9.



--
Terry Jan Reedy

___
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: Removing dead batteries from the standard library

On Tue, 21 May 2019 13:59:56 -0400
Terry Reedy  wrote:
> On 5/21/2019 9:01 AM, Steven D'Aprano wrote:
> ...
> > Many Python users don't have the privilege of being able to install
> > arbitrary, unvetted packages from PyPI. They get to use only packages
> > from approved vendors, including the stdlib, what they write themselves,
> > and nothing else. Please don't dismiss this part of the Python community
> > just because they don't typically hang around in the same forums we do.  
> ...
> 
> The problem with this argument, taken by itself, it that it would argue 
> for adding to the stdlib 100s or 1000s of modules or packages that would 
> be useful to many more people than the modules proposed to be dropped. 
> That would require multiplying the number of core developers by perhaps 
> 10.  We have thus far decided to not do this.
> 
> We have instead left sumo distributions with vetted (?) additions to 
> other groups.  But as it is, the stdlib is, as far as I last knew, 
> richer than, for instance, the standard C stdlib.
> 
> Given that presence in the stdlib is restricted, what should be 
> included.  Is mere inertia a sufficient reason?  I don't think it should be.

One fundamental thing the stdlib provides is stability.  If you use an
API from the stdlib today, chances are it'll still work in 10 years,
even on the most recent Python version. Good luck relying on that with
most third-party packages.

But if stdlib modules can disappear when we decide they don't get
enough usage, the stability promise disappears as well.

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/archive%40mail-archive.com

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 18.29, Glenn Linderman wrote:
> On 5/20/2019 2:20 PM, Christian Heimes wrote:
>> On 20/05/2019 23.12, Andrew Svetlov wrote:
>>> socketserver.py is also questionable
>> I briefly though about the module, but didn't consider it for removal. The 
>> http.server, xmlrpc.server, and logging configuration server are implemented 
>> on top of the socketserver. I don't want to remove the socketserver module 
>> without a suitable replacement for http.server in the standard library.
> 
> But http.server could be on the remove list too... it gets mighty little 
> support, has very little functionality, and implements a CGI interface 
> (although that also has very little functionality), and you have the CGI 
> tools on the remove list, rendering the CGI interface implemented by 
> http.server less easily usable.
> 
> Further, it doesn't directly support https:, and browsers are 
> removing/reducing support for http:.
> 
> I can't speak to xmlrpc or logging configuration.

Hi,

thanks for bringing this topic up. Initially I considered http.server, too. But 
as Guido put it, it's both used and useful for local testing and quick hacks. 
I'm already facing opposition for modules that are less controversial and 
useful than http.server, too. 

I have two remarks:

1) The http.server does not act as a CGI server by default. In CGI server mode, 
it does not depend on the cgi module.
2) The lack of HTTPS support is not a major problem for connections on 
localhost. There is a RFC draft to consider any connection to "localhost" as 
secure, https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06

Christian
___
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: Removing dead batteries from the standard library

On Tue., May 21, 2019, 04:25 Victor Stinner,  wrote:

> Le mar. 21 mai 2019 à 13:18, André Malo  a écrit :
> > There's software in production using both. (It doesn't mean it's on pypi
> or
> > even free software).
> >
> > What would be the maintenance burden of those modules anyway? (at least
> for
> > nntp, I guess it's not gonna change).
>
> The maintenance burden is real even if it's not visible. For example,
> test_nntplib is causing frequently issues on our CI:
>
> https://bugs.python.org/issue19756
> https://bugs.python.org/issue19613
> https://bugs.python.org/issue31850
>
> It's failing frequently since 2013, and nobody managed to come with a
> fix.. in 6 years.
>
> There are 11 open issues with "nntp" in their title (8 with exactly
> "nntplib" in their title).
>

I would be curious to know how many feature PRs there might exist as that
also is a burden for any of these modules beyond bugs and any general
upkeep we do (e.g. someone on Twitter argued that because someone merged a
new feature that means that a module should stay, but to me that just says
one person cared enough to write a PR and one core dev viewed it as
harmless to merge which isn't necessarily representative of usage).

-Brett

P.S. I have an idea about under-supported modules in the stdlib and feature
requests, but it's too early to share (nor the appropriate thread of
discussion).


> test_nntplib uses the public server news.trigofacile.com which is
> operated by Julien ÉLIE. Two years ago, Julien asked me if there is
> any plan to support the NNTP "COMPRESS" command.
>
> Victor
>
>
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/brett%40python.org
>
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Terry Reedy


On 5/21/2019 9:01 AM, Steven D'Aprano wrote:
...

Many Python users don't have the privilege of being able to install
arbitrary, unvetted packages from PyPI. They get to use only packages
from approved vendors, including the stdlib, what they write themselves,
and nothing else. Please don't dismiss this part of the Python community
just because they don't typically hang around in the same forums we do.

...

The problem with this argument, taken by itself, it that it would argue 
for adding to the stdlib 100s or 1000s of modules or packages that would 
be useful to many more people than the modules proposed to be dropped. 
That would require multiplying the number of core developers by perhaps 
10.  We have thus far decided to not do this.


We have instead left sumo distributions with vetted (?) additions to 
other groups.  But as it is, the stdlib is, as far as I last knew, 
richer than, for instance, the standard C stdlib.


Given that presence in the stdlib is restricted, what should be 
included.  Is mere inertia a sufficient reason?  I don't think it should be.


--
Terry Jan Reedy

___
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: Removing dead batteries from the standard library

2019-05-21 Thread Oleg Broytman

``http.server`` is used in ``pydoc``:

https://github.com/python/cpython/blob/ccb7ca728e09b307f9e9fd36ec40353137e68a3b/Lib/pydoc.py#L2236

On Tue, May 21, 2019 at 10:12:50AM -0700, Guido van Rossum  
wrote:
> I still like http.server for quick temporary hacks where I want to be able
> to point a browser at some code I wrote 5 minutes ago and that I plan to
> discard in an hour. Usually it's running at localhost:8000. Remembering how
> to use Django, flask or Tornado seems overkill for that purpose.
> 
> On Tue, May 21, 2019 at 9:39 AM Glenn Linderman 
> wrote:
> 
> > On 5/20/2019 2:20 PM, Christian Heimes wrote:
> >
> > On 20/05/2019 23.12, Andrew Svetlov wrote:
> >
> > socketserver.py is also questionable
> >
> > I briefly though about the module, but didn't consider it for removal. The 
> > http.server, xmlrpc.server, and logging configuration server are 
> > implemented on top of the socketserver. I don't want to remove the 
> > socketserver module without a suitable replacement for http.server in the 
> > standard library.
> >
> >
> > But http.server could be on the remove list too... it gets mighty little
> > support, has very little functionality, and implements a CGI interface
> > (although that also has very little functionality), and you have the CGI
> > tools on the remove list, rendering the CGI interface implemented by
> > http.server less easily usable.
> >
> > Further, it doesn't directly support https:, and browsers are
> > removing/reducing support for http:.
> >
> > I can't speak to xmlrpc or logging configuration.
> -- 
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him/his **(why is my pronoun here?)*
> 

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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] Parser module in the stdlib

On Mon., May 20, 2019, 16:00 Terry Reedy,  wrote:

> On 5/20/2019 11:55 AM, Guido van Rossum wrote:
> > On Thu, May 16, 2019 at 3:57 PM Steve Dower  > > wrote:
> >
> > [...]
> > We still have the policy of not removing modules that exist in the
> > Python 2 standard library. But 3.9 won't be covered by that :)
> >
> > I didn't even remember that. Where's that written down?
>
> AFAIK, there has been no BDFL pronouncement or coredev vote.


It's in PEP 4 since at least Python 3.5:
https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-python-2-7-and-python-3-5
.

-Brett

But it has
> become somewhat of a consensus as a result of discussions in multliple
> threads about removing modules going back to the 3.4 era.
>
> PEP 594, just posted, proposes to codify a 'soft' (or perhaps 'slow')
> version of the policy: doc deprecation, code deprecation, and code
> removal in 3.8, 3.9, 3.10.
> > FWIW I am strongly in favor of getting rid of the `parser` module, in
> > 3.8 if we can, otherwise in 3.9 (after strong deprecation in 3.8).
>
> You could request that 'parser' be specifically excluded from the PEP,
> along with 'distutils' (and effectively anything else not specifically
> named).  Or request that it be included, but with an accelerated
> schedule.  I have a vague idea of why you think it harmful to keep it
> around, but a reminder would not hurt ;-).
>
> --
> Terry Jan Reedy
>
> ___
> 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/brett%40python.org
>
___
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: Removing dead batteries from the standard library


On 5/21/2019 10:12 AM, Guido van Rossum wrote:
I still like http.server for quick temporary hacks where I want to be 
able to point a browser at some code I wrote 5 minutes ago and that I 
plan to discard in an hour. Usually it's running at localhost:8000. 
Remembering how to use Django, flask or Tornado seems overkill for 
that purpose.


After maintaining my own version of http.server to fix or workaround 
some of its deficiencies for some years, I discovered bottle.py. It has 
far more capability, is far better documented, and is just as quick to 
deploy. While I haven't yet converted all past projects to use 
bottle.py, it will likely happen in time, unless something even simpler 
to use is discovered, although I can hardly imagine that happening.


I agree that Django, flask, and Tornado have bigger learning curves, due 
to having their own philosophies on how things should be done... I 
looked at each on my way to finding bottle.py, and in each case decided 
their philosophies, while probably useful to people that like or need 
the capabilities offered, were excessive to learn if the capabilities 
were not needed.


Providing http.server as an included battery is a disservice to novice 
users, because they might try to use it for something real.


On Tue, May 21, 2019 at 9:39 AM Glenn Linderman > wrote:


On 5/20/2019 2:20 PM, Christian Heimes wrote:

On 20/05/2019 23.12, Andrew Svetlov wrote:

socketserver.py is also questionable

I briefly though about the module, but didn't consider it for removal. The 
http.server, xmlrpc.server, and logging configuration server are implemented on 
top of the socketserver. I don't want to remove the socketserver module without 
a suitable replacement for http.server in the standard library.


But http.server could be on the remove list too... it gets mighty
little support, has very little functionality, and implements a
CGI interface (although that also has very little functionality),
and you have the CGI tools on the remove list, rendering the CGI
interface implemented by http.server less easily usable.

Further, it doesn't directly support https:, and browsers are
removing/reducing support for http:.

I can't speak to xmlrpc or logging configuration.




___
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/guido%40python.org



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



___
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: Removing dead batteries from the standard library

2019-05-21 Thread Edwin Zimmerman

On Tuesday, May 21, 2019 12:30 PM Glenn Linderman wrote

On 5/20/2019 2:20 PM, Christian Heimes wrote:
On 20/05/2019 23.12, Andrew Svetlov wrote:
socketserver.py is also questionable
I briefly though about the module, but didn't consider it for removal. The 
http.server, xmlrpc.server, and logging configuration
server are implemented on top of the socketserver. I don't want to remove the 
socketserver module without a suitable replacement for
http.server in the standard library.

But http.server could be on the remove list too... it gets mighty little 
support, has very little functionality, and implements a
CGI interface (although that also has very little functionality), and you have 
the CGI tools on the remove list, rendering the CGI
interface implemented by http.server less easily usable.

Further, it doesn't directly support https:, and browsers are removing/reducing 
support for http:.
All the same, I’d hate to see http.server leave.  It’s doubtful that anyone 
uses the thing for a production server, but I use it
all the time for low-volume development stuff on Windows.
<>___
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: Removing dead batteries from the standard library

I still like http.server for quick temporary hacks where I want to be able
to point a browser at some code I wrote 5 minutes ago and that I plan to
discard in an hour. Usually it's running at localhost:8000. Remembering how
to use Django, flask or Tornado seems overkill for that purpose.

On Tue, May 21, 2019 at 9:39 AM Glenn Linderman 
wrote:

> On 5/20/2019 2:20 PM, Christian Heimes wrote:
>
> On 20/05/2019 23.12, Andrew Svetlov wrote:
>
> socketserver.py is also questionable
>
> I briefly though about the module, but didn't consider it for removal. The 
> http.server, xmlrpc.server, and logging configuration server are implemented 
> on top of the socketserver. I don't want to remove the socketserver module 
> without a suitable replacement for http.server in the standard library.
>
>
> But http.server could be on the remove list too... it gets mighty little
> support, has very little functionality, and implements a CGI interface
> (although that also has very little functionality), and you have the CGI
> tools on the remove list, rendering the CGI interface implemented by
> http.server less easily usable.
>
> Further, it doesn't directly support https:, and browsers are
> removing/reducing support for http:.
>
> I can't speak to xmlrpc or logging configuration.
>
>
>
>
> ___
> 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/guido%40python.org
>


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

___
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: update 1

On 21/05/2019 18.08, Giampaolo Rodola' wrote:
> 
> 
> On Tue, 21 May 2019 at 21:13, Christian Heimes  > wrote:
> 
> crypt
> ~
> 
> The `crypt `_ module 
> implements
> password hashing based on ``crypt(3)`` function from ``libcrypt`` or
> ``libxcrypt`` on Unix-like platform. The algorithms are mostly old, of 
> poor
> quality and insecure. Users are discouraged to use them.
> 
> * The module is not available on Windows. Cross-platform application need
>   an alternative implementation any way.
> * Only DES encryption is guarenteed to be available. DES has an extremely
>   limited key space of 2**56.
> * MD5, salted SHA256, salted SHA512, and Blowfish are optional extension.
>   SSHA256 and SSHA512 are glibc extensions. Blowfish (bcrypt) is the only
>   algorithm that is still secure. However it's in glibc and therefore not
>   commonly available on Linux.
> * Depending on the platform, the ``crypt`` module is not thread safe. Only
>   implementations with ``crypt_r(3)`` are thread safe.
> * The module was never useful to interact with system user and password
>   databases.
> 
> 
> This is actually not true. Their main use case is to compare passwords 
> against the shadowed password db:
> https://github.com/giampaolo/pyftpdlib/blob/ee7b36c701b78b2d36e938c42d08dbfbad55a34f/pyftpdlib/authorizers.py#L413
> A quick search on searchcode.com  shows both spwd and 
> crypt modules are used. I am no security expert (and I wasn’t aware they are 
> insecure until now, since the doc doesn’t mention it) but I would prefer 
> seeing these 2 fixed or improved rather than bluntly removed. 

PS: "pw1 != pw2" on line 418 is also vulnerable to side channel attack. You 
must use a constant timing comparison operator like hmac.compare_digest() to 
compare password digests.

https://github.com/giampaolo/pyftpdlib/blob/ee7b36c701b78b2d36e938c42d08dbfbad55a34f/pyftpdlib/authorizers.py#L418
___
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: Removing dead batteries from the standard library


On 5/20/2019 2:20 PM, Christian Heimes wrote:

On 20/05/2019 23.12, Andrew Svetlov wrote:

socketserver.py is also questionable

I briefly though about the module, but didn't consider it for removal. The 
http.server, xmlrpc.server, and logging configuration server are implemented on 
top of the socketserver. I don't want to remove the socketserver module without 
a suitable replacement for http.server in the standard library.


But http.server could be on the remove list too... it gets mighty little 
support, has very little functionality, and implements a CGI interface 
(although that also has very little functionality), and you have the CGI 
tools on the remove list, rendering the CGI interface implemented by 
http.server less easily usable.


Further, it doesn't directly support https:, and browsers are 
removing/reducing support for http:.


I can't speak to xmlrpc or logging configuration.




___
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: update 1

On 21/05/2019 18.08, Giampaolo Rodola' wrote:
> 
> 
> On Tue, 21 May 2019 at 21:13, Christian Heimes  > wrote:
> 
> crypt
> ~
> 
> The `crypt `_ module 
> implements
> password hashing based on ``crypt(3)`` function from ``libcrypt`` or
> ``libxcrypt`` on Unix-like platform. The algorithms are mostly old, of 
> poor
> quality and insecure. Users are discouraged to use them.
> 
> * The module is not available on Windows. Cross-platform application need
>   an alternative implementation any way.
> * Only DES encryption is guarenteed to be available. DES has an extremely
>   limited key space of 2**56.
> * MD5, salted SHA256, salted SHA512, and Blowfish are optional extension.
>   SSHA256 and SSHA512 are glibc extensions. Blowfish (bcrypt) is the only
>   algorithm that is still secure. However it's in glibc and therefore not
>   commonly available on Linux.
> * Depending on the platform, the ``crypt`` module is not thread safe. Only
>   implementations with ``crypt_r(3)`` are thread safe.
> * The module was never useful to interact with system user and password
>   databases.
> 
> 
> This is actually not true. Their main use case is to compare passwords 
> against the shadowed password db:
> https://github.com/giampaolo/pyftpdlib/blob/ee7b36c701b78b2d36e938c42d08dbfbad55a34f/pyftpdlib/authorizers.py#L413
> A quick search on searchcode.com  shows both spwd and 
> crypt modules are used. I am no security expert (and I wasn’t aware they are 
> insecure until now, since the doc doesn’t mention it) but I would prefer 
> seeing these 2 fixed or improved rather than bluntly removed. 

No, the statement is correct. I may have to explain this even further.

The approach in pyftpdlib is the wrong and IMO deserves a CVE. The crypt() + 
spwd() approach is flawed on multiple levels. For example it bypasses account 
restriction, access control, and login session. It also requires you to run the 
service as root and with SELinux disabled or an unconfined context -- a bad 
combination. There is only one correct way to perform a credential check: use 
PAM.

spwd can't be fixed. It could only be replaced with a completely different API 
that wraps PAM and Windows's authentication API.

Christian

PS: Authentication, authorization, and identity management are part of my day 
job at Red Hat.
___
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: update 1

On 21/05/2019 17.31, Antoine Pitrou wrote:
> 
> As I said, if the main annoyance with nntplib is the sporadic test
> failures, then the relevant tests can be disabled on CI.
> 
> NNTP itself is still used, even if less and less.

I don't like the idea to drop a third of the test cases for nntplib -- and the 
30% that actually test that Python's NNTP library can talk to an actual NNTP 
server. IMHO it's more beneficial for core development and for nntplib to have 
it maintained by somebody that cares about the library.

Even a deprecation in 3.8 means that the module has to be maintained until EOL 
of 3.9, which is around 2026.

Christian
___
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: update 1

On Tue, 21 May 2019 at 21:13, Christian Heimes  wrote:

> crypt
> ~
>
> The `crypt `_ module
> implements
> password hashing based on ``crypt(3)`` function from ``libcrypt`` or
> ``libxcrypt`` on Unix-like platform. The algorithms are mostly old, of poor
> quality and insecure. Users are discouraged to use them.
>
> * The module is not available on Windows. Cross-platform application need
>   an alternative implementation any way.
> * Only DES encryption is guarenteed to be available. DES has an extremely
>   limited key space of 2**56.
> * MD5, salted SHA256, salted SHA512, and Blowfish are optional extension.
>   SSHA256 and SSHA512 are glibc extensions. Blowfish (bcrypt) is the only
>   algorithm that is still secure. However it's in glibc and therefore not
>   commonly available on Linux.
> * Depending on the platform, the ``crypt`` module is not thread safe. Only
>   implementations with ``crypt_r(3)`` are thread safe.
> * The module was never useful to interact with system user and password
>   databases.

This is actually not true. Their main use case is to compare passwords
against the shadowed password db:
https://github.com/giampaolo/pyftpdlib/blob/ee7b36c701b78b2d36e938c42d08dbfbad55a34f/pyftpdlib/authorizers.py#L413
A quick search on searchcode.com shows both spwd and crypt modules are
used. I am no security expert (and I wasn’t aware they are insecure until
now, since the doc doesn’t mention it) but I would prefer seeing these 2
fixed or improved rather than bluntly removed.

> --
Giampaolo - http://grodola.blogspot.com
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Steve Holden

Good point!

On Tue, May 21, 2019 at 2:01 PM Paul Moore  wrote:

> On Tue, 21 May 2019 at 13:50, Steve Holden  wrote:
> >
> > That seems entirely reasonable. I wonder if the larger community could
> somehow form an organization (the Dead Parrot SIG?) that would at least
> curate and monitor efforts to ensure their continued utility?
>
> I have no idea whether there is enough community support to make this
> work, but regardless, I strongly support a SIG by that name. It may
> actually be even *more* amusing if it doesn't have enough members to
> make it viable :-)
>
> Paul
>
___
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: update 1

On 21/05/2019 17.35, Guido van Rossum wrote:
> OK, sounds like nntplib can stay — this time. 
> 
> On Tue, May 21, 2019 at 08:33 Antoine Pitrou  > wrote:
> 
> 
> As I said, if the main annoyance with nntplib is the sporadic test
> failures, then the relevant tests can be disabled on CI.
> 
> NNTP itself is still used, even if less and less.

I'd rather have it moved outside the core and maintained by people that 
actually care about NNTP support.

Greg, you proposed the deprecation of nntplib. Any comments?

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

[Python-Dev] PEP 544 and dunder methods

2019-05-21 Thread Eric Snow

[originally I sent this to typing-sig but I guess it got caught up in
moderation.]

In PEP 554 [1] it says:


   - Implement metaclass functionality to detect whether a class is a
   protocol or not. Add a class attribute _is_protocol = True if that is
   the case. Verify that a protocol class only has protocol base classes in
   the MRO (except for object).

The phrase "except for object" implies that having "type" in the MRO would
not be allowed.  Was that intentional?

Perhaps I've misunderstood semantics with typing stuff (I haven't followed
much of the discussion), but there seems to be a disconnect with how
special ("dunder") methods are looked up (i.e. on classes).  Effectively,
an object's *class* has to implement the relevant "protocol".  So
disallowing "type" in the MRO means not using the PEP's functionality for
"special method" protocols (as well as metaclasses in general).  Have I
understood that right?  Is that on purpose?

Thanks for working on this, BTW.  It's a nice addition. :)

-eric


[1] https://www.python.org/dev/peps/pep-0544/#implementation-details
___
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: update 1

OK, sounds like nntplib can stay — this time.

On Tue, May 21, 2019 at 08:33 Antoine Pitrou  wrote:

>
> As I said, if the main annoyance with nntplib is the sporadic test
> failures, then the relevant tests can be disabled on CI.
>
> NNTP itself is still used, even if less and less.
>
> Regards
>
> Antoine.
>
>
> On Tue, 21 May 2019 16:12:42 +0200
> Christian Heimes  wrote:
> > Hi,
> >
> > I have updated the PEP with feedback from discussions. The highlights
> are:
> >
> > * Deprecate parser module
> > * Keep fileinput module
> > * Elaborate why crypt and spwd are dangerous and bad
> > * Improve sections for cgitb, colorsys, nntplib, and smtpd modules
> > * The colorsys, crypt, imghdr, sndhdr, and spwd sections now list
> suitable substitutions.
> > * Mention that socketserver is going to stay for http.server and
> xmlrpc.server
> > * The future maintenance section now states that the deprecated modules
> may be adopted by Python community members.
> >
> https://github.com/python/peps/compare/7799178a...2d536899?diff=unified#diff-ae358c21fa7968ee3b6c64479e051574
> >
> >
> > I'll be traveling the next couple of days and will only have limited
> opportunities to respond on feedback.
> >
> > Christian
> >
> > ---
> > PEP: 594
> > Title: Removing dead batteries from the standard library
> > Author: Christian Heimes 
> > Status: Draft
> > Type: Standards Track
> > Content-Type: text/x-rst
> > Created: 20-May-2019
> > Post-History: 21-May-2019
> >
> >
> > Abstract
> > 
> >
> > This PEP proposed a list of standard library modules to be removed from
> the
> > standard library. The modules are mostly historic data formats and APIs
> that
> > have been superseded a long time ago, e.g. Mac OS 9 and Commodore.
> >
> >
> > Rationale
> > =
> >
> > Back in the early days of Python, the interpreter came with a large set
> of
> > useful modules. This was often refrained to as "batteries included"
> > philosophy and was one of the corner stones to Python's success story.
> > Users didn't have to figure out how to download and install separate
> > packages in order to write a simple web server or parse email.
> >
> > Times have changed. The introduction of the cheese shop (PyPI),
> setuptools,
> > and later pip, it became simple and straight forward to download and
> install
> > packages. Nowadays Python has a rich and vibrant ecosystem of third party
> > packages. It's pretty much standard to either install packages from PyPI
> or
> > use one of the many Python or Linux distributions.
> >
> > On the other hand, Python's standard library is piling up cruft,
> unnecessary
> > duplication of functionality, and dispensable features. This is
> undesirable
> > for several reasons.
> >
> > * Any additional module increases the maintenance cost for the Python
> core
> >   development team. The team has limited resources, reduced maintenance
> cost
> >   frees development time for other improvements.
> > * Modules in the standard library are generally favored and seen as the
> >   de-facto solution for a problem. A majority of users only pick 3rd
> party
> >   modules to replace a stdlib module, when they have a compelling
> reason, e.g.
> >   lxml instead of `xml`. The removal of an unmaintained stdlib module
> >   increases the chances of a community contributed module to become
> widely
> >   used.
> > * A lean and mean standard library benefits platforms with limited
> resources
> >   like devices with just a few hundred kilobyte of storage (e.g. BBC
> >   Micro:bit). Python on mobile platforms like BeeWare or WebAssembly
> >   (e.g. pyodide) also benefit from reduced download size.
> >
> > The modules in the PEP have been selected for deprecation because their
> > removal is either least controversial or most beneficial. For example
> > least controversial are 30 years old multimedia formats like ``sunau``
> > audio format, which was used on SPARC and NeXT workstations in the late
> > 1980ties. The ``crypt`` module has fundamental flaws that are better
> solved
> > outside the standard library.
> >
> > This PEP also designates some modules as not scheduled for removal. Some
> > modules have been deprecated for several releases or seem unnecessary at
> > first glance. However it is beneficial to keep the modules in the
> standard
> > library, mostly for environments where installing a package from PyPI is
> not
> > an option. This can be cooperate environments or class rooms where
> external
> > code is not permitted without legal approval.
> >
> > * The usage of FTP is declining, but some files are still provided over
> >   the FTP protocol or hosters offer FTP to upload content. Therefore
> >   ``ftplib`` is going to stay.
> > * The ``optparse`` and ``getopt`` module are widely used. They are mature
> >   modules with very low maintenance overhead.
> > * According to David Beazley [5]_ the ``wave`` module is easy to teach to
> >   kids and can mak

Re: [Python-Dev] PEP 594: update 1


As I said, if the main annoyance with nntplib is the sporadic test
failures, then the relevant tests can be disabled on CI.

NNTP itself is still used, even if less and less.

Regards

Antoine.


On Tue, 21 May 2019 16:12:42 +0200
Christian Heimes  wrote:
> Hi,
> 
> I have updated the PEP with feedback from discussions. The highlights are:
> 
> * Deprecate parser module
> * Keep fileinput module
> * Elaborate why crypt and spwd are dangerous and bad
> * Improve sections for cgitb, colorsys, nntplib, and smtpd modules
> * The colorsys, crypt, imghdr, sndhdr, and spwd sections now list suitable 
> substitutions.
> * Mention that socketserver is going to stay for http.server and xmlrpc.server
> * The future maintenance section now states that the deprecated modules may 
> be adopted by Python community members.
> https://github.com/python/peps/compare/7799178a...2d536899?diff=unified#diff-ae358c21fa7968ee3b6c64479e051574
> 
> 
> I'll be traveling the next couple of days and will only have limited 
> opportunities to respond on feedback.
> 
> Christian
> 
> ---
> PEP: 594
> Title: Removing dead batteries from the standard library
> Author: Christian Heimes 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 20-May-2019
> Post-History: 21-May-2019
> 
> 
> Abstract
> 
> 
> This PEP proposed a list of standard library modules to be removed from the
> standard library. The modules are mostly historic data formats and APIs that
> have been superseded a long time ago, e.g. Mac OS 9 and Commodore.
> 
> 
> Rationale
> =
> 
> Back in the early days of Python, the interpreter came with a large set of
> useful modules. This was often refrained to as "batteries included"
> philosophy and was one of the corner stones to Python's success story.
> Users didn't have to figure out how to download and install separate
> packages in order to write a simple web server or parse email.
> 
> Times have changed. The introduction of the cheese shop (PyPI), setuptools,
> and later pip, it became simple and straight forward to download and install
> packages. Nowadays Python has a rich and vibrant ecosystem of third party
> packages. It's pretty much standard to either install packages from PyPI or
> use one of the many Python or Linux distributions.
> 
> On the other hand, Python's standard library is piling up cruft, unnecessary
> duplication of functionality, and dispensable features. This is undesirable
> for several reasons.
> 
> * Any additional module increases the maintenance cost for the Python core
>   development team. The team has limited resources, reduced maintenance cost
>   frees development time for other improvements.
> * Modules in the standard library are generally favored and seen as the
>   de-facto solution for a problem. A majority of users only pick 3rd party
>   modules to replace a stdlib module, when they have a compelling reason, e.g.
>   lxml instead of `xml`. The removal of an unmaintained stdlib module
>   increases the chances of a community contributed module to become widely
>   used.
> * A lean and mean standard library benefits platforms with limited resources
>   like devices with just a few hundred kilobyte of storage (e.g. BBC
>   Micro:bit). Python on mobile platforms like BeeWare or WebAssembly
>   (e.g. pyodide) also benefit from reduced download size.
> 
> The modules in the PEP have been selected for deprecation because their
> removal is either least controversial or most beneficial. For example
> least controversial are 30 years old multimedia formats like ``sunau``
> audio format, which was used on SPARC and NeXT workstations in the late
> 1980ties. The ``crypt`` module has fundamental flaws that are better solved
> outside the standard library.
> 
> This PEP also designates some modules as not scheduled for removal. Some
> modules have been deprecated for several releases or seem unnecessary at
> first glance. However it is beneficial to keep the modules in the standard
> library, mostly for environments where installing a package from PyPI is not
> an option. This can be cooperate environments or class rooms where external
> code is not permitted without legal approval.
> 
> * The usage of FTP is declining, but some files are still provided over
>   the FTP protocol or hosters offer FTP to upload content. Therefore
>   ``ftplib`` is going to stay.
> * The ``optparse`` and ``getopt`` module are widely used. They are mature
>   modules with very low maintenance overhead.
> * According to David Beazley [5]_ the ``wave`` module is easy to teach to
>   kids and can make crazy sounds. Making a computer generate crazy sounds is
>   powerful and highly motivating exercise for a 9yo aspiring developer. It's
>   a fun battery to keep.
> 
> 
> Deprecation schedule
> 
> 
> 3.8
> ---
> 
> This PEP targets Python 3.8. Version 3.8.0 final is scheduled to be released
> a few mo

[Python-Dev] PEP 558: Defined semantics for locals()

2019-05-21 Thread Nick Coghlan

Hi folks,

After a couple of years hiatus, I finally got back to working on the
reference implementation for PEP 558, my proposal to resolve some
weird interactions between closures and trace functions in CPython by
formally defining the expected semantics of the locals() builtin at
function scope, and then ensuring that CPython adheres to those
clarified semantics.

The full text of the PEP is included below, and the rendered version
is available at https://www.python.org/dev/peps/pep-0558/

The gist of the PEP is that:

1. The behaviour when no trace functions are installed and no frame
introspection APIs are invoked is fine, so nothing should change in
that regard (except that we elevate that behaviour from "the way
CPython happens to work" to "the way the language and library
reference says that Python implementations are supposed to work", and
make sure CPython continues to behave that way even when a trace hook
*is* installed)
2. If you get hold of a frame object in CPython (or another
implementation that emulates the CPython frame API), whether via a
trace hook or via a frame introspection API, then writing to the
returned mapping will update the actual function locals and/or closure
reference immediately, rather than relying on the
FastToLocals/LocalsToFast APIs
3. The LocalsToFast C API changes to always produce RuntimeError
(since there's no way for us to make it actually work correctly and
consistently in the presence of closures, and the trace hook
implementation won't need it any more given the write-through proxy
behaviour on frame objects' "f_locals" attribute)

The reference implementation still isn't quite done yet, but it's far
enough along that I'm happy with the semantics and C API updates
proposed in the current version of the PEP.

Cheers,
Nick.

P.S. I'm away this weekend, so I expect the reference implementation
to be done late next week, and I'd be submitting the PEP to Nathaniel
for formal pronouncement at that point. However, I'm posting this
thread now so that there's more time for discussion prior to the 3.8b1
deadline.

==
PEP: 558
Title: Defined semantics for locals()
Author: Nick Coghlan 
BDFL-Delegate: Nathaniel J. Smith
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2017-09-08
Python-Version: 3.8
Post-History: 2017-09-08, 2019-05-22


Abstract


The semantics of the ``locals()`` builtin have historically been underspecified
and hence implementation dependent.

This PEP proposes formally standardising on the behaviour of the CPython 3.6
reference implementation for most execution scopes, with some adjustments to the
behaviour at function scope to make it more predictable and independent of the
presence or absence of tracing functions.


Rationale
=

While the precise semantics of the ``locals()`` builtin are nominally undefined,
in practice, many Python programs depend on it behaving exactly as it behaves in
CPython (at least when no tracing functions are installed).

Other implementations such as PyPy are currently replicating that behaviour,
up to and including replication of local variable mutation bugs that
can arise when a trace hook is installed [1]_.

While this PEP considers CPython's current behaviour when no trace hooks are
installed to be acceptable (and largely desirable), it considers the current
behaviour when trace hooks are installed to be problematic, as it causes bugs
like [1]_ *without* even reliably enabling the desired functionality of allowing
debuggers like ``pdb`` to mutate local variables [3]_.


Proposal


The expected semantics of the ``locals()`` builtin change based on the current
execution scope. For this purpose, the defined scopes of execution are:

* module scope: top-level module code, as well as any other code executed using
  ``exec()`` or ``eval()`` with a single namespace
* class scope: code in the body of a ``class`` statement, as well as any other
  code executed using ``exec()`` or ``eval()`` with separate local and global
  namespaces
* function scope: code in the body of a ``def`` or ``async def`` statement

We also allow interpreters to define two "modes" of execution, with only the
first mode being considered part of the language specification itself:

* regular operation: the way the interpreter behaves by default
* tracing mode: the way the interpreter behaves when a trace hook has been
  registered in one or more threads via an implementation dependent mechanism
  like ``sys.settrace`` ([4]_) in CPython's ``sys`` module or
  ``PyEval_SetTrace`` ([5]_) in CPython's C API

For regular operation, this PEP proposes elevating the current behaviour of
the CPython reference implementation to become part of the language
specification.

For tracing mode, this PEP proposes changes to CPython's behaviour at function
scope that bring the ``locals()`` builtin semantics closer to those used in
regular operation, while also making the related frame API semantics clearer
and easier fo

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

+1. Let's keep colorsys then.

On Tue, May 21, 2019 at 7:41 AM Petr Viktorin  wrote:

> On 5/21/19 12:06 PM, Christian Heimes wrote:
> > On 21/05/2019 11.49, Nathaniel Smith wrote:
> >> On Tue, May 21, 2019 at 2:40 AM Walter Dörwald 
> wrote:
> >>>
> >>> On 20 May 2019, at 22:15, Christian Heimes wrote:
> >>>
>  Hi,
> 
>  here is the first version of my PEP 594 to deprecate and eventually
>  remove modules from the standard library. The PEP started last year
>  with talk during the Python Language Summit 2018,
>  https://lwn.net/Articles/755229/.
> 
>  [...]
> 
>  colorsys
>  
> 
>  The `colorsys `_
>  module
>  defines color conversion functions between RGB, YIQ, HSL, and HSV
>  coordinate
>  systems. The Pillow library provides much faster conversation between
>  color systems.
> 
>  Module type
> pure Python
>  Deprecated in
> 3.8
>  To be removed in
> 3.10
>  Substitute
> `Pillow `_,
> `colorspacious `_
> >>>
> >>> I'm using colorsys constantly as the basis for a tool that converts CSS
> >>> colors between different coordinate systems. I don't see how that could
> >>> be done via Pillow (which AFAICT only converts complete images).
> >>> RGB<->HSV<->HLS conversion seems to be not available (or not obvious)
> in
> >>> colorspacious.
> >>
> >> Correct, colorspacious doesn't support HSV or HLS. I suppose it would
> >> be trivial enough to add...
> >>
> >> The 'colour' package has them (along with everything else you can
> >> dream of): https://colour.readthedocs.io/en/latest/colour.models.html
> >
> > Nice catch, I just added
> https://python-colormath.readthedocs.io/en/latest/ to my update PR. I'll
> add colour to the list, too.
> >
> > (It didn't pop up on my radar because I wasn't checking for British
> spelling)
> >
> > Christian
>
>
> Please, don't remove colorsys. HSL and HSV aren't outdated, and AFAIK,
> the module is not a maintenance burden.
>
> The packages on PyPI offer more advanced models. Perhaps they could be
> linked in the documentation, if we want to endorse them. But just as
> we're not removing `array` in favor of `numpy`, we shouldn't remove
> colorsys either. Colorsys is not dead, it's just small.
>
> I assume one of the reasons colorspacious doesn't support HSV or HLS is
> that HSV/HLS tends to be used for quite different purposes than the more
> fancy color spaces. You'd use HSL/HSV for a simple color picker or a
> saturation shift on a web page, GUI or game (where you don't have
> *exact* colors anyway); things like sRGB or CIELab are for color
> management, photos, printing, etc.
>
> ___
> 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/guido%40python.org
>


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

___
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: Removing dead batteries from the standard library

Quick note on the pip discussion: if the likely remaining users of a module
slated for deprecation are professionals maintaining some legacy code, pip
is a fine solution. OTOH if the likely users are beginners, maybe pip is
not great.

In general I think it's fine to err on the side of caution -- as someone
already said, we're only removing *dead* batteries, not *leaky* ones. If
there's too much pushback for a particular module, maybe it's not dead yet.
We can make another list in a few years.

On Tue, May 21, 2019 at 6:28 AM Paul Moore  wrote:

> On Tue, 21 May 2019 at 14:03, Steven D'Aprano  wrote:
>
> > I know that saying anything against pip and virtual environments is
> > heresy, but honestly, "just install it from PyPI" is not friendly to
> > beginners or those who just want something that works without a load of
> > extra complexity.
>
> Speaking as a pip developer, I 100% support this comment. For a major
> segment of Python's user base, if something isn't in the stdlib (or
> their preferred distribution - Anaconda or a Linux distro, for
> example) then it's a significant step upward in complexity.
>
> Having said this, I'm not as sure I agree with the rest of Steven's
> posting. I think that in general, this PEP is sensible and strikes a
> good balance. It's all very well saying "the Python core devs aren't
> willing to support these libraries any more" - but being quite that
> blunt invites a backlash. The PEP demonstrates that we're doing due
> dilligence over the process, and even if some people disagree with the
> decisions made, the arguments have been made in public. "You can get
> equivalents off PyPI" is only a very minor part of the argument here,
> the main thrust being "... and in general we don't think many people
> need to". It's a judgement call, and it needs review, but "rarely
> used" captures the sense well enough (given that we want a short
> phrase, not an explanatory paragraph...)
>
> Regarding the title, It strikes me as fine, it's a slightly light
> hearted play on the "batteries included" idea, and even if the
> batteries in question aren't entirely dead, they are definitely pinin'
> for the fjords. Discussions like this need a bit of levity to keep us
> all grounded, IMO.
>
> Paul
> ___
> 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/guido%40python.org
>


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

___
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: Removing dead batteries from the standard library

2019-05-21 Thread Skip Montanaro

> If this were my PEP, I'd call it "Removing unloved batteries from the 
> standard library".

Or maybe, "Removing obsolete and (potentially) dangerous batteries
from the standard library."

I can certainly understand why either class of module would be
removed. When bsddb185 was tossed out, I put it up on PyPI
(https://pypi.org/project/bsddb185/) so the source wouldn't be lost. I
never expected to actually need it, but I got pinged for the first
time a few months ago. Someone needed help building it.

So, no matter the reason for removal, I think it would be reasonable
to toss all these modules into GitHub or PyPI. Someone will want them.

Skip
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Petr Viktorin


On 5/21/19 12:06 PM, Christian Heimes wrote:

On 21/05/2019 11.49, Nathaniel Smith wrote:

On Tue, May 21, 2019 at 2:40 AM Walter Dörwald  wrote:


On 20 May 2019, at 22:15, Christian Heimes wrote:


Hi,

here is the first version of my PEP 594 to deprecate and eventually
remove modules from the standard library. The PEP started last year
with talk during the Python Language Summit 2018,
https://lwn.net/Articles/755229/.

[...]

colorsys


The `colorsys `_
module
defines color conversion functions between RGB, YIQ, HSL, and HSV
coordinate
systems. The Pillow library provides much faster conversation between
color systems.

Module type
   pure Python
Deprecated in
   3.8
To be removed in
   3.10
Substitute
   `Pillow `_,
   `colorspacious `_


I'm using colorsys constantly as the basis for a tool that converts CSS
colors between different coordinate systems. I don't see how that could
be done via Pillow (which AFAICT only converts complete images).
RGB<->HSV<->HLS conversion seems to be not available (or not obvious) in
colorspacious.


Correct, colorspacious doesn't support HSV or HLS. I suppose it would
be trivial enough to add...

The 'colour' package has them (along with everything else you can
dream of): https://colour.readthedocs.io/en/latest/colour.models.html


Nice catch, I just added https://python-colormath.readthedocs.io/en/latest/ to 
my update PR. I'll add colour to the list, too.

(It didn't pop up on my radar because I wasn't checking for British spelling)

Christian



Please, don't remove colorsys. HSL and HSV aren't outdated, and AFAIK, 
the module is not a maintenance burden.


The packages on PyPI offer more advanced models. Perhaps they could be 
linked in the documentation, if we want to endorse them. But just as 
we're not removing `array` in favor of `numpy`, we shouldn't remove 
colorsys either. Colorsys is not dead, it's just small.


I assume one of the reasons colorspacious doesn't support HSV or HLS is 
that HSV/HLS tends to be used for quite different purposes than the more 
fancy color spaces. You'd use HSL/HSV for a simple color picker or a 
saturation shift on a web page, GUI or game (where you don't have 
*exact* colors anyway); things like sRGB or CIELab are for color 
management, photos, printing, etc.


___
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] deprecation of abstractstaticmethod and abstractclassmethod

2019-05-21 Thread Nick Coghlan

On Thu, 16 May 2019 at 06:03, Steve Dower  wrote:
>
> On 15May2019 1248, Nathaniel Smith wrote:
> > I don't care about the deprecation either way. But can we fix the
> > individual decorators so both orders work? Even if it requires a special
> > case in the code, it seems worthwhile to remove a subtle user-visible
> > footgun.
>
> The classmethod and staticmethod objects already have a getter for
> __isabstractmethod__ that forwards to the underlying object, so they
> should just need a setter as well, right?

I believe the problem with the reverse direction relates to
abstractmethod correctly forwarding __get__ to the underlying
descriptor (or not), rather than having anything to do with the
`__isabstractmethod__` property forwarding.

However, I *don't* recall if we ever actually tried to make the
reverse direction work - it may be that there's a relatively shallow
enhancement that would let `@abstractmethod` wrap arbitrary decorators
correctly.

> I also have no strong opinion about deprecation. But fixing this seems
> pretty straightforward and may be a good task for someone's first C
> contribution?

If the reverse order can be made to work, that would be good, but if
that proves intractable, Ethan's suggestion of reversing the
documented deprecation makes sense.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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: Removing dead batteries from the standard library

On 21/05/2019 15.54, Victor Stinner wrote:
> IMHO we should simply acknowledge this fact by mentioning it in the
> PEP. We are aware that "pip install" is not always a valid option, but
> we decided anyway to deprecate/remove modules because <...>.

I like the idea. Could you create an issue or PR, please?

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

[Python-Dev] PEP 594: update 1

Hi,

I have updated the PEP with feedback from discussions. The highlights are:

* Deprecate parser module
* Keep fileinput module
* Elaborate why crypt and spwd are dangerous and bad
* Improve sections for cgitb, colorsys, nntplib, and smtpd modules
* The colorsys, crypt, imghdr, sndhdr, and spwd sections now list suitable
substitutions.
* Mention that socketserver is going to stay for http.server and xmlrpc.server
* The future maintenance section now states that the deprecated modules may be
adopted by Python community members.
https://github.com/python/peps/compare/7799178a...2d536899?diff=unified#diff-ae358c21fa7968ee3b6c64479e051574

I'll be traveling the next couple of days and will only have limited
opportunities to respond on feedback.

Christian

---
PEP: 594
Title: Removing dead batteries from the standard library
Author: Christian Heimes
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 20-May-2019
Post-History: 21-May-2019

Abstract

This PEP proposed a list of standard library modules to be removed from the
standard library. The modules are mostly historic data formats and APIs that
have been superseded a long time ago, e.g. Mac OS 9 and Commodore.

Rationale
=

Back in the early days of Python, the interpreter came with a large set of
useful modules. This was often refrained to as "batteries included"
philosophy and was one of the corner stones to Python's success story.
Users didn't have to figure out how to download and install separate
packages in order to write a simple web server or parse email.

Times have changed. The introduction of the cheese shop (PyPI), setuptools,
and later pip, it became simple and straight forward to download and install
packages. Nowadays Python has a rich and vibrant ecosystem of third party
packages. It's pretty much standard to either install packages from PyPI or
use one of the many Python or Linux distributions.

On the other hand, Python's standard library is piling up cruft, unnecessary
duplication of functionality, and dispensable features. This is undesirable
for several reasons.

* Any additional module increases the maintenance cost for the Python core
development team. The team has limited resources, reduced maintenance cost
frees development time for other improvements.
* Modules in the standard library are generally favored and seen as the
de-facto solution for a problem. A majority of users only pick 3rd party
modules to replace a stdlib module, when they have a compelling reason, e.g.
lxml instead of `xml`. The removal of an unmaintained stdlib module
increases the chances of a community contributed module to become widely
used.
* A lean and mean standard library benefits platforms with limited resources
like devices with just a few hundred kilobyte of storage (e.g. BBC
Micro:bit). Python on mobile platforms like BeeWare or WebAssembly
(e.g. pyodide) also benefit from reduced download size.

The modules in the PEP have been selected for deprecation because their
removal is either least controversial or most beneficial. For example
least controversial are 30 years old multimedia formats like ``sunau``
audio format, which was used on SPARC and NeXT workstations in the late
1980ties. The ``crypt`` module has fundamental flaws that are better solved
outside the standard library.

This PEP also designates some modules as not scheduled for removal. Some
modules have been deprecated for several releases or seem unnecessary at
first glance. However it is beneficial to keep the modules in the standard
library, mostly for environments where installing a package from PyPI is not
an option. This can be cooperate environments or class rooms where external
code is not permitted without legal approval.

* The usage of FTP is declining, but some files are still provided over
the FTP protocol or hosters offer FTP to upload content. Therefore
``ftplib`` is going to stay.
* The ``optparse`` and ``getopt`` module are widely used. They are mature
modules with very low maintenance overhead.
* According to David Beazley [5]_ the ``wave`` module is easy to teach to
kids and can make crazy sounds. Making a computer generate crazy sounds is
powerful and highly motivating exercise for a 9yo aspiring developer. It's
a fun battery to keep.

Deprecation schedule

3.8
---

This PEP targets Python 3.8. Version 3.8.0 final is scheduled to be released
a few months before Python 2.7 will reach its end of lifetime. We expect that
Python 3.8 will be targeted by users that migrate to Python 3 in 2019 and
2020. To reduce churn and to allow a smooth transition from Python 2,
Python 3.8 will neither raise `DeprecationWarning` nor remove any
modules that have been scheduled for removal. Instead deprecated modules will
just be *documented* as deprecated. Optionally modules may emit a
`PendingDeprecationWarning`.

All deprecated

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

IMHO we should simply acknowledge this fact by mentioning it in the
PEP. We are aware that "pip install" is not always a valid option, but
we decided anyway to deprecate/remove modules because <...>.

Victor

Le mar. 21 mai 2019 à 15:29, Paul Moore  a écrit :
>
> On Tue, 21 May 2019 at 14:03, Steven D'Aprano  wrote:
>
> > I know that saying anything against pip and virtual environments is
> > heresy, but honestly, "just install it from PyPI" is not friendly to
> > beginners or those who just want something that works without a load of
> > extra complexity.
>
> Speaking as a pip developer, I 100% support this comment. For a major
> segment of Python's user base, if something isn't in the stdlib (or
> their preferred distribution - Anaconda or a Linux distro, for
> example) then it's a significant step upward in complexity.
>
> Having said this, I'm not as sure I agree with the rest of Steven's
> posting. I think that in general, this PEP is sensible and strikes a
> good balance. It's all very well saying "the Python core devs aren't
> willing to support these libraries any more" - but being quite that
> blunt invites a backlash. The PEP demonstrates that we're doing due
> dilligence over the process, and even if some people disagree with the
> decisions made, the arguments have been made in public. "You can get
> equivalents off PyPI" is only a very minor part of the argument here,
> the main thrust being "... and in general we don't think many people
> need to". It's a judgement call, and it needs review, but "rarely
> used" captures the sense well enough (given that we want a short
> phrase, not an explanatory paragraph...)
>
> Regarding the title, It strikes me as fine, it's a slightly light
> hearted play on the "batteries included" idea, and even if the
> batteries in question aren't entirely dead, they are definitely pinin'
> for the fjords. Discussions like this need a bit of levity to keep us
> all grounded, IMO.
>
> Paul
> ___
> 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/vstinner%40redhat.com



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Paul Moore

On Tue, 21 May 2019 at 14:03, Steven D'Aprano  wrote:

> I know that saying anything against pip and virtual environments is
> heresy, but honestly, "just install it from PyPI" is not friendly to
> beginners or those who just want something that works without a load of
> extra complexity.

Speaking as a pip developer, I 100% support this comment. For a major
segment of Python's user base, if something isn't in the stdlib (or
their preferred distribution - Anaconda or a Linux distro, for
example) then it's a significant step upward in complexity.

Having said this, I'm not as sure I agree with the rest of Steven's
posting. I think that in general, this PEP is sensible and strikes a
good balance. It's all very well saying "the Python core devs aren't
willing to support these libraries any more" - but being quite that
blunt invites a backlash. The PEP demonstrates that we're doing due
dilligence over the process, and even if some people disagree with the
decisions made, the arguments have been made in public. "You can get
equivalents off PyPI" is only a very minor part of the argument here,
the main thrust being "... and in general we don't think many people
need to". It's a judgement call, and it needs review, but "rarely
used" captures the sense well enough (given that we want a short
phrase, not an explanatory paragraph...)

Regarding the title, It strikes me as fine, it's a slightly light
hearted play on the "batteries included" idea, and even if the
batteries in question aren't entirely dead, they are definitely pinin'
for the fjords. Discussions like this need a bit of levity to keep us
all grounded, IMO.

Paul
___
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: Removing dead batteries from the standard library

On 21/05/2019 15.01, Steven D'Aprano wrote:
> Christian, I'm glad that you are privileged enough to find it simple and 
> straight forward to download and install, but for many Python users, it 
> is not so simple or straight forward.
> 
> Many Python users don't have the privilege of being able to install 
> arbitrary, unvetted packages from PyPI. They get to use only packages 
> from approved vendors, including the stdlib, what they write themselves, 
> and nothing else. Please don't dismiss this part of the Python community 
> just because they don't typically hang around in the same forums we do.
> 
> I've worked with organisations where downloading and installing software 
> from the internet was grounds for instant dismissal. I've worked with 
> organisations with regulatory requirements to do due-dilegance on their 
> entire software stack, and getting permission to install an unapproved 
> library could take 3-6 months elapsed time and dozens of person-hours, 
> including a full review of the licencing and copyright by lawyers.
> 
> I've also worked with kids using school computers who don't have either 
> the legal permission or the knowledge to use pip install.
> 
> Sometimes their school administrators are ... how shall I put this 
> kindly? ... over zealous in their efforts to protect the students from 
> malware and spyware (apart from the school's own spyware, of course...) 
> and rather lacking in their understanding of the difference between 
> piracy and Open Source software. Getting Python installed by the school 
> admiinistrator is one thing, but allowing the kids to run pip and 
> install software themselves is unthinkable.
> 
> And remember, in some juristictions, installing software from the 
> internet can put you in breach of some draconian laws. At the very 
> least, kids may face expulsion.

This argument has bring brought up several times. For that reason the PEP lists 
mostly modules that deal with historic and irrelevant data formats. The wave 
module stays because it is useful in education contexts. The use case is 
explicitly mentioned in the latest version of the PEP.

Do you have a concrete and tangible case example, in which a deprecated module 
is absolutely necessary, a user gets permission to update Python, but does not 
get permission to get a PyPI package installed?

You could argue that cgi, spwd, and crypt are not history data formats. My 
counter argument: *If* you have to work in a severely restricted environment, 
*then* you are surely not allowed to run your own CGI web server or access the 
system password database.
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Paul Moore

On Tue, 21 May 2019 at 13:50, Steve Holden  wrote:
>
> That seems entirely reasonable. I wonder if the larger community could 
> somehow form an organization (the Dead Parrot SIG?) that would at least 
> curate and monitor efforts to ensure their continued utility?

I have no idea whether there is enough community support to make this
work, but regardless, I strongly support a SIG by that name. It may
actually be even *more* amusing if it doesn't have enough members to
make it viable :-)

Paul
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Steven D'Aprano

The PEP title is prejudicial and inaccurate. These aren't "dead 
batteries", these are *working batteries* that you want to remove.

If you want a fair and open debate on this, please change the title to 
something less prejudicial. If this were my PEP, I'd call it "Removing 
unloved batteries from the standard library".

On Mon, May 20, 2019 at 10:15:22PM +0200, Christian Heimes wrote:

> Times have changed. The introduction of the cheese shop (PyPI), setuptools,
> and later pip, it became simple and straight forward to download and install
> packages. Nowadays Python has a rich and vibrant ecosystem of third party
> packages. It's pretty much standard to either install packages from PyPI or
> use one of the many Python or Linux distributions.

Christian, I'm glad that you are privileged enough to find it simple and 
straight forward to download and install, but for many Python users, it 
is not so simple or straight forward.

Many Python users don't have the privilege of being able to install 
arbitrary, unvetted packages from PyPI. They get to use only packages 
from approved vendors, including the stdlib, what they write themselves, 
and nothing else. Please don't dismiss this part of the Python community 
just because they don't typically hang around in the same forums we do.

I've worked with organisations where downloading and installing software 
from the internet was grounds for instant dismissal. I've worked with 
organisations with regulatory requirements to do due-dilegance on their 
entire software stack, and getting permission to install an unapproved 
library could take 3-6 months elapsed time and dozens of person-hours, 
including a full review of the licencing and copyright by lawyers.

I've also worked with kids using school computers who don't have either 
the legal permission or the knowledge to use pip install.

Sometimes their school administrators are ... how shall I put this 
kindly? ... over zealous in their efforts to protect the students from 
malware and spyware (apart from the school's own spyware, of course...) 
and rather lacking in their understanding of the difference between 
piracy and Open Source software. Getting Python installed by the school 
admiinistrator is one thing, but allowing the kids to run pip and 
install software themselves is unthinkable.

And remember, in some juristictions, installing software from the 
internet can put you in breach of some draconian laws. At the very 
least, kids may face expulsion.

Despite all the advances in packaging and installation, many people 
still do have trouble installing third-party software. Internet forums 
are full of people asking for help troubleshooting pip install.

"Simple and straight forward" it might be for an expert, but many Python 
users are not experts. The Internet is full of difficult, conflicting 
and/or bad advice about installing software ("just use sudo pip 
install"). Let's look at this advice from Red Hat:

If you want to use third-party packages, create a virtual 
environment using python3 -m venv --system-site-packages myenv 
(or for Python 2, install python2-virtualenv and run python2 
-m virtualenv --system-site-packages myenv). Then, activate 
the environment using source myenv/bin/activate, and install 
packages into it using pip install. The packages will then be 
available as long as the environment is activated.

https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/

That's some serious barrier to entry right there. We're going from:

batteries included

to 

what's a virtual enviroment? what's activation? why isn't pip 
working for me?

I know that saying anything against pip and virtual environments is 
heresy, but honestly, "just install it from PyPI" is not friendly to 
beginners or those who just want something that works without a load of 
extra complexity.

-- 
Steven
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Ned Batchelder


On 5/21/19 8:37 AM, Christian Heimes wrote:

On 21/05/2019 14.06, Anders Munch wrote:

Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På vegne 
af Christian Heimes

* The removed modules will be available through PyPI.

Will they?  That's not the impression I got from the PEP.

It's all open source. It's up to the Python community to adopt packages and 
provide them on PyPI.

Python core will not maintain and distribute the packages. I'll merely provide 
a repository with packages to help kick-starting the process.



This statement should be in the PEP in some form. For example: "The 
modules could be made available on PyPI. The Python core team will not 
publish or maintain the packages."


--Ned.

___
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: Removing dead batteries from the standard library

2019-05-21 Thread Steve Holden

That seems entirely reasonable. I wonder if the larger community could
somehow form an organization (the Dead Parrot SIG?) that would at least
curate and monitor efforts to ensure their continued utility?


On Tue, May 21, 2019 at 1:40 PM Christian Heimes 
wrote:

> On 21/05/2019 14.06, Anders Munch wrote:
> > Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org]
> På vegne af Christian Heimes
> >> * The removed modules will be available through PyPI.
> >
> > Will they?  That's not the impression I got from the PEP.
>
> It's all open source. It's up to the Python community to adopt packages
> and provide them on PyPI.
>
> Python core will not maintain and distribute the packages. I'll merely
> provide a repository with packages to help kick-starting the process.
>
> Christian
> ___
> 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/steve%40holdenweb.com
>
___
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: Removing dead batteries from the standard library

On 21/05/2019 14.06, Anders Munch wrote:
> Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På 
> vegne af Christian Heimes
>> * The removed modules will be available through PyPI.
> 
> Will they?  That's not the impression I got from the PEP. 

It's all open source. It's up to the Python community to adopt packages and 
provide them on PyPI.

Python core will not maintain and distribute the packages. I'll merely provide 
a repository with packages to help kick-starting the process.

Christian
___
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: Removing dead batteries from the standard library

On Dienstag, 21. Mai 2019 13:46:34 CEST Christian Heimes wrote:
> On 21/05/2019 13.08, André Malo wrote:
> > On Montag, 20. Mai 2019 23:27:49 CEST Antoine Pitrou wrote:
> >> NNTP is still quite used (often through GMane, but probably not only)
> >> so
> >> I'd question the removal of nntplib.
> >> 
> >> cgitb used to be used by some Web frameworks in order to format
> >> exceptions.  Perhaps one should check if that's still the case.
> > 
> > I concur with both of those.
> > There's software in production using both. (It doesn't mean it's on pypi
> > or even free software).
> 
> There is always somebody who uses a feature. This argument blocks any
> innovation or cleanup. Victor just reminded me of https://xkcd.com/1172/
> .
> 
> * The removed modules will be available through PyPI.
> * You don't have to start to worry until Python 3.10 is released in over 3
> years from now. * The modules are fully supported in Python 3.8 and 3.9.
> Python 3.9 will reach EOL late 2026 or early 2027.

Correct. However that's a valid argument for the whole stdlib.

I agree with Victor  (in the other branch), that we should call the PEP how 
it's meant.
It effectively boils down to: "We don't want to maintain these modules 
anymore, volunteers step forward within the next 3 years". It would 
definitely draw a clear line and cut short a lot of discussions (like this 
one).
And it would be perfectly fine, for me at least.

nd
-- 
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://www.perlig.de  #


___
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: Removing dead batteries from the standard library

On 21/05/2019 13.50, Victor Stinner wrote:
> Hi Christian,
> 
> I dislike the PEP 594 title: "Removing dead batteries from the
> standard library". A module is never "dead", there are always users,
> even if there are less than 5 of them.

I'm open for suggestions for a better title.

> Extract of the Rationale: "The modules are mostly historic data
> formats and APIs that have been superseded a long time ago"
> 
> If we take the example of NNTP: even if it's old and "superseded",
> people still uses NTTP. Python doesn't have to be opinionated about
> formats.

NNTP was added late in the writing of the PEP. I can rephrase the rational

> Wait, I like the overall PEP. I'm just talking about how it's explained.
> 
> IMHO the question here is if the core developers want to continue to
> pay the price of the maintenance burden for modules which have "few"
> users (define few...). The other question is if it would be acceptable
> to move these modules to PyPI. "import wave" would continue to work as
> previously, but the maintenance would be moved *outside* Python.
> 
> Who will maintain these modules on PyPI? Do we have to define this right now?

Whoever steps up and is interested to maintain the module. But we don't have to 
define this now. We have more than a year to come up with a plan. Except for 
the parser module, all modules will be maintained by Python core until 2026.

> If a module is pure Python, well, the easy solution is to embed it
> into your code: cp /path/to/cpython/Lib/.py
> /path/to/yourapp/.py. If it's a C extension, it's more
> complicated.

This only affects nis, ossaudiodev, spwd, and msi. For crypt I already have a 
ctypes wrapper. ossaudiodev is dead and has been replaced by ALSA about two 
decades ago. spwd is bad and users should use PAM instead.

> The PEP is full of "Substitute: none". I'm not comfortable with that.
> I would prefer to require that there is always a solution, like
> putting the code on PyPI and let it die there. The old mojo "the
> stdlib is where modules die" would become "PyPI is where old stdlib
> modules die" :-)

The latest version of the PEP lists many additional substitutes. I'll post a 
new version soonish.

 
> Python itself is bad at fixing DeprecationWarning: imp and asyncore
> are deprecated for years, but they are still widely used inside
> Python...

We are keeping the old packages to make transition from 2.7 to 3.8 easier. This 
is going to change with 3.9.

> I dislike DeprecationWarning *but* ... well, does it really hurt so
> much to keep these modules around? asyncore has know bugs, *but* many
> tests of our test suite are based on that and we managed to make these
> tests very reliable only with minor work.

I'm struggeling with asyncore in SSL tests, mostly because I don't grasp how 
asyncore works and I have no intention to dig into a deprecated technology.

> Even if it's not said this way, in fact this PEP reopens the question
> of splitting the stdlib. It would be helpful to have some references
> into the PEP about previous discussions on this topic. Recent
> discussion:
> 
> "Amber Brown: Batteries Included, But They're Leaking "
> http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html
> 
> By the way, even if it's not directly related, the PEP doesn't address
> one of the common question: be able to override a stdlib module with a
> more recent version. For example, if the Python provided by your OS
> contains a bug in asyncio, you are stuck and cannot easily upgrade it
> to get a new version without the fix.

As you said, it's not directly related. These topics are not within scope for 
the PEP. Please open a new thread. I like to keep this thread on topic.


> For me, "getopt" is a dead battery. The PEP says "Although users are
> encouraged to use argparse instead, the getopt module is still widely
> used."
> 
> Well, that makes sense. But so, what is the metric to decide if a
> module is "widely used" or not?
> 
> Should we keep a module at soon as at least one user says "I'm using
> it!". In other replies, users asked to keep spwd, fileinput, nntplib,
> etc.

getopt is very short, has no maintainance overhead, and useful for quick hacks. 
fileinput stays as well for the same reason.

> Sorry, I mostly opened questions. I don't have answers. I just wanted
> to share that this PEP scares me a little bit. At least, the current
> version of the PEP.

The PEP will be implemented over a course of two releases and three years. It 
gives us enough time to address concern or change our minds.

Christian
___
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: Removing dead batteries from the standard library

On Dienstag, 21. Mai 2019 13:50:30 CEST Victor Stinner wrote:

> Well, that makes sense. But so, what is the metric to decide if a
> module is "widely used" or not?

Yes. Exactly the question that pops up right now. I think, that's the main 
issue when including batteries in general (that's not news though :-). And 
the problem I see there is: There *is* no valid answer.

(Sorry if I seem to be just annoying. That's not intended, I'm just not 
carrying the good news.)

nd
-- 
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://www.perlig.de  #

___
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: Removing dead batteries from the standard library

2019-05-21 Thread Anders Munch

Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På vegne 
af Christian Heimes
> * The removed modules will be available through PyPI.

Will they?  That's not the impression I got from the PEP. 

regards, Anders

___
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: Removing dead batteries from the standard library

Hi Christian,

I dislike the PEP 594 title: "Removing dead batteries from the
standard library". A module is never "dead", there are always users,
even if there are less than 5 of them.

Extract of the Rationale: "The modules are mostly historic data
formats and APIs that have been superseded a long time ago"

If we take the example of NNTP: even if it's old and "superseded",
people still uses NTTP. Python doesn't have to be opinionated about
formats.


Wait, I like the overall PEP. I'm just talking about how it's explained.

IMHO the question here is if the core developers want to continue to
pay the price of the maintenance burden for modules which have "few"
users (define few...). The other question is if it would be acceptable
to move these modules to PyPI. "import wave" would continue to work as
previously, but the maintenance would be moved *outside* Python.

Who will maintain these modules on PyPI? Do we have to define this right now?

If a module is pure Python, well, the easy solution is to embed it
into your code: cp /path/to/cpython/Lib/.py
/path/to/yourapp/.py. If it's a C extension, it's more
complicated.

For me the risk of the PEP 594 is to create a new Python 3 mess.
Pedantic core devs who explain to users that their code is wrong and
they must fix it... But the code was running fine for 20 years!

The PEP is full of "Substitute: none". I'm not comfortable with that.
I would prefer to require that there is always a solution, like
putting the code on PyPI and let it die there. The old mojo "the
stdlib is where modules die" would become "PyPI is where old stdlib
modules die" :-)

Python itself is bad at fixing DeprecationWarning: imp and asyncore
are deprecated for years, but they are still widely used inside
Python...

"Stop using deprecated imp module; imp should now emit a real
DeprecationWarning" is open since 2015:
https://bugs.python.org/issue25160

"Replace asyncore" open since 2016
https://bugs.python.org/issue28533

"test_poplib replace asyncore" open since 2017
https://bugs.python.org/issue30514

I dislike DeprecationWarning *but* ... well, does it really hurt so
much to keep these modules around? asyncore has know bugs, *but* many
tests of our test suite are based on that and we managed to make these
tests very reliable only with minor work.

---

Even if it's not said this way, in fact this PEP reopens the question
of splitting the stdlib. It would be helpful to have some references
into the PEP about previous discussions on this topic. Recent
discussion:

"Amber Brown: Batteries Included, But They're Leaking "
http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html

By the way, even if it's not directly related, the PEP doesn't address
one of the common question: be able to override a stdlib module with a
more recent version. For example, if the Python provided by your OS
contains a bug in asyncio, you are stuck and cannot easily upgrade it
to get a new version without the fix.

---

For me, "getopt" is a dead battery. The PEP says "Although users are
encouraged to use argparse instead, the getopt module is still widely
used."

Well, that makes sense. But so, what is the metric to decide if a
module is "widely used" or not?

Should we keep a module at soon as at least one user says "I'm using
it!". In other replies, users asked to keep spwd, fileinput, nntplib,
etc.


---

Sorry, I mostly opened questions. I don't have answers. I just wanted
to share that this PEP scares me a little bit. At least, the current
version of the PEP.

Victor


Victor
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Sebastian Rittau


Am 21.05.19 um 13:39 schrieb André Malo:


So what I hear is, this battery is definitely not dead, which is what the
PEP is all about.
it's just half charged (or discharged, depending on your POV), so to speak.

Substitute: "none" should read pypi then?


Every single module on this list will have some users. To me the 
question is: Are there enough users to justify the extra burden on the 
maintainers, but also users not using that package? (The latter will 
have to download the package, have it installed on their systems, it 
makes it harder to find other things in the documentation etc.) If there 
not many users left, I believe these should either vendor the last 
official package or to band together to maintain the package themselves 
on pypi.


 - Sebastian


___
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: Removing dead batteries from the standard library

On 21/05/2019 13.08, André Malo wrote:
> On Montag, 20. Mai 2019 23:27:49 CEST Antoine Pitrou wrote:
>> NNTP is still quite used (often through GMane, but probably not only) so
>> I'd question the removal of nntplib.
>>
>> cgitb used to be used by some Web frameworks in order to format
>> exceptions.  Perhaps one should check if that's still the case.
> 
> I concur with both of those.
> There's software in production using both. (It doesn't mean it's on pypi or 
> even free software).

There is always somebody who uses a feature. This argument blocks any 
innovation or cleanup. Victor just reminded me of https://xkcd.com/1172/ .

* The removed modules will be available through PyPI.
* You don't have to start to worry until Python 3.10 is released in over 3 
years from now.
* The modules are fully supported in Python 3.8 and 3.9. Python 3.9 will reach 
EOL late 2026 or early 2027.

That's plenty of time.

Christian
___
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: Removing dead batteries from the standard library

On Dienstag, 21. Mai 2019 13:24:34 CEST Victor Stinner wrote:
> Le mar. 21 mai 2019 à 13:18, André Malo  a écrit :
> > There's software in production using both. (It doesn't mean it's on pypi
> > or even free software).
> > 
> > What would be the maintenance burden of those modules anyway? (at least
> > for nntp, I guess it's not gonna change).
> 
> The maintenance burden is real even if it's not visible. For example,
> test_nntplib is causing frequently issues on our CI:
> 
> https://bugs.python.org/issue19756
> https://bugs.python.org/issue19613
> https://bugs.python.org/issue31850
> 
> It's failing frequently since 2013, and nobody managed to come with a
> fix.. in 6 years.
> 
> There are 11 open issues with "nntp" in their title (8 with exactly
> "nntplib" in their title).
> 
> test_nntplib uses the public server news.trigofacile.com which is
> operated by Julien ÉLIE. Two years ago, Julien asked me if there is
> any plan to support the NNTP "COMPRESS" command.

So what I hear is, this battery is definitely not dead, which is what the 
PEP is all about.
it's just half charged (or discharged, depending on your POV), so to speak.

Substitute: "none" should read pypi then?

nd
-- 
"Solides und umfangreiches Buch"
  -- aus einer Rezension




___
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: Removing dead batteries from the standard library

Le mar. 21 mai 2019 à 13:18, André Malo  a écrit :
> There's software in production using both. (It doesn't mean it's on pypi or
> even free software).
>
> What would be the maintenance burden of those modules anyway? (at least for
> nntp, I guess it's not gonna change).

The maintenance burden is real even if it's not visible. For example,
test_nntplib is causing frequently issues on our CI:

https://bugs.python.org/issue19756
https://bugs.python.org/issue19613
https://bugs.python.org/issue31850

It's failing frequently since 2013, and nobody managed to come with a
fix.. in 6 years.

There are 11 open issues with "nntp" in their title (8 with exactly
"nntplib" in their title).

test_nntplib uses the public server news.trigofacile.com which is
operated by Julien ÉLIE. Two years ago, Julien asked me if there is
any plan to support the NNTP "COMPRESS" command.

Victor





--
Night gathers, and now my watch begins. It shall not end until my death.
___
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: Removing dead batteries from the standard library

On Montag, 20. Mai 2019 23:27:49 CEST Antoine Pitrou wrote:
> NNTP is still quite used (often through GMane, but probably not only) so
> I'd question the removal of nntplib.
> 
> cgitb used to be used by some Web frameworks in order to format
> exceptions.  Perhaps one should check if that's still the case.

I concur with both of those.
There's software in production using both. (It doesn't mean it's on pypi or 
even free software).

What would be the maintenance burden of those modules anyway? (at least for 
nntp, I guess it's not gonna change).

nd
-- 
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;

#  André Malo  #  http://pub.perlig.de  #


___
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: Removing dead batteries from the standard library

On 21/05/2019 12.19, Giampaolo Rodola' wrote:
> I find this one useful and would be a bit sad to see it go. FWIW I use it in 
> pyftpdlib and I suppose there are other apps out there relying on UNIX 
> password db for authentication. The fact that it’s a C module is also an 
> incentive to leave it in the stdlib IMO (pure python modules can easily be 
> copied in the project instead of retrieving them from PYPI as a third party 
> dep - e.g. this is how I am likely going to replace asyncore/asynchat).

If you use the spwd module for authentication, then you have a major security 
problem in your application. You must use the PAM stack to authenticate access 
to a service.

Christian
___
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: Removing dead batteries from the standard library

On Tue, 21 May 2019 at 03:17, Christian Heimes  wrote:

spwd
> 
>
> The `spwd `_ module provides
> direct access to Unix shadow password database using non-standard APIs.
> In general it's a bad idea to use the spwd. The spwd circumvents system
> security policies, it does not use the PAM stack, and is
> only compatible with local user accounts.
>
> Module type
>   C extension
> Deprecated in
>   3.8
> To be removed in
>   3.10
> Substitute
>   **none**

I find this one useful and would be a bit sad to see it go. FWIW I use it
in pyftpdlib and I suppose there are other apps out there relying on UNIX
password db for authentication. The fact that it’s a C module is also an
incentive to leave it in the stdlib IMO (pure python modules can easily be
copied in the project instead of retrieving them from PYPI as a third party
dep - e.g. this is how I am likely going to replace asyncore/asynchat).

A big +1 to this PEP by the way.
-- 
Giampaolo - http://grodola.blogspot.com
___
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: Removing dead batteries from the standard library

On 21/05/2019 11.49, Nathaniel Smith wrote:
> On Tue, May 21, 2019 at 2:40 AM Walter Dörwald  wrote:
>>
>> On 20 May 2019, at 22:15, Christian Heimes wrote:
>>
>>> Hi,
>>>
>>> here is the first version of my PEP 594 to deprecate and eventually
>>> remove modules from the standard library. The PEP started last year
>>> with talk during the Python Language Summit 2018,
>>> https://lwn.net/Articles/755229/.
>>>
>>> [...]
>>>
>>> colorsys
>>> 
>>>
>>> The `colorsys `_
>>> module
>>> defines color conversion functions between RGB, YIQ, HSL, and HSV
>>> coordinate
>>> systems. The Pillow library provides much faster conversation between
>>> color systems.
>>>
>>> Module type
>>>   pure Python
>>> Deprecated in
>>>   3.8
>>> To be removed in
>>>   3.10
>>> Substitute
>>>   `Pillow `_,
>>>   `colorspacious `_
>>
>> I'm using colorsys constantly as the basis for a tool that converts CSS
>> colors between different coordinate systems. I don't see how that could
>> be done via Pillow (which AFAICT only converts complete images).
>> RGB<->HSV<->HLS conversion seems to be not available (or not obvious) in
>> colorspacious.
> 
> Correct, colorspacious doesn't support HSV or HLS. I suppose it would
> be trivial enough to add...
> 
> The 'colour' package has them (along with everything else you can
> dream of): https://colour.readthedocs.io/en/latest/colour.models.html

Nice catch, I just added https://python-colormath.readthedocs.io/en/latest/ to 
my update PR. I'll add colour to the list, too.

(It didn't pop up on my radar because I wasn't checking for British spelling)

Christian
 


___
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: Removing dead batteries from the standard library

2019-05-21 Thread Steve Holden

It's covered in "Python in a Nutshell," Alex Martelli having been a
promoter of its ability simplify many utility programs for a long time.

Not that that's any guide as to what should be in 3.10, by which time we'll
be four minor releases out of date anyway.


On Tue, May 21, 2019 at 9:16 AM Christian Heimes 
wrote:

> On 21/05/2019 02.16, Inada Naoki wrote:
> > I use fileinput for several times per year.
> >
> > fileinput is handy tool to write single script file to analyze log files.
> >
> > * In such tools, I don't need real argument parser.
> > * Some log files are compressed and some are not.
> >   It seems argparse doesn't support transparent decompression.
> > * I don't want to use 3rd party library for such single script files.
>
> OK, let's keep it. I was under the impression that it's not used.
>
> Christian
> ___
> 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/steve%40holdenweb.com
>
___
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: Removing dead batteries from the standard library

On Tue, 21 May 2019 00:55:20 +0200
Christian Heimes  wrote:

> On 21/05/2019 00.13, Antoine Pitrou wrote:
> > On Tue, 21 May 2019 00:06:35 +0200
> > Christian Heimes  wrote:  
> >> On 20/05/2019 23.27, Antoine Pitrou wrote:  
> >>> NNTP is still quite used (often through GMane, but probably not only) so
> >>> I'd question the removal of nntplib.
> >>
> >> Is NNTP support important enough to keep the module in the standard 
> >> library?  
> > 
> > I'd phrase the question differently: is NNTP dead enough, or nntplib
> > painful enough to maintain, that it's worth removing it from the stdlib?  
> 
> The module itself does not create much work. But its tests are a regular 
> source of pain and instabilities. The tests for nntplib depend on external 
> NNTP servers. These servers are sometimes down, very slow, or don't work over 
> IPv6. I'm sure that Pablo and Victor can tell you some war stories. I briefly 
> mentioned the issues in the PEP, too.

I plead guilty for adding those tests :-/  Back then, it seemed
reasonable to test the nntplib module against real-world servers, since
like all old Internet text protocols NNTP is not always implemented
rigorously.

If the NNTP networked tests are an annoyance, they should probably be
skipped on CI.

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/archive%40mail-archive.com

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

2019-05-21 Thread Nathaniel Smith

On Tue, May 21, 2019 at 2:40 AM Walter Dörwald  wrote:
>
> On 20 May 2019, at 22:15, Christian Heimes wrote:
>
> > Hi,
> >
> > here is the first version of my PEP 594 to deprecate and eventually
> > remove modules from the standard library. The PEP started last year
> > with talk during the Python Language Summit 2018,
> > https://lwn.net/Articles/755229/.
> >
> > [...]
> >
> > colorsys
> > 
> >
> > The `colorsys `_
> > module
> > defines color conversion functions between RGB, YIQ, HSL, and HSV
> > coordinate
> > systems. The Pillow library provides much faster conversation between
> > color systems.
> >
> > Module type
> >   pure Python
> > Deprecated in
> >   3.8
> > To be removed in
> >   3.10
> > Substitute
> >   `Pillow `_,
> >   `colorspacious `_
>
> I'm using colorsys constantly as the basis for a tool that converts CSS
> colors between different coordinate systems. I don't see how that could
> be done via Pillow (which AFAICT only converts complete images).
> RGB<->HSV<->HLS conversion seems to be not available (or not obvious) in
> colorspacious.

Correct, colorspacious doesn't support HSV or HLS. I suppose it would
be trivial enough to add...

The 'colour' package has them (along with everything else you can
dream of): https://colour.readthedocs.io/en/latest/colour.models.html

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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: Removing dead batteries from the standard library

2019-05-21 Thread Walter Dörwald


On 20 May 2019, at 22:15, Christian Heimes wrote:


Hi,

here is the first version of my PEP 594 to deprecate and eventually 
remove modules from the standard library. The PEP started last year 
with talk during the Python Language Summit 2018, 
https://lwn.net/Articles/755229/.


[...]

colorsys


The `colorsys `_ 
module
defines color conversion functions between RGB, YIQ, HSL, and HSV 
coordinate

systems. The Pillow library provides much faster conversation between
color systems.

Module type
  pure Python
Deprecated in
  3.8
To be removed in
  3.10
Substitute
  `Pillow `_,
  `colorspacious `_


I'm using colorsys constantly as the basis for a tool that converts CSS 
colors between different coordinate systems. I don't see how that could 
be done via Pillow (which AFAICT only converts complete images). 
RGB<->HSV<->HLS conversion seems to be not available (or not obvious) in 
colorspacious.


colorsys is a module where we can be pretty sure that it has zero bugs, 
and doesn't require any maintenance or security updates, so I don't see 
any reason to deprecate it.



[...]


Servus,
   Walter
___
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: Removing dead batteries from the standard library