[Python-Dev] Re: The current state of typing PEPs

[Mike Miller]

On 2021-11-30 09:01, Steven D'Aprano wrote:


Heh. We could update PEP 8 to ban type annotations, then watch as the
people who over-zealously apply PEP 8 to everything AND over-zealously
insist on adding type annotations to everything have their heads
explode.



Captain Kirk would be proud:

https://memory-alpha.fandom.com/wiki/Induced_self-destruction

-Mike


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

[Python-Dev] Re: Do we need to remove everything that's deprecated?

[Mike Miller]

This is the point where the pricey support contract comes in.  Would give 
options to those who need it and provide some revenue.


Otherwise, the "there's no such thing as a free lunch," factor takes precedence.

-Mike

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

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Mike Miller]

How about moving Python 2 notes into a section at the bottom?


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

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Mike Miller]

On 2021-05-11 16:12, Guido van Rossum wrote:
On Tue, May 11, 2021 at 4:07 PM Gregory P. Smith There's a difference between tracebacks dumped as plain text (utf-8) by

traceback.print_exc() appearing on stderr or directed into log files and
what can be displayed within a terminal.  It is highly unusual to emit
terminal control characters into log files.


And yet it happens all the time. :-( Let's not risk that happening.



os.isatty() is helpful in that situation, no?

-Mike

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

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Mike Miller]

On 5/11/21 1:57 AM, Baptiste Carvello wrote:

Le 11/05/2021 à 09:35, Steven D'Aprano a écrit :

On Mon, May 10, 2021 at 09:44:05PM -0400, Terry Reedy wrote:


The vanilla interpreter could be updated to recognize when it is running
on a similated 35-year-old terminal that implements ansi-vt100 color
codes rather than a similated 40+-year-old black-and-white teletype-like
terminal.


This is what is called "scope creep", although in this case
perhaps "scope gallop" is more appropriate *wink*
[...]


Also: people paste tracebacks into issue reports, so all information has
to survive copy-pasting.



The first ANSI standard supported underlined text, didn't it?  The VT100 did. 
That would make it part of the 40+ year old subset from the late 70's.


While color might stand out more, underline suits the problem well, also without 
increasing the line count.


There are a number of terminal emulators that support rich text copies, but not 
all of them.  This is added information however, so it not being copy-pastable 
everywhere shouldn't be a blocking requirement imho.


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

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

[Mike Miller]

On 2021-03-10 13:45, David Mertz wrote:
In contrast, the "master" used in version control directly borrows from 
so-called "master/slave network architecture."



It was shown upthread that this isn't the case.  Do you have more accurate 
documentation to refute the claim?


- https://twitter.com/xpasky/status/1272280760280637441
- https://en.wikipedia.org/wiki/Mastering_(audio)

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

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Mike Miller]

On 2021-02-24 21:08, Peter Wang wrote:
With binary extension modules, version conflicts lead to (at best) runtime 
segfault and (at worst) subtle *data* bugs that return incorrect results.  There 
are also deeper concerns around security and reproducibility.


If your app has requirements, by all means use an isolated environment.  Wasn't 
recommending against it, when needed.


Rather, that it is not a requirement for *every single script,* or even most. 
As we've seen some folks have been scared into a heavy-handed solution.




Perhaps it has to do with
the decline of sys-admin skills over the years?

Many millions of users of new Python users show up every year, using the 
language and its powerful ecosystem for data analytics and scientific computing, 
and they have no hope of having sys-admin skills.



"sys-admin" is a bit of an overstatement in my phrasing.  The core is that you 
need to understand how a PATH works and be able to run pip and cd into folders 
and perhaps run rm/del, etc.  Basic command-line skills?


In any case, if you can't do these, virtual envs are not a full solution either.

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

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Mike Miller]

On 2021-02-24 02:52, Stéfane Fermigier wrote:
I have currently 57 apps installed via pipx on my laptop, and the 57 
environments take almost 1 GB already.



I never understood the fear around version conflicts.  Perhaps it has to do with 
the decline of sys-admin skills over the years?  So, the strategy above feels 
like swatting a fly with a sledgehammer to me.  Same as with a venv for every 
app. :-)


Rather than installing every package this way, why not wait until a conflict 
actually occurs?


Personally, I rarely have such conflicts, maybe every few years or so.  When it 
happens, I fix them by uninstalling the offender and putting the more difficult 
one into the venv or pipx.  Right now I only have one, a giant app from work 
that uses pipenv, and it's fine.



Now what about sudo and all that?  Well, I used it in the old days because 
that's what the instructions said.  But, to be honest, it never made any sense. 
I haven't shared a computer in decades, and when we did we used NFS for common 
tools, so it never saved any disk space.


Pip (and easy_install?) dragged their feet for years to properly support user 
installs (should have been default) but once they did I didn't look back.  I 
dump almost all packages to user, which gets cleaned up every other year when 
the distro moves to the next version.  The strategy has been working well for a 
long time.


So, --user works at the low end, and containers for the high end.  Honestly, I 
don't have much of a use case any longer for venvs.


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

[Python-Dev] Re: Security releases of CPython

[Mike Miller]

On Thu, 2021-02-11 at 23:24 -0500, Terry Reedy wrote:
> ... Releases are not just a push of a button.

On 2021-02-19 15:05, Stestagg wrote:
>  > The thing that stood out from this conversation, for me, is: Releases
>  > are too hard, and there’s a risk of not having enough volunteers as a
>  > result.
>  >
>  > How hard is it to fix that?
>
> Are there no technical solutions that might help reduce the cost?


Sounds like automating until it is "just a push of a button," should be a goal. 
According to Victor there has been progress, but always room for more.



On 2021-02-19 18:36, Brett Cannon wrote:
There is no specific drive to hire someone to target security and/or release 
management at the moment. We just got enough funding for the first time to hire 
a dev-in-residence for Python itself to try to help tackle our 1.4K PR backlog 
in some fashion that they won't be dedicated to security or release management.



Looking at the PSF Annual report from a normal year it also looks like there is 
substantial revenue, income, and assets available.  There are significant 
expenses as well.


(And of course income down for ~two years, but it should return at some point.)

I would argue that security releases are of higher importance than most, 
including sponsorship programs and grants, and that a mild change of priorities 
is in order.  This is not to say (of course) that any other categories are not 
important, simply that having machines and networks pwned while being sponsored 
or educated is a devil's bargain.


Such a position may not require a hundred-thousand a year salary either.  A 
skilled contractor could improve automation, while a stipend might be enough to 
ensure releases get out within a ~week if they need to.


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

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Mike Miller]

On 2020-11-09 10:44, Simon Cross wrote:

That's quite subjective. Personally I prefer a more complete tutorial
which explains many details so that I don't immediately run into
fundamentals I don't understand when I start using what I've learned.
K was very popular, so I don't think I'm alone in this.



Indeed.  A common problem with a lot of platform documentation I've experienced 
is that tutorials are "fluff" for absolute beginners, complemented with terse, 
dense reference material for experts.  There is too often very little in-between 
to get you to the intermediate level.


That's why the current tutorial is fantastic, imho.  It doesn't skip the 
all-important middle part of the journey, and gets you to near-intermediate 
within a few hours if you've programed before.


Perhaps the first step is too high, however.  How about a new Section 0: 
Absolute beginners guide, for those new to programming?


-Mike

P.S.  I didn't see an obvious link to the tutorial from the home page, it is 
sorta buried under getting-started.  Perhaps it could be better highlighted.

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

[Python-Dev] Re: Improvement to SimpleNamespace

[Mike Miller]

On 2020-04-16 04:33, Rob Cliffe via Python-Dev wrote:
Here's another revolutionary thought:  add a new operator and associated dunder 
method (to object?)
whose meaning is *undefined*.  Its default implementation would do *nothing* 
useful (raise an error? return None?).

E.g. suppose the operator were `..`
Then in a specific class you could implement x..y to mean x['y']
and then you could write
     obj..abc..def..ghi
Still fairly concise, but warns that what is happening is not normal attribute 
lookup.


Interesting, I've thought the same thing.  Double dot might be a good option.

In practice however I've not encountered key names in JSON that conflict with 
the dictionary methods.  A missing protocol could handle clashes when they 
happen, as applied to keys.  Keys that conflict are simply shadowed by the 
method names unless you use [''] notation.


I know, that answer is not satisfying to the purist.  Double dot is better in 
that regard.  Yet haven't found it to be a concrete problem.


Perhaps linters could find code using uncalled dict method names as a 
mitigation.  Suppose it boils down to a judgement call in the end.


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

[Python-Dev] Python2 as 푣 → 푒

[Mike Miller]

Unless I've read something wrong, it looks like the final Python 2 release 
(2.7.18) should approximate the math constant e:


>>> import math
>>> math.e
2.718281828459045

Aka:

Python as 푣 → 푒
Python ≈ 푒

Would be fun to note that in the announcement/docs somehow.

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

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

[Mike Miller]

On 2020-03-21 20:38, Guido van Rossum wrote:
It's not great, and I actually think that "stripprefix" and "stripsuffix" are 
reasonable. (I found that in Go, everything we call "strip" is called "Trim", 
and there are "TrimPrefix" and "TrimSuffix" functions that correspond to the PEP 
616 functions.)


To jump on the bikeshed, trimprefix and trimsuffix are the best I've read so 
far, due to the definitions of the words in English.


Though often used interchangeably, when I think of "strip" I think of removing 
multiple things, somewhat indiscriminately with an arm motion, which is how the 
functions currently work.  e.g. "strip paint", "strip clothes":


https://www.dictionary.com/browse/strip
to take away or remove

When I think of trim, I think more of a single cut of higher precision with 
scissors.  e.g. "trim hair", "trim branches":


https://www.dictionary.com/browse/trim
to put into a neat or orderly condition by clipping…


Which is what this method would do.  That trim matches Go is a small but decent 
benefit.  Another person warned against inconsistency with PHP, but don't think 
PHP should be considered for design guidance, IMHO.  Perhaps as an example of 
what not to do, which happily is in agreement with the above.


-Mike

p.s.  +1, I do support this PEP, with or without name change, since some 
mentioned concern over that.

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

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Mike Miller]

On 2020-02-04 14:40, Paul Moore wrote:
>> The answer to that concern is to not break compatibility in the first place,
>> and/or revert it when the mistake is discovered.  It happens.
>
> That sounds to me like an argument for stagnation. We already take
> backwards compatibility very seriously. If you're suggesting that we
> don't even have the option of deprecating things, then I'm not sure
> how you expect the language to evolve.

No, I chose the wrong phrasing there.  Have been arguing for deprecations to 
occur on schedule but removals to occur later.  By "not break compatibility…" I 
meant not to break it in a large, destructive manner.  Small ones, sure.



> The point has already been made that "keeping code around but
> deprecated" isn't the problem, it's bug triage, telling people who
> report problems with deprecated code that "this is not going to be
> fixed", educating people who copy/paste old and deprecated code and
> wonder why they are now getting warnings with it, etc. I think it's
> probably up to the core devs (who do the work) to judge what is an
> "undue burden", but if you do want to try to judge it, please take all
> of those extra tasks into account when reckoning up.

This happens already and won't go away.  I'm arguing that a *very* predictable 
release process helps and doesn't hurt in this department, resulting in fewer 
questions.  Instead of every release is a unique snowflake to be considered. 
Still have questions?  Go to FAQ #42.



> Restricting compatibility breaks to the major version
> isn't that important in my experience. IMO, the version number isn't
> anywhere near as important as the *process* of handling backward

It matters, when say Ubuntu drops X.4 when X.6 comes out and X.6 isn't backwards 
compatible.  You get forced to update or find one of the various workarounds.  I 
argue this should happen less frequently at predictable times.



> No, it's that conserving the *extremely* limited resource that is
> freely donated, volunteer core developer time is essential if we want
> to have a viable core development team at all.


Sorry, didn't mean that part as an attack, rather an illustration of the 
tradeoff being made.  Now if PSF needs help to build a more predictable release 
process, well then, by all means ask.  But that can't happen until the decision 
is made to do it.


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

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Mike Miller]

On 2020-02-04 12:10, Brett Cannon wrote:

Please be careful making that claim. Over my 16 years of helping manage this 
project I can tell you that claim is not universally true no matter how small 
and simple you think something is.


The answer to that concern is to not break compatibility in the first place, 
and/or revert it when the mistake is discovered.  It happens.


As mentioned, significant breaks are now discouraged.  The code is already 
written, so I'd argue keeping it deprecated potentially a few years extra in a 
regular process is not an undue burden.



Python predates semver. Assume every feature/minor release potentially has a 
breaking change and we have (hopefully) been raising warnings to the user for 
the past two years about the breaking change coming.


Hmm, was thinking about MS-DOS when I wrote that.  Still, I don't think this a 
good system having breaking changes in the minor version number.  It's not 
traditional and it's not newfangled either, it's relatively unique.


On that note, just noticed that Wikipedia has its own section for Python under 
the "Software Versioning" article:


The PSF has published PEP 440 -- Version Identification and Dependency
Specification,[16] outlining their own flexible (complicated) scheme, that
defines an epoch segment, a release segment, pre-release and post-release
segments and a development release segment.

https://en.wikipedia.org/wiki/Software_versioning#Python


The main argument here seems to be it this uncommon versioning scheme saves core 
developer time, (unsaid) at the expense of dev or end-user time.  As there are 
probably a million end-users per Python contributor, I argue this is not a good 
tradeoff to make.


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

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Mike Miller]

On 2020-02-03 17:00, Brett Cannon wrote:

Until you're being asked to maintain all of that for a decade. We paid a major 
price keeping Python 2 alive for over a decade. Now I'm not saying it wasn't 
the right thing to do considering what we changed, but for the stuff we are 
talking about removing it doesn't require a massive rewrite on the behalf of 
users. And we know from experience anything that is left in will get used no 
matter how loudly we try to broadcast that fact (and we know people still do 
not have a habit of running their code with warnings turned on).


Potentially up to a decade, often not.

We seem to agree that these are most likely minor things like duplicate import 
paths and such.  The maintenance burden is low on these items.  Also, due to 
skittishness, removals have drug out to five plus releases anyway.  So, why the 
aversion to formalizing the process, instead of "winging it" every release?  Why 
force devs/end-users to maintain state about what release is compatible or waste 
time on investigation?


Really, this was solved decades ago.  Everyone knows what to do when a major 
version number changes.  Other language platforms are not afraid to change them, 
likely because the breaks were typically minor and not break-the-world events. 
Just like we're talking about here.


More broadly, an agile cadence is great for innovative apps, not so great for 
mature platforms.  Platforms are supposed to provide stability and 
predictability, and the popular ones do.


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

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Mike Miller]

On 2020-02-04 04:16, Rhodri James wrote:
I think that just enables laziness.  "We don't need to worry about the 
deprecations, nothing is going to happen for years yet," is more or less what 
happened with the Python2 to Python3 shift.  People naturally enjoy adding shiny 
new features to their projects over maintenance.


That's an uncharitable interpretation.  Not everyone has the luxury of fixing 
broken code every year.  (New release schedule)  It's not how most of the 
industry works either.



As a refinement to the idea above, perhaps a sub rule could be added:

   - No deprecations should appear in a X.9 release to give folks time
 to prepare.


That feels like a very bad idea indeed.  If you don't tell people things are 
going away, they definitely won't prepare for that.


This point is not suggesting to break things and "not tell anyone."  Rather to 
avoid any compatibility breaks on the ultimate release of a series to give folks 
a minimum of two years to react.


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

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Mike Miller]

On 2020-02-03 01:50, Petr Viktorin wrote:
When the changes are rolled out gradually across minor releases, those that 
cause unforeseen trouble in real-world code can be identified in the 
alphas/betas, and rethought/reverted if necessary.



To be clear, my suggestion was to maintain gradual deprecations and warnings, 
but have a single removal event at the start of a new version major number.  So 
there will be many years of betas and releases to haggle over.


Also, I believe it is possible to separate the "mechanically fixable" breaks 
from larger changes in fundamentals.  Few folks are willing to entertain or 
stomach the latter at this point in the lifecycle of Python.  If one happens to 
occur, scheduling it for X.4 instead of X+1.0 doesn't help much, and may serve 
to obscure it.


In some sense, distributing the breaks avoids potential/temporary bad press at 
the cost of easy planning.  However, it feels like a very regular, easy to 
understand process should trump that in the long run.


As a refinement to the idea above, perhaps a sub rule could be added:

  - No deprecations should appear in a X.9 release to give folks time
to prepare.

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

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

[Mike Miller]

On 2020-01-23 07:20, Victor Stinner wrote:
> Python 3.9 introduces many small incompatible changes which broke tons


There's a well-known and established way of signaling breaking changes in 
software platforms—it is to increment the major version number.


Rather than debating the merits of breaking code on 3.9 or 3.10, wouldn't it 
make more sense to do it in a Python 4.0 instead?  Well, either of these 
strategies sound logical to me:


- Python 4.0 with removal of all of the Python 3-era deprecations
- Continuing Python 3.1X with no breaks

In other words, we should keep compatibility, or not.  In any case, from the 
looks of it these will be tiny breaks compared to the Unicode transition.


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

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Mike Miller]

On 2019-12-03 18:41, Ned Batchelder wrote:
> Has anyone yet given a reason to remove it? It will change working code into
> broken code. Why do that?

I've heard a few complaints over the years about the number of combinations of 
string prefixes being a problem and a high barrier to new ones being accepted.
Especially since they are allowed to be capital letters as well, which I've 
never actually seen used in the real world.  Some code formatters already fix these.


At the appropriate time, hopefully we can deprecate u… and the capital prefixes 
too.

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

Re: [Python-Dev] Call for prudence about PEP-572

[Mike Miller]

On 2018-07-07 06:09, Giampaolo Rodola' wrote:
 I initially found myself disliking the idea as a whole but 
https://github.com/python/cpython/pull/8122 made me (and others) reconsider it 
quite a bit (see: https://twitter.com/grodola/status/1015251302350245888). 
PR-8122 clearly shows an improvement in expressiveness and compactness (many 
folks argue this is too much) 



One of the requirements from the PEP (informing its design) is that there would 
be a significant need and opportunities to use it with multiple and/or compound 
conditions.


While it may be a function of Victor's choices, from my reading of the pull 
request the vast majority of the improved lines has but a single, simple 
condition such as:


 while (data := f.readframes(1024)):

I believe Giampaolo has a good point.  These expressions are useful, however 
don't seem to have much value outside these examples.


On the subject on imagining how they would be used, suppose we could look at 
JavaScript or other expression-oriented languages for best practices.  Didn't 
find many admonitions however, other than keep it simple:


https://stackoverflow.com/q/9726496/450917

-Mike
___
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] Examples for PEP 572

[Mike Miller]

On 2018-07-04 00:25, Nathaniel Smith wrote:

The only cases that seem potentially valuable to me are the ones that
are literally the form 'if  := ` and 'while  :=
'. (I suspect these are the only cases that I would allow in
code that I maintain.) The PEP does briefly discuss the alternative
proposal of restricting to just these two cases, but rejects it
because it would rule out code like 'if ( := )
 '. But those are exactly the cases that I want to
rule out, so that seems like a plus to me :-).

The 'if  as ' syntax would be a simple way to encode
exactly these simple non-harmful cases. The PEP rejects it on the
grounds that 'as' is already used in a different way by 'except' and
'with'. But... 'as' is *also* used in the *same* way by 'import', so
the argument feels disingenuous. Yeah, there'd be an inconsistency,
but that inconsistency already exists, and adding 'if ... as' and
'while ... as' wouldn't create any *new* inconsistencies.



Agreed, tried to make this point in several threads.

-Mike
___
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 572, VF/B, and "Shark Jumping"

[Mike Miller]

On 2018-07-05 10:52, Ivan Pozdeev via Python-Dev wrote:
>

Perhaps, however I'm not advocating using "EXPR as NAME" with "with" as it 
wouldn't be useful enough, only limited to if/while/comp.


-Mike
___
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 572, VF/B, and "Shark Jumping"

[Mike Miller]

On 2018-07-05 04:28, Ivan Pozdeev via Python-Dev wrote:

This is as intended.
I wanted to show my summary and Chris' refuttal, with links to both original 
posts. Because my letter is much shorter than the originals while carrying the 
same message. Also to show that I've made the same mistake, which puts things in 
perspective: how an outsider could get the wrong idea.



There will always be a long tail of new languages doing any and everything. 
Which new languages are actually being used?  The more limited ones.  Static 
typing, fewer foot-guns.


Arguably Elixir should have been in the original list, but it is practically 
unknown compared to Kotlin, for example.


-Mike
___
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 572, VF/B, and "Shark Jumping"

[Mike Miller]

On 2018-07-04 17:22, Chris Angelico wrote:

- the "if expr as name:" syntax is able to handle only the tiniest
proportion of cases, because many MANY situations require a condition
after that. You can't write this, for instance:

if f(x) as spam < 0:
 print(spam)


The original use cases didn't ask for these compound conditions.  In fact many 
of the other threads this week are advising folks to break up an expression with 
compound conditions due to lack of readability.


The common cases described:

- compute value once in a comprehension
- loop and a half (reading file, socket)
- common regex match

More complex cases can be handled the old way.

> Python uses "as NAME" for things that
> are quite different from this, so it's confusing),

It's less confusing, and limited.  No one bats an eyelash after using "as" day 
after day in Python and SQL.


Good day,
-Mike
___
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 572, VF/B, and "Shark Jumping"

[Mike Miller]

On 2018-07-04 23:20, Steven D'Aprano wrote:

It simply isn't true that modern languages are moving away from
assignment expressions. Some are. Some aren't. Even those that don't
support assignment expressions in general usually support special syntax
to allow it in a few contexts.


The older post you are referring and this thread describe the exact situation in 
your last sentence.  The limited assignment "compromise" is a common solution 
nowadays, just as this thread discusses.


Repeating "it won't work" when it has been shown to work well in several 
languages is nonsensical.  Yes, the available solutions are not perfect, but I 
still maintain "as" is less disruptive and doesn't reverse 25 year-old design 
choices, but rather works with them.


-Mike
___
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 572, VF/B, and "Shark Jumping"

[Mike Miller]

Recently on Python-Dev:

On 2018-07-03 15:24, Chris Barker wrote:
> On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico  On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka 
>
> > I believe most Python users are not
> > professional programmers -- they are sysadmins, scientists, hobbyists
> > and kids --
>
> [citation needed]
>
> fair enough, but I think we all agree that *many*, if not most, Python users
> are "not professional programmers". While on the other hand everyone involved
> in discussion on python-dev and python-ideas is a serious (If not
> "professional") programmer.


Python Audience - wants clarity:

Not sure I'd say that most users are not professionals, but one major strength 
of Python is its suitability as a teaching language, which enlarges the 
community every year.


Additionally, I have noticed a dichotomy between prolific "C programmers" who've 
supported this PEP and many Python programmers who don't want it.  While C-devs 
use this construct all the time, their stereotypical Python counterpart is often 
looking for simplicity and clarity instead.  That's why we're here, folks.



Value - good:

Several use cases are handled well by PEP 572.  However it has been noted that 
complexity must be capped voluntarily relatively early—or the cure soon becomes 
worse than the disease.



Frequency - not much:

The use cases for assignment-expressions are not exceedingly common, coming up 
here and there.  Their omission has been a very mild burden and we've done 
without for a quarter century.


Believe the authors agreed that it won't be used too often and won't typically 
be mis- or overused.



New Syntax - a high burden:

For years I've read on these lists that syntax changes must clear a high 
threshold of the (Value*Frequency)/Burden (or VF/B) ratio.


Likewise, a few folks have compared PEP 572 to 498 (f-strings) which some former 
detractors have come to appreciate.  Don't believe this comparison applies well, 
since string interpolation is useful a hundred times a day, more concise, clear, 
and runs faster than previous functionality.  Threshold was easily cleared there.



Conclusion:

An incongruous/partially redundant new syntax to perform existing functionality 
more concisely feels too low on the VF/B ratio IMHO.  Value is good though 
mixed, frequency is low, and burden is higher than we'd like, resulting in "meh" 
and binary reactions.


Indeed many modern languages omit this feature specifically in an effort to 
reduce complexity, ironically citing the success of Python in support.  Less is 
more.



Compromise:

Fortunately there is a compromise design that is chosen often these days in new 
languages---restricting these assignments to if/while (potentially comp/gen) 
statements.  We can also reuse the existing "EXPR as NAME" syntax that already 
exists and is widely enjoyed.


This compromise design:

1  Handles the most common cases (of a group of infrequent cases)
0  Doesn't handle more obscure cases.
1  No new syntax (through reuse)
1  Looks Pythonic as hell
1  Difficult to misuse, complexity capped

Score: 4/5

PEP 572:

1  Handles the most common cases (of a group of infrequent cases)
1  Handles even more obscure cases.
0  New syntax
0  Denser look: more colons, parens, expression last
0  Some potential for misuse, complexity uncapped

Score: 2/5


Thanks for reading, happy independence,
-Mike

___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Mike Miller]

On 2018-06-22 19:46, Steven D'Aprano wrote:

- the inexplicable (to me) decision to say "for x of array" instead of
   "for x in array";


Believe JavaScript has for…in, but as usual in the language it is broken and 
they needed a few more tries to get it right.  for…of is the latest version and 
works as expected.


-Mike

___
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] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Mike Miller]

Sorry all, wasn't specific enough.

By "modern" I mean the last decade perhaps.  New languages that have had a 
chance to look at the older generations and choose their best ideas, while 
leaving behind the rest.


Personally I thought of Swift (Ryan mentioned), Kotlin, Rust, and perhaps Go, 
though Go wasn't focused on breaking new ground outside of ease of concurrency. 
I don't know R or Felix at all, but sound interesting.  Nim is another I'm 
vaguely aware of.  They surely have given some thought to the issue.


One thing that jumped out at me is that most replies here jumped to the question 
of whether they supported assignment-expressions, but that is only one potential 
solution.  To be more clear, I wondered how did they solve "the problem itself?" 
 Was their solution different?  Ryan somewhat alluded to that, but I'd like to 
dig in a bit on that part.


In contrast, in many of the other threads I heard, "C, C++, C#, Java, etc do 
assignment-expressions, they're useful and not so hard to learn."  Ok that's 
reasonable, but where is the industry headed?  Python deferred long enough that 
we don't necessarily have to choose a classic solution.


So, it sounds like many of the new generation of languages are not embracing 
these expressions everywhere but rather letting folks do an assignment right in 
the statement where their use case applies, if, while, maybe comprehensions.  Is 
that accurate?


Looks like I've got some homework to do, haha.

-Mike


On 2018-04-26 17:58, Steven D'Aprano wrote:

What counts as a modern language? Less than five years old? Less than
fifty years old? Are Javascript, Ruby and R modern? They all support
assignment as expressions.

I think Koitlin, Rust and Go prohibit assignment as expressions.

Swift assignment evaluates as Void (equivalent to None in Python, I
guess), so you can use assignment in an expression but it returns
nothing and only operates by side-effect.

As far as type hints go, I think that if you need explicit type hints in
the middle of an expression, it's a bad idea and you ought to pull it
out as a separate statement. That applies regardless of whether that
expression involves binding or not.

___
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] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Mike Miller]

On 2018-04-25 19:36, Ryan Gonzalez wrote:

By now we've searched over the current proposal in excruciating detail.

However, there were two good questions in this message which I haven't seen 
addressed yet:


- How are other modern languages solving this issue?
- How does this new construct intersect with typing functionality?

-Mike
___
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 572: Write vs Read, Understand and Control Flow

[Mike Miller]

On 2018-04-24 21:05, Nathaniel Smith wrote:

On Tue, Apr 24, 2018 at 8:56 PM, Tim Peters  wrote:

It would actually be quite convenient, and far less error-prone, to
add a binding construct inside a complicated expression for purposes
of running under a debugger.  The alternative is typing the


A bit like breaking complicated expressions into several lines, with or without 
assignments for readability.  ;-)



I thought this was what q was for :-)

https://pypi.org/project/q/


Where have you been all my life, q?

-Mike


___
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 572: Write vs Read, Understand and Control Flow

[Mike Miller]

On 2018-04-24 02:21, Victor Stinner wrote:
> I have been asked to express myself on the PEP 572. I'm not sure that


Thanks.  Well written and I've had the same thoughts myself.

___
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 572: Assignment Expressions

[Mike Miller]

On 2018-04-24 12:59, Chris Angelico wrote:

Aside from the restriction to binding only to a simple name, and the
fact that they're also an expression with the same value, how are they
not the same as plain assignment? Any discrepancies should be
considered bugs.


Slightly different in that they return the value, and are expressions not 
assignment statements.


Now, I agree that's not a difference of much consequence, but the difference 
from "import as" is not either.


-Mike

___
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 572: Assignment Expressions

[Mike Miller]

On 2018-04-23 14:19, Barry Warsaw wrote:

Me too.  Plus we *already* have precedence for spelling name bindings in 
similar constructs, such as import statements, with statements, and exceptions. 
 It seems like a natural and Pythonic approach to extend that same spelling to 
binding expressions rather than introducing new, weird, symbols.


We've survived for decades without this syntax, so don't think the need is so 
great that we need to rush it.  Let's not "jump the shark."  :D


In my opinion, "EXPR as NAME" is the only version worthy enough for the 
readability of Python.  It reads like psuedo-code, as advocates have described 
in the past, and already used frequently in a fuzzy, non-dogmatic manner.


The point about the potential of a bug in the "with" statement is worth serious 
consideration however.  I don't have a problem with it, but if deemed 
intolerable there was an additional solution I read upthread, believe by Kirill 
and Steve.


Merely that, since all current use cases are in the if/while/comprehension 
statements, it might be a good idea to limit binding-expressions there to avoid 
issues/overuse elsewhere.


Well, there are a number of mitigations to the "with" issue that could be 
considered.


(Hoping that this is my last post on the subject.)

-Mike

___
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 572: Assignment Expressions

[Mike Miller]

On 2018-04-23 15:36, Guido van Rossum wrote:
- the semantics are subtly different from all other uses of 'as' in Python; I'd 
like to reserve 'as' for "not a plain assignment"


It's conceptually similar to "import as", no?  The keyword "as" is a fuzzy yet 
intuitive concept already.


Also, these "binding expressions" are not exactly plain assignment, as it has 
been known.


-Mike
___
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 572: Assignment Expressions

[Mike Miller]

On 2018-04-22 14:33, Chris Angelico wrote:

with open(fn) as f:
with (open(fn) as f):

These two do the same thing, but only because a file object's
__enter__ returns self. So it's dangerous, because it WILL work... and
people will get into the habit of parenthesizing to permit a 'with'
statement to go across line breaks. And then they'll use a different
context manager, like closing(), or a PsycoPG2 database connection (I
think), where it returns something else. And it'll work, until they go
over multiple lines, and then suddenly the semantics change.



Why do you think folks will be rushing to parenthesize with statements when it 
has always been a syntax error, there is years of code and docs that show 
otherwise, no use cases, and will take years for 3.8 to trickle out?


Seems remote, and there are mitigations that could be done.

Again it's back to "people could write bad code," but they already can with only 
+/* and ().


-Mike
___
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 572: Assignment Expressions

[Mike Miller]

On 2018-04-22 12:37, Chris Angelico wrote:
> Kinda, except that that's not quite a match either. But mainly, the
> comparison with 'with' and 'except' is dangerously incompatible.

Hmm, looks very close conceptually, though mechanics are different.

Dangerous feels like an exaggeration however.  I've made the argument that 
occurrences would be very rare, but if I'm wrong, the code should blow up on its 
first run.  Perhaps a sanity check could be put in?


There is a section of your PEP that argues against the "bad code could 
potentially be written" argument, and think it applies here.



> Maybe not, but why not just use ':=' to avoid that?

Don't hate it but feels like Pascal and C and not "Pythonic."  Too many colons, 
avoiding the questions about the difference between "=" and ":=".  Expression 
first is another win.  People know how to use "as".


> Intuitive consistency isn't enough to handle complex cases.
> Programming languages that favour intuitive consistency end up with a
> million special cases.

Ok, but I think we have all the tools we need here, there's just an extra place 
to stub your toe out in the weeds.


To turn the question around, are we really worried that this awkward code (or 
some variant) is about to be written?


with (cm_obj := callable()) as enter_result_obj:
cm_obj.write()  #  AttributeError

If not, I argue it is a theoretical problem that, if hit, blows up immediately.

-Mike


___
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 572: Assignment Expressions

[Mike Miller]

On 2018-04-21 19:57, Chris Angelico wrote:

Thanks for being patient.

Looks like the crux of the issue is that "with … as" binds the result of the 
enter function rather than the context-manager object, as it might first appear. 
Therefore it's not compatible with how "as" is used for direct name bindings 
after "import" statements or this sub-proposal.  Additionally, "except Class as 
instance" names the instance rather than the class.


So, the "as" keyword is already operating at an intuitive level rather than 
idealistic perfection.  Three different semantics for import/with/except, 
correct?  This sub-proposal lines up with the import use, I believe.


Given that there are no use cases for using assignment-expressions in the 
import/with/except statements, and it could be documented that if one insists an 
extra set of parens could make it work:


with (callable() as cm_obj) as enter_result_obj:
pass

It doesn't feel like this issue should be a blocker.

TL;DR - Been feebly trying to make the argument that everyday "intuitive 
consistency" (where the expression will be used) is more important than avoiding 
theoretical problems.  I've never seen complex with/except statements in the 
wild and don't expect this feature to significantly alter that.


-Mike

___
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 572: Assignment Expressions

[Mike Miller]

Round 2 (Changed order, see below):

1. with open(fn) as f:   # current behavior
2. with (open(fn) as f): # same

3. with closing(urlopen(url)) as dl: # current behavior
5. with (closing(urlopen(url)) as dl):   # same

4. with closing(urlopen(url) as dl): # urlopener named early


On 2018-04-20 17:15, Chris Angelico wrote:

The second and fifth could be special cased as either the same as
first and third, or as SyntaxErrors. (But which?) 


If they are expressions, they should be the same once evaluated, no?

(I had a brief episode where I wrote that "as" was required with "with", instead 
of the CM object, sorry. :)



The fourth one is very tricky. If 'expr as name' is allowed inside arbitrary
expressions, why shouldn't it be allowed there?


Yes, they should be allowed there.


The disconnect between viable syntax and useful statements is problematic here.


Number 4 appears to name the urlopener early.  Since closing() returns it as 
well, might it work anyway?


Might be missing something else, but #4 looks like a mistake with the layout of 
the parentheses, which can happen anywhere.  I don't get the sense it will 
happen often.


Cheers,
-Mike
___
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 572: Assignment Expressions

[Mike Miller]

On 2018-04-20 14:59, Jelle Zijlstra wrote:
> In other words, the with statement would continue to require an as clause
> outside of the parentheses.  A double name binding doesn't seem very 
useful
> however.
>
> The with statement does not require an as clause.

Sorry, more precisely a contenxt-manager object to be returned.  So perhaps this 
"with" issue may not be one at all.


___
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 572: Assignment Expressions

[Mike Miller]

On 2018-04-20 12:43, Chris Angelico wrote:
> Except that that's now a feature of expressions, NOT of the loop
> construct. And then you're left with: why not permit this everywhere?

Sorry, I didn't understand.  Didn't mean to imply it couldn't be used 
everywhere.

> What would these mean?

My expectations:

with open(fn) as f:   # current behavior
with (open(fn) as f): # syntax error, missing clause
with closing(urlopen(url)) as dl: # current behavior
with closing(urlopen(url) as dl): # syntax error, missing clause
with (closing(urlopen(url)) as dl):   # syntax error, missing clause

In other words, the with statement would continue to require an as clause 
outside of the parentheses.  A double name binding doesn't seem very useful however.


-Mike
___
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 572: Assignment Expressions

[Mike Miller]

On 2018-04-19 23:52, Chris Angelico wrote:

And are limited to conditions that check the truthiness/falsiness of
the value you care about. So that works for re.match, but not for
anything that might return -1 (a lot of C APIs do that, so if you're
working with a thin wrapper, that might be all you get), and it'll
encourage people to use this form when "is not None" would be more
appropriate (setting up for a failure if ever the API returned a


From the previously discussed code, it might look like this:

while (file.get_next_token() as token) != -1:
doc += token

Shouldn't be needed often, but I find it readable enough.

More generally, I've been -0 on this idea because I've come to appreciate 
Python's less-clever i.e. "dumb" loop syntax, and ":=" combined with 
assignment-expressions doesn't feel like Python at all but rather Pascal and C 
had a love-child, haha.


I could mildly support the "as" syntax however, since it is so darn readable and 
has analogues in other places.


That leaves what to do with "with".  Guess I missed the part in the discussion 
where we couldn't fit the syntax into it.  Would requiring parens here not work?


with (expr() as name) as conman:
pass

This should rarely be necessary or useful, correct?  Perhaps disallow for now.

On assignment to names/subscripts, just names sounds simpler for the first 
round.

Also the current "while" itself could be a bit simpler by making the expression 
optional and slightly less verbose:


while:
points = learner.get(static_hint)
if not points:
   break


Thanks for the hard work,
-Mike
___
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)

[Mike Miller]

On 2018-04-07 02:08, Steven D'Aprano wrote:

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


Interesting, I'd forgotten about the module but this thread brought it from 
dusty backup tape back into my brain.  Part of the problem may be the generic name.


I just used it for a programming challenge and it worked quite well. :-)  The 
source is close to trivial, not a burden, and I found the module useful and easy 
to use.


Only nitpick is that the "repeat last action on empty line" is a poor default I 
think.


-Mike

p.s.  The bug listed above has the authors of cmd2 planning a 
simplified/compatible version that could become the next "cmd."

___
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] The `for y in [x]` idiom in comprehensions

[Mike Miller]

I'm not sure, I found the "with f(x) as y" form previously mentioned the most 
readable despite it being a new use case, while not needing new keywords.


-Mike


On 2018-02-23 22:07, David Mertz wrote:
FWIW, the nested loop over a single item is already in the language for 15 years 
or something. It's not that ugly, certainly not enough to need a new 'let' or 
'where' keyword that basically does exactly the same thing with 3 fewer characters.


On Feb 23, 2018 10:04 PM, David Mertz > 
wrote:


___
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] [RELEASE] Python 3.7.0b1 is now available for testing

[Mike Miller]

On 2018-01-31 17:34, Ned Deily wrote:

Please see "What’s New In Python 3.7" for more information.
Additional documentation for these features and for other changes
will be provided during the beta phase.

https://docs.python.org/3.7/whatsnew/3.7.html



I see that the new classmethod fromisoformat in datetime arrived (thanks all) 
but it hasn't yet received a blurb in the what's new page.


https://docs.python.org/3.7/library/datetime.html#datetime.datetime.fromisoformat

-Mike
___
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] Is static typing still optional?

[Mike Miller]

On 2017-12-22 12:15, Chris Barker wrote:

Would it be crazy to bring typing.Any into the builtin namespace?

@dataclass:
     a: Any
     b: Any = 34
     c: int = 0

That reads pretty well to me

> And having Any available in the built in namespace may help in other cases 
where

There is already an "any" function in the builtins.  It looks fine but not sure 
how it will interact with type checkers.


The "dataclass.Data" idea mentioned in a sibling thread is good alternative, 
though just wordy enough to make ... a shortcut.


-Mike
___
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] Is static typing still optional?

[Mike Miller]

On 2017-12-19 02:53, Paul Moore wrote:

Also, the fact that no-one raised this issue during the whole time the
PEP was being discussed (at least as far as I recollect) and that
Guido (who of all of us should be most aware of what is and isn't
acceptable use of annotations in the stdlib) approved the PEP,
suggests to me that this isn't that big a deal.



Hi, I asked about this in the first posting of the PEP and agree with Chris.

https://mail.python.org/pipermail/python-dev/2017-September/149406.html


There is definitely a passive bias towards using types with dataclasses in that 
the Eric (the author) doesn't appear to want an example without them in the 
pep/docs.


It seems that typing proponents are sufficiently enamored with them that they 
can't imagine anyone else feeling differently, haha.


Personally, I wouldn't use types with Python unless I was leading a large 
project with a large team of folks with different levels of experience.  That's 
where types shine, and those folks might be better served by Java or Kotlin.


So we hearing that "types are optional" while the docs may imply the opposite. 
Liked the ellipsis since None is often used as a sentinel value and an extra 
import is a drag.


-Mike
___
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] Support of the Android platform

[Mike Miller]

I've used Kivy with buildozer on Android and it generally works well, with a few 
issues.  Currently it uses the Crystax NDK for Python 3 support.


Does anyone know how this development will affect it?

-Mike


On 2017-12-15 10:06, Glenn Linderman wrote:
I see a variety of Python apps on Android, but I have no idea how well they 
work, or what their source is, or if they are supported, or what features of 
Python or its standard library might not be available, etc. I've been too busy 
on other projects to take time to investigate them.


___
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] iso8601 parsing

[Mike Miller]

Guess the argument for limiting what it accepts would be that every funky 
variation will need to be supported until the endtimes, even those of little use 
or utility.


On the other hand, it might be good to keep the two implementations the same for 
consistency reasons.


Thanks either way,
-Mike


On 2017-12-07 17:57, Chris Barker - NOAA Federal wrote:
___
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] iso8601 parsing

[Mike Miller]

Yeah!  I'm available for writing docs and testing it if needed.

Performance is not a big concern in this first version, unless you've already 
written most of it.  If it is a concern for others then the third-party modules 
will still be available as well.


-Mike


On 2017-11-29 16:19, Paul G wrote:
I can write at least a pure Python implementation in the next few days, if not a 
full C implementation. Shouldn't be too hard since I've got a few different 
Cython implementations sitting around anyway.



___
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] iso8601 parsing

[Mike Miller]

Hi,

This thread isn't about the numerous third-party solutions that are a pip 
command away.  But rather getting a minimal return parser to handle 
datetime.isoformat() into the std library.


It's been needed for years, and hopefully someone can squeeze it into 3.7 before 
its too late.  (It takes years for a new version to trickle down to Linux dists.)


-Mike


On 2017-11-28 13:09, Skip Montanaro wrote:
It's got its own little parsing language, different than the usual 


___
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] iso8601 parsing

[Mike Miller]

This may have gotten bogged down again.  Could we get the output of 
datetime.isoformat() parsed at a minimum?  Perfection is not required.


Looks like there is a patch or two and test cases on the bug.

-Mike


Could anyone put this five year-old bug about parsing iso8601 format date-times 
on the front burner?


     http://bugs.python.org/issue15873

In the comments there's a lot of hand-wringing about different variations that 
bogged it down, but right now I only need it to handle the output of 
datetime.isoformat():


     >>> dt.isoformat()
     '2017-10-20T08:20:08.986166+00:00'

Perhaps if we could get that minimum first step in, it could be iterated on and 
made more lenient in the future.



___
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] iso8601 parsing

[Mike Miller]

Hi,

Could anyone put this five year-old bug about parsing iso8601 format date-times 
on the front burner?


http://bugs.python.org/issue15873

In the comments there's a lot of hand-wringing about different variations that 
bogged it down, but right now I only need it to handle the output of 
datetime.isoformat():


>>> dt.isoformat()
'2017-10-20T08:20:08.986166+00:00'

Perhaps if we could get that minimum first step in, it could be iterated on and 
made more lenient in the future.


Thank you,
-Mike
___
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 557: Data Classes

[Mike Miller]

On 2017-10-11 23:05, Nick Coghlan wrote:

It's akin to "static method", "class method", and "instance method" for function 
definitions (although the last one isn't a typical decorator, since it's the 
default behaviour for functions placed inside a class).


Thanks, I'm still thinking of it as inheritance for some reason.

-Mike

___
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 557: Data Classes

[Mike Miller]

On 2017-10-12 00:36, Stéfane Fermigier wrote:
"An object that is not defined by its attributes, but rather by a thread of 
continuity and its identity." (from 
https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks)


Not sure I follow all this, but Python objects do have identities once 
instantiated.  e.g. >>> id('')


See also the more general Wikipedia definition "An entity is something that 
exists as itself, as a subject or as an object, actually or potentially, 
concretely or abstractly, physically or not." 
(https://en.wikipedia.org/wiki/Entity).


In the context of DDD, entities are usually opposed to value objects: "An object 
that contains attributes but has no conceptual identity. They should be treated 
as immutable.". (https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks)


Attrs, and by extension the dataclass proposal (I guess), provide some support 
for both:


- Providing support for quickly constructing immutable objects from a bag of 
attributes, and providing equality based on those attributes, it helps implement 
Value Objects (not sure much more is needed actually)


- By supporting equality based on some "primary key", it will also help with 
maintaining the concept of "equality" in entities.


I don't believe either module particularly supports or restricts immutability?

-Mike
___
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 557: Data Classes

[Mike Miller]

On 2017-10-11 19:56, Nick Coghlan wrote:
 From my perspective, the main benefit of a compound name like "data class" is 
that it emphasises a deliberate behavioural choice (adopted from attrs): data 
classes are just regular classes, with some definition time logic to help define 
data fields.


IMO, the problem with the dataclass name isn't the data part, but the "class" 
part.  No other class has "class" in its name(?), not even object.  The 
Department of Redundancy Department will love it.


If it must be a compound name, it should rather be dataobject, no?

By contrast, if we give them their own name (as with suggestions like record, 
row, entity), that makes them start to sound more like enums: an alternative 
base class with different runtime behaviour from a regular class.


This pep also adds many methods for use at runtime, though perhaps the behavior 
is more subtle.


P.S. I'll grant that this reasoning doesn't entirely mesh with the naming of 
"Abstract Base Class", but that phrase at least explicitly has the word "base" 
in it, suggesting that inheritance is involved in the way it works.


There was some discussion over inheritance vs. decoration, not sure if it was 
settled.


(Just noticed that the abc module got away with a class name of "ABC," perhaps 
dataclass would be more palatable as "DC", though entity sounds a bit nicer.)


Cheers,
-Mike
___
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 557: Data Classes

[Mike Miller]

(Apologies for reviving a dead horse, but may not be around at the blessed 
time.)

As potential names of this concept, I liked record and row, but agreed they were 
a bit too specific and not quite exact.  In my recent (unrelated) reading 
however, I came across another term and think it might fit better, called an 
"entity."


It has some nice properties:

- Traditional dictionary definition, meaning "thing"
- Same specificity as the current base-class name: object
- Corresponds to a class or instance (depending on context) in data
  terminology


From: http://ewebarchitecture.com/web-databases/database-entities

An entity is a thing or object of importance about which data must be
captured. Information about an entity is captured in the form of attributes
and/or relationships.

All things aren't entities—only those about which information should be
captured. If something is a candidate for being an entity and it has no
attributes or relationships, it isn't an entity.


Thoughts?  Another candidate is "container" but is not very descriptive.

-Mike



On 2017-09-16 11:14, Steve Holden wrote:
I therefore propose "row", which is sufficiently neutral to avoid most current 
opposition and yet a common field-oriented mechanism for accessing units of 
retrieved data by name.

___
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 557: Data Classes

[Mike Miller]

On 2017-09-15 05:08, Michel Desmoulin wrote:

Because given how convenient it is, it will most probably becomes the
default way to write classes in Python. Not just for record.


Yes, would have been great if this was how the original object worked and the 
current barebones object was a base(object) or something like that.  Too late 
however.


Another option was "bag" which is more generic and brief, and might seem to fit 
better, but the discussion went towards record.


-Mike
___
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 557: Data Classes

[Mike Miller]

On 2017-09-14 10:45, Stefan Krah wrote:

I'd expect something like a C struct or an ML record.


Struct is taken, and your second example is record.



 from dataclass import dataclass

This is more intuitive, since the PEP example also has attached methods
like total_cost().  I don't think this is really common for records.


Every class can be extended, does that mean they can't be given appropriate 
names?

(Not to mention dataclass is hardly intuitive for something that can have 
methods added.)


-Mike
___
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 557: Data Classes

[Mike Miller]

On 2017-09-12 21:05, Guido van Rossum wrote:
It's ironic that some people dislike "data classes" because these are regular 
classes, not just for data, while others are proposing alternative names that 
emphasize the data container aspect. So "data classes" splits the difference, by 
referring to both data and classes.


True that these data-classes will be a superset of a traditional record.  But, 
we already have objects and inheritance for those use cases.  The data-class is 
meant to be used primarily like a record, so why not name it that way?


Almost everything is extensible in Python; that shouldn't prevent focused names, 
should it?




Let's bikeshed about something else.


An elegant name can make the difference between another obscure module thrown in 
the stdlib to be never seen again and one that gets used every day.  Which is 
more intuitive?


from collections import record

from dataclass import dataclass



Would the language be as nice if "object" was named an "instanceclass?"  Or 
perhaps the "requests" module could have been named "httpcall."  Much of the 
reluctance to use the attrs module is about its weird naming.


Due to the fact that this is a simple, potentially ubiquitous enhancement an 
elegant name is important.  "For humans," or something, haha.


-Mike
___
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 557: Data Classes

[Mike Miller]

On 2017-09-12 19:09, Nick Coghlan wrote:

On 13 September 2017 at 02:01, Chris Barker - NOAA Federal
 wrote:

This really does match well with the record concept in databases, and most
people are familiar with that.


No, most people aren't familiar with that - they only become familiar
with it *after* they've learned to program and learned what a database
is.


Pretty sure he was talking about programmers, and they are introduced to the 
concept early.  Structs, objects with fields, random access files, databases, 
etc.  Lay-folks are familiar with "keeping records" as you mention, but they are 
not the primary customer it seems.


Record is the most common name for this ubiquitous concept.



whether its referring to the noun (wreck-ord) or the verb (ree-cord).


This can be grasped from context quickly, and due to mentioned ubiquity, not 
likely to be a problem in the real world.  "Am I going to ree-cord this class?"




Also, considering their uses, it might make sense to put them in the
collections module.


Data classes are things you're likely to put *in* a collection, rather
than really being collections themselves (they're only collections in
the same sense that all Python classes are collections of attributes,
and that's not the way the collections module uses the term).



Yes, a collection of attributes, not significantly different than the namedtuple 
(that began this thread) or the various dictionaries implemented there already. 
The criteria doesn't appear to be very strict, should it be?


(Also, could be put into a submodule and imported into it maintain modularity. 
Where it lands though isn't so important, just that collections is relatively 
likely to be imported already on medium sized projects, and I think the 
definition fits, collections == "bags of stuff".)


Cheers,
-Mike
___
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 557: Data Classes

[Mike Miller]

On 2017-09-11 17:00, Barry Warsaw wrote:


I’ve used ‘bag’ too, but I’m not sure that’s descriptive enough for the stdlib.


Well, "the Pythons" were irreverent, were they not?  ;)

-Mike

___
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 557: Data Classes

[Mike Miller]

On 2017-09-11 05:26, Eric V. Smith wrote:

On 9/10/17 10:27 PM, Raymond Hettinger wrote:


I've typically used these type of objects as records.  When in an irreverent 
mood I've called them bags.  The short name is helpful as they get used all over 
the place.  I'll add Nick's "declarative" as it describes the problem well from 
another angle:


- record
- bag
- declarative

Anyone like these?  I find them more intuitive than the existing name.

Also, considering their uses, it might make sense to put them in the collections 
module.


-Mike
___
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 557: Data Classes

[Mike Miller]

On 2017-09-10 18:20, Eric V. Smith wrote:

I'll think about adding some more language to the PEP about it.


Agreed, was only looking for mention or example that a specific type was not 
required.  Perhaps even dusting off the word "annotation" to describe them.


___
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 557: Data Classes

[Mike Miller]

On 2017-09-10 23:38, Michel Desmoulin wrote:

I'm going to put some words in explaining why I don't want to use base
classes (I don't think it buys you anything). Do you have a reason for
preferring base classes?


Not preferring, but having it as an alternative. Mainly for 2 reasons:

1 - data classes allow one to type in classes very quickly, let's
harvest the benefit from that.

Typing a decorator in a shell is much less comfortable than using
inheritance. Same thing about IDE: all current ones have snippet with
auto-switch to the class parents on tab.

All in all, if you are doing exploratory programming, and thus
disposable code, which data classes are fantastic for, inheritance will
keep you in the flow.

2 - it will help sell the data classes

I train a lot of people to Python each year. I never have to explain
classes to people with any kind of programming background. I _always_
have to explain decorators.

People are not used to it, and even kind fear it for quite some time.

Inheritance however, is familiar, and will not only push people to use
data classes more, but also will let them do less mistakes: they know
the danger of parent ordering, but not the ones of decorators ordering.


I also feel inheritance is more intuitive (and easily entered), but missed the 
reason it wasn't chosen.  ;)


-Mike

___
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 557: Data Classes

[Mike Miller]

On 2017-09-10 14:23, Ivan Levkivskyi wrote:
This is not the case, static support for dataclasses is an import point of 
motivation.


I've needed this functionality a decade before types became cool again.  ;-)


It is hard to support static typing for many third party packages like attrs, 
since they use a lot of "magic".

Believe that attrs has its own validators.

As mentioned, nothing against static typing, would simply like an example 
without, to show that it is not required.


-Mike
___
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 557: Data Classes

[Mike Miller]

Thanks for the info.

On 2017-09-08 15:40, Eric V. Smith wrote:

- Are types required?


Annotations are required, the typing module is not.


  Maybe an example or two with Any?


I'd rather leave it like it is: typing is referenced only once, for ClassVar.



Guess I really meant "object" or "type" above, not "typing.Any."

For a decade or two, my use of structs/records in Python has been 
dynamically-typed and that hasn't been an issue.  As the problem this PEP is 
solving is orthogonal to typing improvements, it feels a bit like typing is 
being coupled and pushed with it, whether wanted or not.


Not that I dislike typing mind you (appreciated on projects with large teams), 
it's just as mentioned not related to the problem of class definition verbosity 
or lacking functionality.


Cheers,
-Mike
___
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 557: Data Classes

[Mike Miller]

Thanks for the info.

On 2017-09-08 15:40, Eric V. Smith wrote:

- Are types required?


Annotations are required, the typing module is not.


  Maybe an example or two with Any?


I'd rather leave it like it is: typing is referenced only once, for ClassVar.



Guess I really meant "object" or "type" above, not "typing.Any."

For a decade or two, my use of structs/records in Python has been 
dynamically-typed and that hasn't been an issue.  As the problem this PEP is 
solving is orthogonal to typing improvements, it feels a bit like typing is 
being coupled and pushed with it, whether wanted or not.


Not that I dislike typing mind you (appreciated on projects with large teams), 
it's just as mentioned not related to the problem of class definition verbosity 
or lacking functionality.


Cheers,
-Mike
___
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 557: Data Classes

[Mike Miller]

On 2017-09-08 07:57, Eric V. Smith wrote:

I've written a PEP for…


Apologies for the following list dumb questions and bikesheds:


- 'Classes can be thought of as "mutable namedtuples with defaults".'

  - A C/C++ (struct)ure sounds like a simpler description that many more
would understand.

- dataclass name:

- class, redundant
- data, good but very common
- struct, used?
- Record?  (best I could come up with)


- Source needs blanks between functions, hard to read.

- Are types required?

  Maybe an example or two with Any?


- Intro discounts inheritance and metaclasses as "potentially interfering",
  but unclear why that would be the case.
  Inheritance is easy to override, metaclasses not sure?


- Perhaps mention ORMs/metaclass approach, as prior art:

  https://docs.djangoproject.com/en/dev/topics/db/models/

- Perhaps mention Kivy Properties, as prior art:

  https://kivy.org/docs/api-kivy.properties.html


- For mutable default values:

  @dataclass
  class C:
  x: list  # = field(default_factory=list)

  Could it detect list as a mutable class "type" and set it as a factory
  automatically?

  The PEP/bug #3 mentions using copy, but that's not exactly what I'm asking
  above.
___
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 557: Data Classes

[Mike Miller]

On 2017-09-08 07:57, Eric V. Smith wrote:

I've written a PEP for…


Apologies for the following list dumb questions and bikesheds:


- 'Classes can be thought of as "mutable namedtuples with defaults".'

  - A C/C++ (struct)ure sounds like a simpler description that many more
would understand.

- dataclass name:

- class, redundant
- data, good but very common
- struct, used?
- Record?  (best I could come up with)


- Source needs blanks between functions, hard to read.

- Are types required?

  Maybe an example or two with Any?


- Intro discounts inheritance and metaclasses as "potentially interfering",
  but unclear why that would be the case.
  Inheritance is easy to override, metaclasses not sure?


- Perhaps mention ORMs/metaclass approach, as prior art:

  https://docs.djangoproject.com/en/dev/topics/db/models/

- Perhaps mention Kivy Properties, as prior art:

  https://kivy.org/docs/api-kivy.properties.html


- For mutable default values:

  @dataclass
  class C:
  x: list  # = field(default_factory=list)

  Could it detect list as a mutable class "type" and set it as a factory
  automatically?

  The PEP/bug #3 mentions using copy, but that's not exactly what I'm asking
  above.
___
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] for...else

[Mike Miller]

On 2017-07-26 16:36, MRAB wrote:

"nobreak" would introduce a new keyword, but "not break" wouldn't.


Whenever I've used the for-else, I've put a # no-break right next to it, to 
remind myself as much as anyone else.


for...: not break: is the best alternative I've yet seen, congrats.  Perhaps in 
Python 5 it can be enabled, with for-else: used instead for empty iterables, as 
that's what I expected the first few dozen times.


-Mike
___
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] Details on replacing Python's dict object

[Mike Miller]

While not super technical, this talk by RH got me up to speed on recent 
improvements in the implementation:


https://www.youtube.com/watch?v=p33CVV29OG8

I believe there is some sample code linked that you might be able to use for 
testing/benchmarking, etc.


-Mike


On 2017-04-25 12:52, Jose Aaron Lopez Garcia wrote:

Hello:
I'm attempting to replace Python's dict object with an algorithm I created
myself to improve on memory and time consumption of hashmaps.
My initial tests on the algorithm show that it manages to keep a stable
logarithmic performance even with extremely high load factors (>0.9).
My knowledge of C and Python are good enough but I only know how the interpreter
works from a theoretical viewpoint, never really done any deep investigation
into it.
This said, I need expert help to port the algorithm, any insight into the
details of the dict object is greatly appreciated (and please let it be as
technical and guru-ish as possible).
Regards J. Aaron Lopez.


___
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] Py 3.6 on Ubuntu Zesty

[Mike Miller]

Hi,

Does anyone know why Python 3.6 is not the default Python 3 under the upcoming 
Ubuntu Zesty, or what may be holding it back?  Is there anyone that could give 
it a nudge?  It's in the repos but not as python3:


http://packages.ubuntu.com/zesty/python3
http://packages.ubuntu.com/zesty/python3.6

-Mike
___
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: Collecting information about git

[Mike Miller]

Mercurial is easier to use (for cases outside linux kernel development).  It's 
too bad the gravity of GitHub tends to override that.


-Mike


On 09/15/2015 05:20 PM, Chris Angelico wrote:

Looks like it's time I spun up my own hg, rather than using the 3.1.2
that ships with Debian.


＞ sudo pip install -U mercurial

  Downloading mercurial-3.5.1.tar.gz (4.4MB): 4.4MB downloaded
  Running setup.py (path:/tmp/pip_build_root/mercurial/setup.py) egg_info for 
package mercurial...


___
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 498: Naming

[Mike Miller]

Nice work!

So we're on the eve of pronouncement and though I've read several bring up the 
slightly-unfortunate naming of f-strings in the past, I've not seen recent 
discussion on the subject.  While the 498 implementation looks best, it still 
could be tweaked on the surface to use one of the other names or letters that 
had come up.  The original idea was to use f'' because it was thought that the 
feature would be locked to str.format, but that is no longer as true as it was 
originally.


To my knowledge there was i for interpolation, t for template, and e for 
expression suggested.  Any better ideas?


It's a good time to have this bikeshed discussion, because if the PEP is 
accepted news will get out and the name will be set in cement.  Previous drafts 
have made it out to hacker news and reddit, as the feature is exciting, so 
acceptance should as well.


-Mike


On 09/04/2015 06:45 PM, Eric V. Smith wrote:


I think it's now ready for Guido to pronounce on it.

___
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] String Interpolation Best Practices

[Mike Miller]

Ok, I thought that's what you and others were asking for in previous threads.

-Mike


On 09/08/2015 10:32 AM, Guido van Rossum wrote:

Sounds awfully premature. Style guides are typically updated in response to the

___
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] String Interpolation Best Practices

[Mike Miller]

Perhaps, here is my mention of it yesterday and response:

https://mail.python.org/pipermail/python-dev/2015-September/141487.html

Some have been asking for guidance on the subject though (see other links in 
this thread).  Maybe style-guide is the wrong terminology, but the idea wasn't 
intended to be insulting, haha.


I'll drop it and cut down PEP 502 a bit.  It is the easiest path for me, so no 
complaints.


-Mike


On 09/08/2015 11:25 AM, Guido van Rossum wrote:

I was not asking for style rules. Maybe you're thinking of my encouraging words
regarding turning PEP 502 into an overview of the thinking that led to PEP 498?
Or maybe I wasn't clear enough that that's what I was encouraging. :-)

On Tue, Sep 8, 2015 at 11:21 AM, Mike Miller <python-id...@mgmiller.net
<mailto:python-id...@mgmiller.net>> wrote:

Ok, I thought that's what you and others were asking for in previous 
threads.

-Mike



On 09/08/2015 10:32 AM, Guido van Rossum wrote:

Sounds awfully premature. Style guides are typically updated in response
to the


___
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 498: Literal String Interpolation is ready for pronouncement

[Mike Miller]

Yeah, can't wait to use it!

-Mike


On 09/08/2015 05:37 PM, Eric V. Smith wrote:

On 9/8/2015 8:27 PM, Guido van Rossum wrote:

I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who
contributed. A lot of thought and discussion went into this -- Eric
himself was against the idea when it first came up!


Thanks, Guido. In the next few days I'll update the implementation in
issue 24965 to reflect some changes in the PEP.

Thanks to Mike, Nick, Guido, and everyone else who helped improve the PEP.

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

[Python-Dev] String Interpolation Best Practices

[Mike Miller]

Hi,

I'd like to collect thinking on best practices that we can use as a style guide 
for string interpolation.  Now that arbitrary expressions are very likely to be 
included, it is more important to set guidelines than it would otherwise be.


Below is a recent post with some good ideas (though it hopes to restrict 
expressions, which is not what we're discussing here, but rather creation of a 
style-guide for code-review a la PEP8).


Would anyone else like to contribute?

-Mike

Recent posts:

- On PEPs to augment PEP8:

https://mail.python.org/pipermail/python-dev/2015-September/141473.html

- On things to avoid in f-strings:

https://mail.python.org/pipermail/python-dev/2015-September/141451.html
(part included below)


On 09/05/2015 02:10 AM, haypo s (Victor Stinner) wrote:
> Would it be possible to specify a subset of the Python language
> allowed in f-string? For example, __import__ or lambda should not be
> used in a f-string. I'm not convinced that a loop or
> list/dict/set-comprehension is a good idea neither.
>
> I would prefer to keep as much code as possible *outside* f-string because:
> - text editor knows well how to color it
> - static analyzers know how to analyze it
> - it encourage developers to indent and comment their code correctly,
> whereas f-string has more restrictons on indentation (is it possible
> to indent and comment code inside a f-string?)
>
> For example, for me it's a common practice to write a complex
> list-comprehension on two lines for readability:
>
> newlist = [very_complex_expression(item)
>  for item in oldlist]
> # sorry, it's hard to indent correctly in a mail client, especially Gmail
>
> Well, I'm not convinced that we need a larger subset than what is
> allowed currently in str.format(), simple expressions like: obj.attr,
> obj[index], etc.
>
> I recall horrible examples in the previous mail threads showing how
> much complex code you can put inside f-string.
>
> Even the following example from the PEP seems too complex to me:
> print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in
> valid_opts)}]", file=sys.stderr)
>
> Oh, first I read [...] as a list-comprehension :-p But it's part of
> the output string, not of the Python code...
>
> I prefer to build the second parameter outside the f-string:
> opts = '|'.join('--'+opt for opt in valid_opts)
> print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)
>
___
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 498: Literal String Interpolation is ready for pronouncement

[Mike Miller]

And thanks for making it a reality.  ;)

-Mike

On 09/08/2015 05:37 PM, Eric V. Smith wrote:
___
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] Critique of PEP 502 (String Interpolation Redux)

[Mike Miller]

That could be helpful and done without too much work, adding in the best 
practices and PEP8 guidelines that have been asked for in other threads.


Are people interested in a "rationale and best practices" for string 
interpolation pep?


-Mike


On 09/04/2015 08:15 PM, Guido van Rossum wrote:

The text of the PEP has too much on motivation and rationale: maybe that would
be suitable for an informative PEP.

___
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] Critique of PEP 502 (String Interpolation Redux)

[Mike Miller]

On 09/04/2015 08:15 PM, Guido van Rossum wrote:

The text of the PEP has too much on motivation and rationale: maybe that would
be suitable for an informative PEP.  The proposal itself is under-specified.
But the real weakness cannot be fixed by improving the text: it is in the key…


I'm planning on writing an improved version, but haven't the time to get to it 
this past week; huge project at work.  (Though it may not matter at this point 
as the last sentence indicates.)


Since another thread on the list just started about whether to allow arbitrary 
expressions, I think it is important to have a good explanation of that for 
those that might disagree at first, a place to send them.  That was easier for 
me to write than making interpreter improvements, which explains the current 
state of PEP 502 well... fair enough.



This is initially likable: to recipients who don't know about e-strings they
behave just like regular strings; but recipients who *do* know about them can
extract the template and the values to be interpolated and use these to build an
alternative string, e.g. to be used as a translation.

However, in order to fulfill the former requirement, the type must inherit from
str (it's one of those built-in types for which duck typing doesn't always
work). And at the same time this is a real problem, because it's too easy to..


Yes, was aiming to "split the difference" and produce a helpful object that 
could alleviate various concerns.  The design is somewhat successful at that. 
However, while we could mitigate "losing the object" with docs and 
magic-methods, the end-result is still less compelling than I had hoped.  The 
exercise was helpful in that regard.


There is something quite nice about the simplicity of PEP 498 for the developer. 
 It can also be explained to critics as just "syntactic sugar over existing 
str.format," which is compelling.  Though, can we do any cherry picking from 
these PEPs?


While the 498 implementation is great, I'd argue that the 502 expression-string 
nomenclature is a bit better.  The terminology is not heavily used for strings 
in the stdlib (as format and template are), the e/expression name highlights the 
difference in capability, and in conversations doesn't remind one of the f-word, 
haha.


-Mike
___
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-498: Literal String Formatting

[Mike Miller]

On 08/11/2015 06:47 AM, Eric V. Smith wrote:

2. Let's call them format strings not f-strings.
The latter sounds slightly obnoxious, and also inconsistent with the
others:

 r'' raw string
 u'' unicode object (string)
 f'' format string


People seem to have already started using f-strings. I think it's
inevitable.


Sure, there's no way to ban it, that would be silly.  But, I think the 
documentation should not use it.


We don't normally say r-strings or u-strings when talking about them, it's 
not very accurate.  The letter they use isn't their important quality.


Also, avoiding the f- takes the spotlight off the part where f stands for words 
besides format.  ;)


-Mike
___
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-498: Literal String Formatting

[Mike Miller]

Here are my notes on PEP 498.

1. Title:  Literal String Formatting

- String Literal Formatting
- Format String Expressions
?

2. Let's call them format strings not f-strings.
   The latter sounds slightly obnoxious, and also inconsistent with the
   others:

r'' raw string
u'' unicode object (string)
f'' format string

3.  This PEP does not propose to remove or deprecate any of the existing
string formatting mechanisms. 

Should we put this farther up with the section talking about them,
it seems out of place where it is.

4. The existing ways of formatting are either error prone, inflexible, or
cumbersome.

I would tone this down a bit, they're not so bad, quite verbose is a
phrase I might use instead.

5. Discussion Section
How to designate f-strings, and how specify the locaton of expressions
^ typo

6. Perhaps mention string literal functionality, like triple quotes, line-ending 
backslashes, as MRAB mentions, in addition to the concatenation rules.


-Mike


On 08/07/2015 06:39 PM, Eric V. Smith wrote:
___
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] 3.5 release schedule PEP

[Mike Miller]

On 09/24/2014 10:00 PM, Nick Coghlan ncogh...@gmail.com wrote:

Subject: Re: [Python-Dev] 3.5 release schedule PEP

On 24 Sep 2014 15:15, Tim Golden m...@timgolden.me.uk wrote:
 
  On 23/09/2014 18:05, Steve Dower wrote:
  I'm also considering/experimenting with installing into Program
  Files by default, but I suspect that isn't going to work out yet.
 
  I'd like to see that go forward: I think it's increasingly difficult to
justify Python's position at c:\pythonxx. But it does run the risk of
  breaking All The Things.

It might be better to offer that as a supported option in 3.5, and then make it
the default in 3.6.

That will offer a couple of years to work out the issues, rather than a few 
months.


Hi all,

ProgramFiles was the default in Python 1.X.

It has been a supported option for just shy of 15 years on 2.X...  most if not 
all the bugs (setuptools) were fixed a decade ago, and right now thousands, if 
not millions of people are running it under Program Files right now.  I can 
vouch for several thousand because a company I work for distributes Python and 
pip there for its customers all around the world w/o issue.


I've never once encountered a bug due to install to ProgramFiles, or heard of 
anyone who has, and have been using Python for everything since the year 2000. 
If any rare bugs happen to surface, they can likely be fixed or replaced with a 
line of code, or worked around by installing elsewhere.


The potential existence of such bugs isn't enough reason to stay stuck in 1990 
while leaving users vulnerable to tampering attacks for another few years.


-Mike
___
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] 3.5 release schedule PEP

[Mike Miller]

On 09/25/2014 08:50 AM, Steve Dower wrote:

Unfortunately not. The easy way is for the executable to declare that it 
needs administrative privileges, and then the OS will take over and let you 
approve/reject/sign-in/etc. according to your settings.


There is the runas command, though it could be easier to use.  There is also a 
third-part sudo clone.



I don't believe this is the right solution anyway, as very many Windows users 
won't be able to do this (particularly in IT managed environments). Having 'pip 
install' do a per-user install automatically is something that will actually 
work, at the cost/benefit of not affecting other users.


Shoul mention this won't take any choices away from users, such as IT managed 
environs, they could still install wherever they need to.


I understand pip is not actually bundled with Python, just an installer script. 
 That means it is decoupled from changes in the Python installer.  Pypa can 
have pip default to, or fall back to --user later if it decides it is a good idea.


-Mike


___
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] 3.5 release schedule PEP

[Mike Miller]

Paul Moore wrote:

One thing that I presume would be an issue. Isn't Program Files protected in
newer versions of Windows?


Yes, that's the feature that protects from malicious users/code editing import 
os to run format c:\, spam your address book, or look for credit card 
numbers, etc.


It is the same on Mac and other Unix systems, even Windows since Vista came out, 
almost 10 years ago.




This is my main concern. Until pip install --user is the default
(or the fallback if there are no write permissions on the destination),

real-life experience, certainly. But I would suggest carefully checking before
making the switch.


Windows users know how to elevate now, especially developer types.

It should be billed as a feature for your protection not something to be 
feared.  Microsoft decided security was worth the pain of changing over its 
billions of users.  Why not Python?


In my experience pip --user works just fine also.  We use it on our unmanned 
media players successfully.


We also write Windows services, which run under a system account, where it is 
imperative everything is running from a secure file system.



A good reason to decide early on a change like this,

 or at least to promote it as an option in 3.5 and make it the default in 3.6.

It's already an option!  It always has been -- Custom install.  I can't 
remember a time when it didn't work perfectly.


-Mike
___
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] 3.5 release schedule PEP

[Mike Miller]

On 09/25/2014 08:43 AM, Donald Stufft wrote:


One thing about *nix is even though you can’t write to your normal Python
install location without root, invoking pip with permissions (assuming you have
them) is as easy as prefacing it with ``sudo`` in most cases. Does Windows have
an equivalent or do you need to launch a whole new shell?


There is the runas command, though it is a tad harder to use.  There is a 
third-party windows sudo command also that works as you'd expect.


-Mike
___
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] 3.5 release schedule PEP

[Mike Miller]

Yes, we enable the compile script.

As we require admin rights to install Python and system (not user) modules with 
pip, the stdlib .pycs do get created under ProgramFiles at install time.


There might well be a situation where a system pipped module doesn't get 
compiled, but to be honest the difference is negligible on modern machines, 
those needed to run a supported Windows.


I suppose this issue could be improved in the future by caching unwritable 
system .pyc in a user folder, however it feels like a micro-optimization that 
shouldn't hold up the change.


-Mike


On 09/25/2014 09:29 AM, Steve Dower wrote:

As a slight aside, do you enable the option to compile PYC/PYO files on 
install? Unless your users are running as admin, you won't get caching on these 
for the stdlib when it's installed into Program Files.

Cheers,
Steve


-Mike

___
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 2.7.7. on Windows

[Mike Miller]

On 04/29/2014 03:07 PM, Stephen J. Turnbull wrote:
 I have no objection *at all* to making the change in the next feature
 release.  I think the good citizenship argument is more than
 sufficient, ...
 I'm questioning whether it is a sufficient reason to make a backwards-
 incompatible change in a bugfix release.

Normally I would completely agree.

However, this bug has been shitcanned for a decade.  This is the last chance to 
fix this bug in a branch that's going to be supported until 2020!  An unknown 
portion of Python 2.x users will never upgrade to 3.


Do we continue on this path in good conscience for at least six more years?

-Mike
___
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 2.7.7. on Windows

[Mike Miller]

Hi,

Every change has pluses and minuses.  I can't guarantee 100% benefits, only 
trying to make the case that the benefits here outweigh them.


Since we are talking about humans, I'd gather most of them trying to install 
something on Windows will have heard about ProgramFiles and not be too bothered 
at its inclusion in the path.


-Mike

On 04/29/2014 06:31 PM, anatoly techtonik wrote:

You don't take into account many tutorials and internal docs that make the
job of new users easier by using this default. Human processes will be
broken, newbies will suffer.


___
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 2.7.7. on Windows

[Mike Miller]

Hi,

Stepping back a bit...

I doubt you'd take the idea this far, but that Python should need assembly by 
professionals before use doesn't match its Batteries Included spirit, nor the 
PC revolution for that matter.


The reason I brought up the subject at 2.7.7 is because there are greater 
changes than normal in this release, and people are expecting security fixes.

This is realistically the last chance to fix this vulnerability in 2.X.

We should help people do the right thing and be safe, while keeping the 
possibility to customize.


Yes, I can imagine a few people in the world unhappy with any change, but a 
large majority of millions will not notice and reap the benefits.  There are 
also quite a few people unhappy the change hasn't been made (see the bug).


However, those that want a less safe setting on brand new installs may still 
change it manually, script it with the command-line parameter, or could stay 
with 2.7.6 until they do.  The porting effort is tiny and would effect few 
compared to those who'd benefit.


-Mike

p.s. I'm available to help with maintaining the 2.7 installer, unfortunately 
I've only used Inno so not sure how long it would take me to ramp up.



On 04/29/2014 12:04 PM, Steve Dower wrote:
___
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 2.7.7. on Windows

[Mike Miller]

On 04/30/2014 04:14 AM, Steve Dower wrote:

Here are some more minuses beyond those listed on the issue:


I have to say I'm a bit baffled.  I expected disagreement, but didn't expect 
that multiple reasons against would be made up seemingly at random?  I and a 
company I work for (that distributes Py) have been installing Python to 
ProgramFiles for almost a decade, and can assure that none of those things you 
mention have yet happened.


Also, your security point contradicts industry best practice.  Mac and Linux 
require sudo to install system packages, with user packages and venv as 
alternatives.



My basic argument is not that you are wrong, but that it is too late to change.


That's a fine argument.

The problem is that we and others like us are not able to move to Py3 (for work) 
and won't be able to for a long-enough time that it could be considered to be 
never.


-Mike
___
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 2.7.7. on Windows

[Mike Miller]

On 04/30/2014 04:14 AM, Steve Dower wrote:

Since we are talking about humans, I'd gather most of them trying to install
something on Windows will have heard about ProgramFiles and not be too bothered
at its inclusion in the path.


Modifying PATH is not recommended by Microsoft...


Sorry, I meant the install path in that sentence, not the environment var.

-Mike

___
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 2.7.7. on Windows

[Mike Miller]

Greetings,

I've just woken up and noticed Python 2.7.7 is on track to be released, and in a 
rather unique event contains a few security enhancements

in addition to the usual fixes:

http://legacy.python.org/dev/peps/pep-0466/

I thought this might be a good time to make a final plea to fix a
long-standing security issue in the installer on Windows.  By default it
installs Python to the root folder, thereby bypassing filesystem permissions:

http://bugs.python.org/issue1284316

The main rationale given (for not using the standard %ProgramFiles%) has been 
that the full path to python is too long to type, and ease of use is more 
important than the security benefits given by following Windows conventions.


However, adding python to the PATH variable is an alternative solution that
would result in even fewer keystrokes needing to be typed at a console, while
maintaining system security.

As this is an installer setting and not a code change, I gather that the
opportunities for code breakage should be fewer.  Please consider updating
this setting to a more secure and friendly default, for 2.7.7 and 3.5+ as well.

-Mike

___
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 2.7.7. on Windows

[Mike Miller]

On 04/29/2014 05:12 AM, Steve Dower wrote:

This would be an incredibly painful change that would surprise and hurt a lot of
people.


Hi, I think incredibly painful is overstating the case a bit. ;)  We're 
talking about an installer default, a setting that would still be changeable as 
it always has, that by definition only will affect brand new installs.



Yes, it is possible for a non-admin user to install arbitrary packages into a
place where an admin user may inadvertently run it, thereby providing escalation
of privilege. On the other hand, that applies to a lot of development tools,
especially since most users on Windows these days are actually limited
administrators - ANYTHING they install could run when they elevate a certain
process.


None of Microsoft's Dev tools install to C:\, rather to ProgramFiles.  The fact 
that another security issue may exist is not a good justification for creating 
additional.



On the other hand, Python from python.org is a tool that should only be
installed by those who are prepared to manage it. On Windows it is easy enough
to have a second, secured copy for your admin scripts and an unsecured copy for
non-admin tasks.


This sounds like the perspective of someone highly technical, forgetting that 
new users will be installing python as well and vastly outnumber us.  Normal 
people need help to avoid security issues.


Microsoft's guidelines on where to install software are clear, and don't make 
exceptions that tools should be installed to the root of the drive to bypass 
file system permissions, for convenience.



I'm not sure what change you are proposing here... doesn't the installer already
have an option to add to PATH? I'm sure I keep disabling it.


No, it does not.  Unless it got slipped in when I wasn't looking.

It should be an option though, I think everyone would agree.


python.exe on my PATH because I have 10+ versions installed at any one time. I


Remember, python-dev's are not the target users of this package, and are a 
rather minuscule fraction of the user base.



Python installation. At this point, 2.7.6-2.7.7 should be an incredibly safe
upgrade, and there's no way to safely change the default installation location


This would continue to be the case, as the installer will recognize the 
previously installed Python 2.7 and use its setting.  This should affect only 
*brand new installs.*



or the ACLs on the install directory.


No ACLs would be affected or changed or even thought about.  Simply installing 
to the correct folder (on new installs) will accomplish the goal.


In short, this design of restricted permissions (read-only) for binaries and 
PATH conveniences goes back decades under Unix and other OS's.  MS Windows has 
finally caught up in the security department in the last few releases.  Please 
don't keep us back in the bad old days of DOS where everything was installed 
to the root folder.


--
-Mike

___
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 2.7.7. on Windows

[Mike Miller]

Hi,

Those bugs were fixed 9 years ago or so around 2005. I use python in 
ProgramFiles every day without issue.  If another bug has crept in somewhere, it 
can be fixed.


-Mike



--
From: Sturla Molden sturla.mol...@gmail.com
To: python-dev@python.org
Subject: Re: [Python-Dev] Python 2.7.7. on Windows
Message-ID:
771463774420395726.352685sturla.molden-gmail@news.gmane.org

C:\Program Files\Python27 contains an empty space in the path. If you
want to randomly break build tools for C extensions, then go ahead and
change it.

Sturla

___
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-Dev Digest, Vol 129, Issue 81

[Mike Miller]

Hi, note the pep, it makes allowances for security enhancements.

-Mike

 Message: 5 Date: Mon, 28 Apr 2014 20:23:12 +0200
 From: Antoine Pitrou solip...@pitrou.net
 To: python-dev@python.org Subject:
 Re: [Python-Dev] Python 2.7.7. on Windows
 Message-ID: 20140428202312.6903d62a@fsol

 Regardless of whether this change this or not, we certainly cannot
 change it in a bugfix version. So, 3.5 at the earliest it would be.

 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] Python 2.7.7. on Windows

[Mike Miller]

On 04/29/2014 08:38 AM, Brian Curtin wrote:

The option to add the current install to your path was added 3.3.


Ok, thanks.  So there is some precedent it would be useful.


Remember, python-dev's are not the target users of this package, and are a
rather minuscule fraction of the user base.


Knowing which Python you want on your path and that you want it on
your path at all is somewhat of an advanced usage.

 ...

They can do
whatever they want to do within that context without modifying their
entire system. If they learn that they later want their system-wide
path manipulated...


Installing python at all is a system-wide change.  Why not default to a known 
safe, ready to use configuration, rather than a tool-box that needs assembly?



* watch Dave Beazley's PyCon 2014 talk for a good story involving one
of those manufacturer installed Pythons:
https://www.youtube.com/watch?v=RZ4Sn-Y7AP8


Thanks, I'm trying to get thru all the talk will watch that shortly. ;)

Still, edge cases regarding manufactures should not override the needs of the 
majority of users.


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