[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions

[Neil Girdhar]

> I propose (not for the first time) that similarly concatenating an 
unknown number of iterables or dicts should be possible via comprehensions:

I'm really happy to see this feature proposal come up again!  Every time, 
it seems this feature is even more intuitive to even more people, and I'm 
excited to see so many +1s compared to the -1s.  I hope it will be 
accepted, if not this time, then one day :)

It was considered and rejected in PEP 448. What was changed since? What new 
> facts or arguments have emerged?


Just for the record, both Joshua and I worked on implementing PEP 448.  We 
both wanted this feature because we felt it was consistent.  However, we 
wanted to maximize the probability that PEP 448 was accepted, so we chose 
to defer this feature.

Best,

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

[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib

[Neil Girdhar]

I like this comment.

The proposal to change list and str is way too ambitious.  But some minor 
cleanup might not be so pernicious?

On Saturday, November 13, 2021 at 5:31:49 PM UTC-5 Mike Miller wrote:

>
> I like this idea and disappointed it always gets a negative reaction. One 
> of my 
> biggest peeves is this: 
>
> import datetime # or 
> from datetime import datetime 
>
> Which is often confusing... is that the datetime module or the class 
> someone 
> chose at random in this module? A minor thorn that… just doesn't go away. 
>
>
> On 2021-11-11 07:38, Eric V. Smith wrote: 
> > The costs of migration are also too high. I personally work on a 20 year 
> old 
> > proprietary python code base that would never be updated for a change 
> like this. 
> > 
> > like: "str = 'foo'". But even if a perfect tool existed, it would take 
> > man-months and many tens of thousands of dollars to test such a large 
> code base. 
> > My clients are understandably unwilling to do that for no functional 
> gain. 
>
>
> My current work is on a ~15 year old code base. Had to do a number of 
> upgrades 
> over the years. 2.x to 3.x was the big one. Luckily there was not a lot of 
> text encoding work so porting was straightforward, and the project was 
> improved 
> for the effort. Despite the failures and grumbling there are success 
> stories as 
> well. 
>
> A lot of folks are understandably hesitant at repeating the 2 vs 3 divide. 
> But 
> I think some learned the wrong lesson from that experience. 
>
> The lesson wasn't that we shouldn't improve anything, but that we 
> shouldn't 
> change anything *fundamental.* Fundamental improvements generally can't be 
> automated, they sometimes have to be rebuilt from the ground up. I agree 
> that's 
> a no-go. 
>
> But this thread is about a rename with aliases for compatibility. 
>
> Recently we brought the same project from the ~3.5 era to 3.8 idioms using 
> the 
> tool pyupgrade. Have you tried it? Made short work of moving forward. 
> Project 
> is now more readable, using better language features. 
>
> It took a few hours from an existing maintenance budget—not tens of 
> thousands of 
> dollars. Not only that, (combined with other refactoring) the code is more 
> fun 
> to work on now. Yes, you read that right, enjoyment has increased due to 
> improved readability, appearance, and quality. 
>
> No, we couldn't afford to rewrite it from the ground up. But, running a 
> tool to 
> fix the case of a few confusing names is a small win for a small cost. I 
> would 
> like to continue the process. 
>
> +1 for stdlib, not including typing scope creep, 
> -Mike 
> ___
> Python-ideas mailing list -- python...@python.org
> To unsubscribe send an email to python-id...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python...@python.org/message/7DQAXLLLNWKRJAWBU2QPUBYH4LRSP746/
>  
> 
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7VEKSRWWODDUSRZQRP5RGKYTSBDZRYHX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib

[Mike Miller]

I like this idea and disappointed it always gets a negative reaction.  One of my 
biggest peeves is this:


import datetime # or
from datetime import datetime

Which is often confusing... is that the datetime module or the class someone 
chose at random in this module?  A minor thorn that… just doesn't go away.



On 2021-11-11 07:38, Eric V. Smith wrote:
The costs of migration are also too high. I personally work on a 20 year old 
proprietary python code base that would never be updated for a change like this. 

>
like: "str = 'foo'". But even if a perfect tool existed, it would take 
man-months and many tens of thousands of dollars to test such a large code base. 
My clients are understandably unwilling to do that for no functional gain.



My current work is on a ~15 year old code base.  Had to do a number of upgrades 
over the years.  2.x to 3.x was the big one.  Luckily there was not a lot of 
text encoding work so porting was straightforward, and the project was improved 
for the effort.  Despite the failures and grumbling there are success stories as 
well.


A lot of folks are understandably hesitant at repeating the 2 vs 3 divide.  But 
I think some learned the wrong lesson from that experience.


The lesson wasn't that we shouldn't improve anything, but that we shouldn't 
change anything *fundamental.*  Fundamental improvements generally can't be 
automated, they sometimes have to be rebuilt from the ground up.  I agree that's 
a no-go.


But this thread is about a rename with aliases for compatibility.

Recently we brought the same project from the ~3.5 era to 3.8 idioms using the 
tool pyupgrade.  Have you tried it?  Made short work of moving forward.  Project 
is now more readable, using better language features.


It took a few hours from an existing maintenance budget—not tens of thousands of 
dollars.  Not only that, (combined with other refactoring) the code is more fun 
to work on now.  Yes, you read that right, enjoyment has increased due to 
improved readability, appearance, and quality.


No, we couldn't afford to rewrite it from the ground up.  But, running a tool to 
fix the case of a few confusing names is a small win for a small cost.  I would 
like to continue the process.


+1 for stdlib, not including typing scope creep,
-Mike
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7DQAXLLLNWKRJAWBU2QPUBYH4LRSP746/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding pep-8-casing-compliant aliases for unittest and logging

[Christopher Barker]

On Sat, Nov 13, 2021 at 3:52 AM Paul Moore  wrote:

I love pytest, and I'm a happy user of it. But I've never wanted it in
> the stdlib. Because it's a developer tool, basically.


I have no problem with getting pytest from PyPi for my projects.

But there are two use cases where that’s less than ideal:

1) The Python standard library itself needs tests. Granted, I suppose the
stdlib could use a third party package for testing without shipping it in
the stdlib, but no one seems to want to do that at this point.

2) newbies and the community— why is unittest in the stdlib if it’s not the
best option??

Personally, In my intro to Python class, I do have my students install
Pytest early on and start using it well before I tell them about anything
about unittest.

There are two reasons for that:

1) I really think pytest is the better way to go.

2) I introduce unit testing and TDD really early — before classes. So being
able to write tests with simple functions is a real win.

But I’m guessing that’s not a very common approach. It really is confusing
to the community to have a not-recommended unittest framework in the
stdlib.

Granted, it’s only my opinion that it’s “not recommended”, so maybe there
is no problem to be solved, but my point is that “just keep it on PyPi” is
not really a satisfactory solution, IF unittest is not the recommend way to
write tests for Python.

Oh, point 3) I think it was Ethan that said he’d never used pytest. He’s
been very active in this community a long time! So clearly having something
in the stdlib is very influential.

Anyway — this really needs another thread if we want to continue the
discussion.

-CHB


As a developer,
> I'm perfectly fine having my tools installed in a per-project
> virtualenv, or set up as standalone commands via pipx, or whatever
> works best for my project. I don't need the full "developer
> experience" in the stdlib, because pip install works fine. And yes, I
> know that for some developers, access to PyPI isn't as easy as that
> (I've been in that position myself, many times!) but there are
> workarounds and hacks, which are fine if it's setting up stuff once on
> your dev machine.
>
> And having pytest able to change and innovate is important - if it
> became part of the stdlib, it would (of necessity) stagnate, and the
> role of innovator in testing tools would pass to someone else.
>
> **However**, the situation is completely different for packages that
> are used in applications that get shipped out to end users. And
> "applications" is a very broad term, that covers full standalone
> executables, web services, one-file scripts, Jupyter notebooks, etc.
>
> Python's story on building and deploying such applications is still
> pretty bad (and I say this as a packaging specialist!) We've focused
> on libraries at the cost of the final result, and as a consequence
> it's extremely easy to use packages from PyPI when developing your new
> application, but when you get round to deploying it, things get hard
> and you start wishing that the stuff you used was in the stdlib,
> because that would make things so much easier. So there's regular
> discussions about adding functionality to the stdlib, but it's *that*
> sort of package (requests, toml, bits of numpy, data structure
> libraries, etc), and not tools like pytest (or tox, hypothesis, nox,
> black, or flake8, ...)
>
> So basically, I don't think it's likely that a proposal to add pytest
> to the stdlib would get very far (it's fine as a PyPI package) but
> that's specific to pytest, and as a general principle, "it's on PyPI
> so it doesn't need to be in the stdlib" *doesn't* apply, and won't
> until we have a better deployment story for Python tools.
>
> Paul
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KZEZ2QHR5V6QIHD7QQM75F7I2724JTKN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JTKECRISGFDPXVPWTNYFOXJBH2VLSEEL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib

[Richard Damon]

On 11/13/21 9:59 AM, Stephen J. Turnbull wrote:

Mark Mollineaux writes:

  > I'll simply say that while I am disappointed that there are so many
  > frictions here for whatever reason,

For your personal use, you can create a module that just does

import nonPEP8module
pep8name = nonPEP8module.nonpep8name
...


Or even

import nonPEP8module
nonPEP8modue.pep8name = nonPEP8module.nonpep8name

to monkeypatch the module to have the pep8name in it.

As long as you import this module before you try it, you can then even do

from nonPEP8module import pep8nane

--
Richard Damon

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

[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib

[Stephen J. Turnbull]

Mark Mollineaux writes:

 > I'll simply say that while I am disappointed that there are so many
 > frictions here for whatever reason,

For your personal use, you can create a module that just does

import nonPEP8module
pep8name = nonPEP8module.nonpep8name
...

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

[Python-ideas] Re: Adding pep-8-casing-compliant aliases for unittest and logging

[Paul Moore]

On Sat, 13 Nov 2021 at 08:47, Stephen J. Turnbull
 wrote:
>
> A final comment: I wonder if you're being too conservative.  It's true
> that generally we prefer small targeted modules in the stdlib, but
> everybody needs tests (even if they don't know it ;-), and there might
> be quite large audiences for the great majority of PyTest.  So maybe
> we could get all of PyTest in (perhaps in a slimmed-down form without
> some of the redundant/deprecated functionality).
>
> As I mentioned, I'm not a PyTest user (yet! :-), so I wouldn't be a
> good proponent for this.  But I find the proposal exciting.

I love pytest, and I'm a happy user of it. But I've never wanted it in
the stdlib. Because it's a developer tool, basically. As a developer,
I'm perfectly fine having my tools installed in a per-project
virtualenv, or set up as standalone commands via pipx, or whatever
works best for my project. I don't need the full "developer
experience" in the stdlib, because pip install works fine. And yes, I
know that for some developers, access to PyPI isn't as easy as that
(I've been in that position myself, many times!) but there are
workarounds and hacks, which are fine if it's setting up stuff once on
your dev machine.

And having pytest able to change and innovate is important - if it
became part of the stdlib, it would (of necessity) stagnate, and the
role of innovator in testing tools would pass to someone else.

**However**, the situation is completely different for packages that
are used in applications that get shipped out to end users. And
"applications" is a very broad term, that covers full standalone
executables, web services, one-file scripts, Jupyter notebooks, etc.

Python's story on building and deploying such applications is still
pretty bad (and I say this as a packaging specialist!) We've focused
on libraries at the cost of the final result, and as a consequence
it's extremely easy to use packages from PyPI when developing your new
application, but when you get round to deploying it, things get hard
and you start wishing that the stuff you used was in the stdlib,
because that would make things so much easier. So there's regular
discussions about adding functionality to the stdlib, but it's *that*
sort of package (requests, toml, bits of numpy, data structure
libraries, etc), and not tools like pytest (or tox, hypothesis, nox,
black, or flake8, ...)

So basically, I don't think it's likely that a proposal to add pytest
to the stdlib would get very far (it's fine as a PyPI package) but
that's specific to pytest, and as a general principle, "it's on PyPI
so it doesn't need to be in the stdlib" *doesn't* apply, and won't
until we have a better deployment story for Python tools.

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

[Python-ideas] Re: Adding pep-8-casing-compliant aliases for unittest and logging

[Stephen J. Turnbull]

Jonathan Crall writes:

 > But perhaps a subset of it (pytest lite?) might be isolated and
 > considered for inclusion down the line?

*Anything* might be considered for inclusion, although Guido might
dispose of it with a simple "please, no".  That is not going to happen
to your suggestion! :-)  But somebody's got to do the work of
identifying the subset, and coordinating with PyTest on whether they
would use the subset in their more extended framework, and (one hopes)
volunteer to maintain the module in the stdlib.

There's also the issue of how mature PyTest is.  If it's still gaining
features at some pace, it probably doesn't want to be part of the
stdlib yet.

A final comment: I wonder if you're being too conservative.  It's true
that generally we prefer small targeted modules in the stdlib, but
everybody needs tests (even if they don't know it ;-), and there might
be quite large audiences for the great majority of PyTest.  So maybe
we could get all of PyTest in (perhaps in a slimmed-down form without
some of the redundant/deprecated functionality).

As I mentioned, I'm not a PyTest user (yet! :-), so I wouldn't be a
good proponent for this.  But I find the proposal exciting.

Steve

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