Re: [Python-Dev] Is it useful to update cgitb module?

[Alex Walters]

Are there people still actively developing new cgi scripts in python?  I know 
some modern HTTPDs don’t even support classic cgi without some kind of fastcgi 
daemon in between.  I am aware that some parts of various wsgi tools use the 
cgi module, but is the cgitb module useful for them?

Your suggestions might be good ideas, but I don’t know if they would be used.  
I feel like its kind of like updating the macpath module - sure you can make 
code improvements to it if you want, but its for a workflow that is very rarely 
used.

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Stéphane Blondon
> Sent: Saturday, April 7, 2018 4:21 PM
> To: python-dev@python.org
> Subject: [Python-Dev] Is it useful to update cgitb module?
> 
> Hello,
> 
> I wonder if it's useful to update the cgitb module, in particular the
> html output.
> I see some possible improvements:
> 
> 1. In both text and html versions:
> 
> When a module is called, there are no parameters (displayed as '()'). I
> think they are unnecessary. Perhaps the parentheses should be removed?
> Perhaps it's better to keep them for backward compatibility?
> 
> ### example for the text version ###
> $ python3 demo.py
> [...]
>  /home/stephane/src/cgitest/demo.py in ()
> 7 def func1(a, b):
> [...]
> ### end of example ###
> 
> 2. In html version only:
>  a. If the executed code is in : in this case, it is not shown
> in the html version because the square brackets are interpreted as a
> html tag (see the picture in attachement).
>  b. Update the style of the html or/and using html5. It would be
> prettier but it will be a big change for probably too few benefits.
> 
> What do you think about them? I can report bugs and send pull-requests
> for them but I would prefer to get feedbacks before.
> 
> Regards,
> Stéphane

___
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] Are undocumented functions part of the stable ABI?

[Nick Coghlan]

On 6 April 2018 at 14:45, Guido van Rossum  wrote:
> As you may guess from the silence, it may be hard to get a definitive answer
> to this question -- PEP 384's author has stopped actively participating in
> the Python community and I'm not sure if any core developers currently
> consider themselves to be the "guardians of the ABI".

It's only been a few days, and there are definitely some of us that
genuinely want the stable ABI to meet its guarantees (e.g. me, Steve
Dower, Eric Snow, Victor Stinner). It just isn't likely to come fully
into its own until more library developers are able to drop support
for Python 2.7.

> That said, from a quick skim of PEP 384 it seems to be quite strict in its
> position that anything not explicitly included by the PEP should be
> considered not part of the ABI, which makes me think that only a few
> PyCFunction related items are considered part of the ABI (searching for
> PyCFunction only finds three hits). OTOH it states that if Py_LIMITED_API is
> defined, all definitions that are not part of the ABI will be hidden. So
> from that (plus the source code) you should be able to tell which
> PyCFunction_* functions are part of the ABI -- again it does not appear the
> documentation status of a function matters for this rule.
>
> On the third hand, PEP 384 references a file "python3.def"
> (https://www.python.org/dev/peps/pep-0384/#id5) and that file contains
> several PyCFunction_* names. Maybe this is the hard rule you're looking for?
> Again, being documented is not a requirement.
>
> Another observation would be that (AFAICT) PEP 384 strictly forbids
> signature changes, but is mostly silent on semantics.

Right, PEP 384 is mainly focused on low level ABI compatibility:
whether or not the extension module loader will even be able to import
the module without getting segfaults due signature mismatches or
struct size changes.

Semantic questions are a bit different, as the question there isn't
"Will the module segfault?" it's "Will it work as expected?", and that
question applies regardless of whether you recompile it or not.

> On Wed, Apr 4, 2018 at 10:34 PM, Jeroen Demeyer  wrote:
>> The context is PEP 575. I guess my question is mostly about
>> PyCFunction_Check(). I will not be able to keep it 100% backwards compatible
>> simply because the goal of that PEP is precisely changing the classes of
>> some objects.
>>
>> Now the question is: am I allowed to change the implementation of
>> PyCFunction_Check()? If it's considered part of the stable ABI, then the
>> answer is immediately "no".

Changing macro definitions doesn't break the stable ABI, as long as
the *old* macro expansions still do the right thing.

So in the case of PEP 575, the following change would be OK (since the
old macro expansion would still work):

* add PyCFunction_CheckExact() to replace the current meaning of
PyCFunction_Check
* adjust PyCFunction_Check() to allow subclasses

In a lot of ways, you're actually better off than if these were
functions, as extension modules built against the stable ABI with an
old version won't even see the semantic change - they'll implicitly
keep PyCFunction_CheckExact semantics.

>> By the way, does anybody happen to know why the PyCFunction_* functions
>> are undocumented? Is it just an oversight in the docs or is it intentional?

Just an oversight as far as I am aware.

>> But regardless of the context, I think that the question "Are undocumented
>> functions part of the stable ABI?" should be answered in PEP 384.

We'd put any answer to that question in
https://docs.python.org/3/c-api/stable.html, rather than in PEP 384
(although it may make sense to link from the PEP back to the docs for
usage questions, for the benefit of folks that find the PEP first).

There isn't really a universal answer, though - the closest we get to
that is the fact that we default to "No, they're not part of the
stable ABI" when they have an underscore prefix (and hence aren't even
part of the public API), and "Yes, they are covered by the stable ABI"
otherwise (it may be a bug that they escaped into the stable ABI in
the first place, but once they're there, they're there).

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] Soliciting comments on the future of the cmd module (bpo-33233)

[Nathaniel Smith]

On Sat, Apr 7, 2018 at 6:54 AM, Matěj Cepl  wrote:
> Also, considering requests, I am still dreaming about somebody
> writing some requests-like API over the standard library.

What would be the difference between that and... requests? Requests
still uses http.client under the hood...

-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] Soliciting comments on the future of the cmd module (bpo-33233)

[Steven D'Aprano]

On Sat, Apr 07, 2018 at 02:50:00PM -0400, Chris Barker - NOAA Federal wrote:

> Is bringing cmd2 into the standard library an option to be considered?

That is discussed on the tracker. The short answer is, yes, it is 
considered, but no, cmd2 is not ready to come into the std lib. I 
recommend you check out the discussion here:

https://bugs.python.org/issue33233


-- 
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] Trying to build from source, test-poplib fails

[Skip Montanaro]

> Do you have ca-certificates installed?

It seems so:

% apt search ca-certificates | grep installed

ca-certificates/artful,artful,now 20170717 all [installed]
ca-certificates-mono/artful,artful,now 4.6.2.7+dfsg-1ubuntu1 all
[installed,automatic]
liblwp-protocol-https-perl/artful,artful,now 6.07-2 all [installed]

S
___
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] Trying to build from source, test-poplib fails

[Ryan Gonzalez]

Do you have ca-certificates installed?

On April 7, 2018 5:33:35 PM Skip Montanaro  wrote:


It's been a long while since I rebuilt Python from the Git source. I
tried for the first time the other day. Everything passed except
test_poplib and test_asyncio. The former just runs and runs and runs.
Here's the first traceback I encounter when executing ./python
Lib/test/test_poplib.py:

test_stls_context (__main__.TestPOP3Class) ... Exception in thread Thread-16:
Traceback (most recent call last):
 File "/home/skip/src/python/cpython/Lib/threading.py", line 917, in
_bootstrap_inner
   self.run()
 File "Lib/test/test_poplib.py", line 227, in run
   asyncore.loop(timeout=0.1, count=1)
 File "/home/skip/src/python/cpython/Lib/asyncore.py", line 207, in loop
   poll_fun(timeout, map)
 File "/home/skip/src/python/cpython/Lib/asyncore.py", line 150, in poll
   read(obj)
 File "/home/skip/src/python/cpython/Lib/asyncore.py", line 87, in read
   obj.handle_error()
 File "/home/skip/src/python/cpython/Lib/asyncore.py", line 83, in read
   obj.handle_read_event()
 File "/home/skip/src/python/cpython/Lib/asyncore.py", line 422, in
handle_read_event
   self.handle_read()
 File "Lib/test/test_poplib.py", line 194, in handle_read
   self._do_tls_handshake()
 File "Lib/test/test_poplib.py", line 174, in _do_tls_handshake
   self.socket.do_handshake()
 File "/home/skip/src/python/cpython/Lib/ssl.py", line 1108, in do_handshake
   self._sslobj.do_handshake()
ssl.SSLError: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert
certificate unknown (_ssl.c:1049)

I thought perhaps I was missing something, but _ssl built just fine. I
believe I have a recent enough version of libssl (1.0.2g), and I'm on
a pretty vanilla system (up-to-date Ubuntu 17.10). SSL-wise:

% apt search ssl | grep installed | egrep '^lib' | egrep ssl

libgnutls-openssl27/artful,now 3.5.8-6ubuntu3 amd64 [installed]
libio-socket-ssl-perl/artful,artful,now 2.050-1 all [installed]
libnet-smtp-ssl-perl/artful,artful,now 1.04-1 all [installed]
libnet-ssleay-perl/artful,now 1.80-1build1 amd64 [installed]
libssl-dev/artful-updates,artful-security,now 1.0.2g-1ubuntu13.4 amd64
[installed]
libssl-doc/artful-updates,artful-updates,artful-security,artful-security,now
1.0.2g-1ubuntu13.4 all [installed,automatic]
libssl1.0.0/artful-updates,artful-security,now 1.0.2g-1ubuntu13.4
amd64 [installed]

Any clues about what I might be missing from my setup would be appreciated.

Not sure what was wrong with test_asyncio. I ran it in isolation and it passed.

Thx,

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/rymg19%40gmail.com


--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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

[Python-Dev] Trying to build from source, test-poplib fails

[Skip Montanaro]

It's been a long while since I rebuilt Python from the Git source. I
tried for the first time the other day. Everything passed except
test_poplib and test_asyncio. The former just runs and runs and runs.
Here's the first traceback I encounter when executing ./python
Lib/test/test_poplib.py:

test_stls_context (__main__.TestPOP3Class) ... Exception in thread Thread-16:
Traceback (most recent call last):
  File "/home/skip/src/python/cpython/Lib/threading.py", line 917, in
_bootstrap_inner
self.run()
  File "Lib/test/test_poplib.py", line 227, in run
asyncore.loop(timeout=0.1, count=1)
  File "/home/skip/src/python/cpython/Lib/asyncore.py", line 207, in loop
poll_fun(timeout, map)
  File "/home/skip/src/python/cpython/Lib/asyncore.py", line 150, in poll
read(obj)
  File "/home/skip/src/python/cpython/Lib/asyncore.py", line 87, in read
obj.handle_error()
  File "/home/skip/src/python/cpython/Lib/asyncore.py", line 83, in read
obj.handle_read_event()
  File "/home/skip/src/python/cpython/Lib/asyncore.py", line 422, in
handle_read_event
self.handle_read()
  File "Lib/test/test_poplib.py", line 194, in handle_read
self._do_tls_handshake()
  File "Lib/test/test_poplib.py", line 174, in _do_tls_handshake
self.socket.do_handshake()
  File "/home/skip/src/python/cpython/Lib/ssl.py", line 1108, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: SSLV3_ALERT_CERTIFICATE_UNKNOWN] sslv3 alert
certificate unknown (_ssl.c:1049)

I thought perhaps I was missing something, but _ssl built just fine. I
believe I have a recent enough version of libssl (1.0.2g), and I'm on
a pretty vanilla system (up-to-date Ubuntu 17.10). SSL-wise:

% apt search ssl | grep installed | egrep '^lib' | egrep ssl

libgnutls-openssl27/artful,now 3.5.8-6ubuntu3 amd64 [installed]
libio-socket-ssl-perl/artful,artful,now 2.050-1 all [installed]
libnet-smtp-ssl-perl/artful,artful,now 1.04-1 all [installed]
libnet-ssleay-perl/artful,now 1.80-1build1 amd64 [installed]
libssl-dev/artful-updates,artful-security,now 1.0.2g-1ubuntu13.4 amd64
[installed]
libssl-doc/artful-updates,artful-updates,artful-security,artful-security,now
1.0.2g-1ubuntu13.4 all [installed,automatic]
libssl1.0.0/artful-updates,artful-security,now 1.0.2g-1ubuntu13.4
amd64 [installed]

Any clues about what I might be missing from my setup would be appreciated.

Not sure what was wrong with test_asyncio. I ran it in isolation and it passed.

Thx,

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

[Python-Dev] Is it useful to update cgitb module?

[Stéphane Blondon]

Hello,

I wonder if it's useful to update the cgitb module, in particular the
html output.
I see some possible improvements:

1. In both text and html versions:

When a module is called, there are no parameters (displayed as '()'). I
think they are unnecessary. Perhaps the parentheses should be removed?
Perhaps it's better to keep them for backward compatibility?

### example for the text version ###
$ python3 demo.py
[...]
 /home/stephane/src/cgitest/demo.py in ()
7 def func1(a, b):
[...]
### end of example ###

2. In html version only:
 a. If the executed code is in : in this case, it is not shown
in the html version because the square brackets are interpreted as a
html tag (see the picture in attachement).
 b. Update the style of the html or/and using html5. It would be
prettier but it will be a big change for probably too few benefits.

What do you think about them? I can report bugs and send pull-requests
for them but I would prefer to get feedbacks before.

Regards,
Stéphane


signature.asc
Description: OpenPGP digital signature
___
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] Soliciting comments on the future of the cmd module (bpo-33233)

[Brett Cannon]

On Sat, 7 Apr 2018 at 11:50 Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> Is bringing cmd2 into the standard library an option to be considered?
>

Anything can be considered. ;)


>
> That water get included batteries and a more featurefull and supported lib.
>
> It seems (on python-ideas) that people are often told, when they have
> a suggestion for the stdlib, that they put it on pypi and see if it
> gains usage, etc, and it it proves useful and popular, maybe then it
> could be brought in. That seems to be the case here.
>
> I understand that it only makes sense if the cmd2 developers want to
> support it and are willing to accept the responsibilities and
> restrictions that come with being in the core, but it’s worth asking.
>

First I think we need to ask ourselves whether we would even want a module
like cmd in the stdlib today. It's 26 years old, so it was added back when
Guido has admitted the bar for entry was much lower. If we wouldn't add the
module today, then there's no need to bring in a replacement.

Plus we have instances in the stdlib where we brought it in with the
maintainer becoming a core dev, and then they step away and no one picks
the module up going forward. So I would argue that even if we thought we
would add the cmd module today that we shouldn't bring it in unless we have
at least 2 people in total willing to list themselves in the experts index
for that module (preferably 3 people so we're never down to just one person
when someone takes a break).
___
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] Soliciting comments on the future of the cmd module (bpo-33233)

[Ned Deily]

Thanks for everyone's interest but, please, let's keep the discussion in one 
place as originally requested:

> If you have an opinion about either recommending cmd2 in the cmd docs and/or
> deprecating cmd in 3.8, please comment on https://bugs.python.org/issue33233.

You'll find some answers to some of these questions there already.

--
  Ned Deily
  n...@python.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] Soliciting comments on the future of the cmdmodule (bpo-33233)

[Brett Cannon]

On Sat, 7 Apr 2018 at 02:09 Steven D'Aprano  wrote:

> On Sat, Apr 07, 2018 at 09:30:05AM +0100, Paul Moore wrote:
> > On 7 April 2018 at 04:13, Steve Dower  wrote:
> > > Better to deprecate it before it becomes broken, in my opinion.
>
> That argument could be applied to everything in the std lib.
>

Sure, but we all know none of this is as black-and-white as it's being
portrayed either.


>
>
> > > Having someone willing and able to review and merge changes is the best
> > > criteria for whether a module is still supported or not.
>
> I don't think "best" is justified -- and certainly it is not the *only*
> criteria.
>

But you have to admit it is an important one.


>
> Modules can become stable simply because they have no known bugs and no
> new feature requests. Stable doesn't mean useless, and the urge to
> consider anything that isn't being regularly fiddled with as "obsolete"
> is a tendency to be resisted.
>
> If the module isn't broken, there's no need to fix it. That's a GOOD
> thing, not a reason to dump a perfectly good, useful, working module.
>

I think part of the question is whether the module is also used enough to
justify putting in scarce core dev time to maintain it.


>
> Raymond has stated that he is happy to work on it if there are any bugs
> reported on it, and if he's not available, I'm sure somebody will.


Actually Raymond said he *teaches* the module, not that he wanted to
maintain it. And I definitely would not assume that someone will pick up to
help maintain any module in the stdlib.


> And
> if not, well, we don't have any sort of performance guarantees on fixes:
> sooner or later, *somebody* will provide a patch.


Assuming someone does, do we really want to say, "eh, it's buggy but we can
wait over 7 years for a fix" (the oldest open issue on b.p.o is from August
2009: https://bugs.python.org/issue6686). And even if they do, that doesn't
mean someone will have the time or inclination to review it and eventually
see it through to being merged.


> That's the beauty of
> the Open Source model. There are plenty of potential upstream
> contributors who could contribute a patch.
>

But potential does not necessarily translate to action.


>
>
> > I think there's a difference between not being willing to add
> > enhancements, and not fixing bugs. The issue that originally triggered
> > this discussion was an enhancement request, and I don't think it's
> > unreasonable to declare cmd as "stable - no further enhancements will
> > be made or accepted" while still considering it as supported for
> > bugfixes.
>
> Its not an unreasonable position to take, but I don't think it is
> justified in this case. The cmd module is not something so arcane or
> complicated that it requires a specialist to maintain it. Its about 400
> lines, including blank lines and doc strings, with a single class and
> around twenty methods.
>
> Wasn't one of the major reasons for moving to git and Github to
> make it easier for non-core devs to contribute?


Actually the major reason was to make it easier for core devs to review
contributions. Easing the workflow for outside contributors was a side
benefit.


> A module as stable and
> simple as cmd seems to me to be the ideal place for people to begin
> contributing, whether it is fixing bugs or contributing any
> (hypothetical) feature enhancements.
>

Perhaps, but that assumes someone wants that job. ;)


>
> I don't think we need do anything here: so long as there is a core
> developer willing to review any PRs, and so long as new enhancements go
> through the same approval process on the bug tracker and/or Python-
> Ideas, I don't think we need to single cmd out as deprecated or "no new
> features".
>

Those two "so long as" parts are I think the key reason Ned brought this up.


>
> This isn't gopher, or something with serious unfixable security
> vulnerabilities. It works. What more needs to be said?
>

I think this all ties back to the usual discussion we have when it comes to
the stdlib: what  is the bar for what should be in there because nothing is
maintenance-free?

The cmd module itself has plenty of commits that were just standard code
maintenance changes:
https://github.com/python/cpython/commits/master/Lib/cmd.py . All of that
eats up time over the 26 years of the module's existence. And feature
enhancements are not free either even if you don't review the PR because
even if you don't review them you still have to peruse the PR title to make
the decision not to review it, which once again is a small amount of time
in isolation but adds up at a macro level.

We all have a limited amount of time to contribute, especially when we are
almost all spending personal time on this project. And no matter how
trivial a module is to keep around, it is not a non-zero amount of time for
the group all-up, even if we all collectively choose to ignore it in hopes
someone comes forward to help out.

And I would 

Re: [Python-Dev] Soliciting comments on the future of the cmd module (bpo-33233)

[Chris Barker - NOAA Federal]

Is bringing cmd2 into the standard library an option to be considered?

That water get included batteries and a more featurefull and supported lib.

It seems (on python-ideas) that people are often told, when they have
a suggestion for the stdlib, that they put it on pypi and see if it
gains usage, etc, and it it proves useful and popular, maybe then it
could be brought in. That seems to be the case here.

I understand that it only makes sense if the cmd2 developers want to
support it and are willing to accept the responsibilities and
restrictions that come with being in the core, but it’s worth asking.

-CHB
___
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] Error embedding python

[Brett Cannon]

Most likely your 'args' module is calling import with a bytes object and
not a string and that it's getting that far into the process before you hit
code that only works with strings (_os.listdir() returns bytes if you pass
a bytes argument to it).

At this point I would take the question to python-list or python-tutor to
get more help with embedding.

On Fri, 6 Apr 2018 at 10:29 Chris Bryan  wrote:

> Hello list,
>
> I am embedding a python 3.6 environment in another executable, which is
> compiling and executing ok. However I get an error on Windows when I try
> to import any module except sys:
>
> Traceback (most recent call last):
>File "args", line 1, in 
>File "", line 971, in _find_and_load
>File "", line 951, in
> _find_and_load_unlocked
>File "", line 894, in _find_spec
>File "", line 1157, in find_spec
>File "", line 1129, in _get_spec
>File "", line 1245, in find_spec
>File "", line 1302, in _fill_cache
> TypeError: a bytes-like object is required, not 'str'
>
> Looking on line 1302, it would appear that the call to _os.listdir()
> (line 1285) is returning a list of byte objects. I can confirm that I
> get the same error doing the following from a normal python interactive
> session:
>
>  >>> x = b'a.b.c'
>  >>> x.partition('.')
> Traceback (most recent call last):
>File "", line 1, in 
> TypeError: a bytes-like object is required, not 'str'
>
> Is this a bug in the bootstrap module, or am I doing something wrong
> which is causing listdir() to return bytes?
>
> Chris
>
> ___
> 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] Soliciting comments on the future of the cmd module (bpo-33233)

[Matěj Cepl]

On 2018-04-07, 00:13 GMT, Steven D'Aprano wrote:
> Just in the last week, I've been reminded twice that many 
> people using Python do so where they cannot just arbitarily 
> pip install , and if a library isn't in the std lib, 
> they can't use it without a lot of pain:

100% agree + one of the great advantages of Python is that the 
batteries actually are included and we are not forcing users to 
download one of twenty competing unstable versions somewhere on 
GitHub (I won't name any competing languages here).

Also, I don't see a problem with having one more mature, slower 
version of library in the standard library, while the more alive 
version is still being developed from time to time rebasing the 
stdlib version (I thought, unittest was one such example.)

Also, considering requests, I am still dreaming about somebody 
writing some requests-like API over the standard library.

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
My opinions may have changed, but not the fact that I am right.
--Ashleigh Brilliant

___
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] Soliciting comments on the future of the cmdmodule (bpo-33233)

[Steven D'Aprano]

On Sat, Apr 07, 2018 at 09:30:05AM +0100, Paul Moore wrote:
> On 7 April 2018 at 04:13, Steve Dower  wrote:
> > Better to deprecate it before it becomes broken, in my opinion.

That argument could be applied to everything in the std lib.


> > Having someone willing and able to review and merge changes is the best
> > criteria for whether a module is still supported or not.

I don't think "best" is justified -- and certainly it is not the *only* 
criteria.

Modules can become stable simply because they have no known bugs and no 
new feature requests. Stable doesn't mean useless, and the urge to 
consider anything that isn't being regularly fiddled with as "obsolete" 
is a tendency to be resisted.

If the module isn't broken, there's no need to fix it. That's a GOOD 
thing, not a reason to dump a perfectly good, useful, working module.

Raymond has stated that he is happy to work on it if there are any bugs 
reported on it, and if he's not available, I'm sure somebody will. And 
if not, well, we don't have any sort of performance guarantees on fixes: 
sooner or later, *somebody* will provide a patch. That's the beauty of 
the Open Source model. There are plenty of potential upstream 
contributors who could contribute a patch.


> I think there's a difference between not being willing to add
> enhancements, and not fixing bugs. The issue that originally triggered
> this discussion was an enhancement request, and I don't think it's
> unreasonable to declare cmd as "stable - no further enhancements will
> be made or accepted" while still considering it as supported for
> bugfixes.

Its not an unreasonable position to take, but I don't think it is 
justified in this case. The cmd module is not something so arcane or 
complicated that it requires a specialist to maintain it. Its about 400 
lines, including blank lines and doc strings, with a single class and 
around twenty methods.

Wasn't one of the major reasons for moving to git and Github to 
make it easier for non-core devs to contribute? A module as stable and 
simple as cmd seems to me to be the ideal place for people to begin 
contributing, whether it is fixing bugs or contributing any 
(hypothetical) feature enhancements.

I don't think we need do anything here: so long as there is a core 
developer willing to review any PRs, and so long as new enhancements go 
through the same approval process on the bug tracker and/or Python- 
Ideas, I don't think we need to single cmd out as deprecated or "no new 
features".

This isn't gopher, or something with serious unfixable security 
vulnerabilities. It works. What more needs to be said?



-- 
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] Soliciting comments on the future of the cmdmodule (bpo-33233)

[Paul Moore]

On 7 April 2018 at 04:13, Steve Dower  wrote:
> Better to deprecate it before it becomes broken, in my opinion.
>
> Having someone willing and able to review and merge changes is the best
> criteria for whether a module is still supported or not.

I think there's a difference between not being willing to add
enhancements, and not fixing bugs. The issue that originally triggered
this discussion was an enhancement request, and I don't think it's
unreasonable to declare cmd as "stable - no further enhancements will
be made or accepted" while still considering it as supported for
bugfixes. If significant bugs in cmd are remaining unfixed, then
that's a somewhat different matter.

The fact that pdb uses it, and the advantage of having something in
the stdlib for users without easy access to "pip install", *plus* the
general principle of "if it isn't broken, don't fix it" make me feel
that the best solution would be to document that extended replacements
such as cmd2 exist in PyPI, but retain cmd as supported but not (in
principle) accepting further enhancements (leaving the door open for
interested core devs to merge enhancements on a case by case basis if
they have a personal interest in doing so).

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