[Python-Dev] Re: The current state of typing PEPs
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?
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?
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
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
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
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?
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?
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
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
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&R 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
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 𝑣 → 𝑒
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
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
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
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
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
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
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
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
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
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
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"
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"
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"
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"
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"
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)
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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 mailto:me...@gnosis.cx>> 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
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?
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?
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
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
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
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
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
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
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
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
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
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
(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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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: Literal String Interpolation is ready for pronouncement
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] PEP 498: Literal String Interpolation is ready for pronouncement
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
Re: [Python-Dev] String Interpolation Best Practices
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 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] String Interpolation Best Practices
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
[Python-Dev] String Interpolation Best Practices
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: Naming
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] Critique of PEP 502 (String Interpolation Redux)
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)
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
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
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
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] 3.5 release schedule PEP
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
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
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
On 09/24/2014 10:00 PM, Nick Coghlan wrote: Subject: Re: [Python-Dev] 3.5 release schedule PEP On 24 Sep 2014 15:15, "Tim Golden" 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] Python 2.7.7. on Windows
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
Re: [Python-Dev] Python 2.7.7. on Windows
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
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
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
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
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
Re: [Python-Dev] Python-Dev Digest, Vol 129, Issue 81
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 > 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
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 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 2.7.7. on Windows
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
[Python-Dev] Python 2.7.7. on Windows
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