Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
Greg Ewing writes: > Actually, I'm closer to -1 on (a) as well. I don't like := as a > way of getting assignment in an expression. The only thing I would > give a non-negative rating is some form of "where" or "given". +1 to this; ‘:=’ doesn't convey the meaning well. Python's syntax typically eschews cryptic punctuation in faviour of existing words that convey an appropriate meaning, and I agree with Greg that would be a better way to get this effect. -- \ “Self-respect: The secure feeling that no one, as yet, is | `\suspicious.” —Henry L. Mencken | _o__) | Ben Finney ___ Python-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] Microsoft to acquire GitHub for $7.5 billion
Ethan Furman writes: > On 06/04/2018 10:49 AM, Mariatta Wijaya wrote: > > > I think we shouldn't be speculating or making guesses. > > We should have contingency plans and be prepared. More than one > bought-out competitor has simply disappeared, or been hamstrung in its > effectiveness. Yes. So, because such contingency plans take quite some time to prepare, now *is* the time to be talking about it. -- \ “There's a certain part of the contented majority who love | `\anybody who is worth a billion dollars.” —John Kenneth | _o__) Galbraith, 1992-05-23 | Ben Finney ___ Python-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] What is the rationale behind source only releases?
"Alex Walters" writes: > I'd like to know the rationale behind source only releases of cpython. Software freedom entails the freedom to modify and build the software. For that, one needs the source form of the software. Portable software should be feasible to build from source, on a platform where no builds (of that particular release) were done before. For that, one needs the source form of the software. > I have an opinion on their utility and perhaps an idea about changing > them, but I'd like to know why they are done The above rationales seem sufficient to me. Are you looking for additional ones? > (as opposed to source+binary releases or no release at all) I don't see a good justification for adding “source+binary” releases to the existing ones. We already have a source release (once), anda separate binary (one per platform). Why bother *also* making a source+binary release — presumably an additional one per platform? As for “no release at all”, it seems that those who want that can download it very quickly now :-) > before I head over to python-ideas. Is this documented somewhere where > my google-fu can't find it? I am not clear on why this would need specific documentation for Python; these are not issues that are different from any other software where the recipients have software freedom in the work. I hope these answers are useful. -- \ “My business is to teach my aspirations to conform themselves | `\ to fact, not to try and make facts harmonise with my | _o__) aspirations.“ —Thomas Henry Huxley, 1860-09-23 | Ben Finney ___ Python-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] Slow down...
Serhiy Storchaka writes: > 09.05.18 07:25, Steven D'Aprano пише: > > If we could look forward to 2028, when we're running Python 3.14 or so > > (4.7 if you prefer), how many fantastic language features that we cannot > > bear to give up would we be missing out on? > > Like tab-delimited tables. Cheeky :-) (For those who are not closely following comp.lang.python, I am pretty sure Serhiy is wryly referring to an ongoing thread in that forum. Someone is arguing that Python should grow a U+0009-delimited syntax for tabular data, and quickly demonstrated a lack of interest in the familir reasons why this is a bad idea. The thread is already past the point of calm discussion, so I am not linking to it because it's not worth wading into.) -- \ “I wish I had a dollar for every time I spent a dollar, because | `\ then, yahoo!, I'd have all my money back.” —Jack Handey | _o__) | Ben Finney ___ Python-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 394 update proposal: Allow changing the `python` command in some cases
Ben Finney writes: > Petr Viktorin writes: > > > […] we feel that the only way to *enforce* that guidelines is to > > provide environments where the `python` command does not work > > (unless explicitly installed). > > Yes. The ‘python’ command is confusing, for the reasons you say. There > should be ‘python2’ and ‘python3’ commands for Python 2 and Python 3 > respectively, and no ‘python’ command should be installed by the > operating system. > > The fact that ‘/usr/bin/python’ exists is an historical accident, and I > agree with the proposal you state: the best way to correct the confusion > is to bar the confusing command from being installed by packages. Because the above is ambiguous, I'll clarify: I am not calling for, and PEP 394 does not call for, the banishment of the ‘python’ command. What I'm saying is that muddying the rules further on what ‘python’ may or may not mean is *worse than* banishing the ‘python’ command entirely. So, short of banishing ‘python’ entirely, I think PEP 394 is already a good clear way to address the issue. Existing, documented and supported means to locally modify a ‘python’ command already exist and should be sufficient. > I trust that PEP 394 will not be weakened in its effect, and I wish you > well with using the already-supported, already-documented, PEP-394 > compatible means to add local customisations for a ‘python’ command. -- \ “Try to learn something about everything and everything about | `\ something.” —Thomas Henry Huxley | _o__) | Ben Finney ___ Python-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 394 update proposal: Allow changing the `python` command in some cases
Petr Viktorin writes: > In Fedora, I found that PEP 394's strict recommendation that `python` > points to `python2` is holding us back. I have read the message, but I don't see how you draw the link that PEP 394 is holding you back. > The problems are: > - For developers that are not following the language's development, > the fact that `python` invokes `python2` sends a strong signal that 2 > is somehow the preferred version, and it's OK to start new projects in > it. I agree with the statement you make later in the message: > […] we feel that the only way to *enforce* that guidelines is to > provide environments where the `python` command does not work (unless > explicitly installed). Yes. The ‘python’ command is confusing, for the reasons you say. There should be ‘python2’ and ‘python3’ commands for Python 2 and Python 3 respectively, and no ‘python’ command should be installed by the operating system. The fact that ‘/usr/bin/python’ exists is an historical accident, and I agree with the proposal you state: the best way to correct the confusion is to bar the confusing command from being installed by packages. > - Users and sysadmins that *do* want to “live in the future” are > switching the symlink to `python3` themselves. We would like to give > them a supported, documented way to do so -- and make surer they're > aware of the caveats. The supported, documented way to add a command pointing to a different command already exists, and there is no need to make a Python-specific special case. Users who want to make a ‘python’ alias can do so in their shell; this is supported and documented. Users who want to add a new command file can add a suitable directory (e.g. ‘$HOME/bin’) to their ‘PATH’ variable, and put a symlink in there named ‘python’. This is supported and documented. Sysadmins who want to create a system-wide command ‘python’ can put a symlink at ‘/usr/local/bin/python’. This is supported and documented. I disagree with making some special-case extra way; that would be both cunfusing and superfluous. > - The `python` command is still not available out-of-the box on macOS, > so it didn't completely live up to the expectation of being the > cross-platform way to launch 2/3 source compatile scripts. That is one of the minor ways which macOS fails to conform to community-agreed conventions. We should not let that intransigence distort our discussion of best practices. > To help solve these, I would like to relax recommendations on the Unix > ``python -> python2`` symlink in these cases: For the above reasons, I disagree that PEP 394 is limiting what you want to do on free-software operating systems. For non-free operating systems, I don't think the already-discussed PEP 394 should be weakened if the operating system vendor fails to conform. > - Users and administrators can, by a deliberate action, change > ``python`` to invoke Python 3. Yes. That is well-known and long-standardised on Unix operating systems, and is much more broadly understood than any Python-specific special case would be. So I don't see how anyone is being held back. I trust that PEP 394 will not be weakened in its effect, and I wish you well with using the already-supported, already-documented, PEP-394 compatible means to add local customisations for a ‘python’ command. -- \ “Pity the meek, for they shall inherit the earth.” —Donald | `\ Robert Perry Marquis | _o__) | Ben Finney ___ Python-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] Round 2 of the Python Language Summit coverage at LWN
Jake Edge writes: > The second batch of articles from the Python Language Summit is now > available. Thank you for writing these (and many other good articles) for Linux Weekly News! High-quality, dependable reporting is very valuable for our community. -- \ “To punish me for my contempt of authority, Fate has made me an | `\ authority myself.” —Albert Einstein, 1930-09-18 | _o__) | Ben Finney ___ Python-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] Mailing list metadata via RFC 2369 (was: Terminal console)
"Franklin? Lee" writes: > FWIW, Gmail's policies require: > """ > A user must be able to unsubscribe from your mailing list through > one of the following means: > > * A prominent link in the body of an email leading users to a page > confirming his or her unsubscription (no input from the user, other > than confirmation, should be required). > * By replying to your email with an unsubscribe request. > """ > (https://support.google.com/mail/answer/81126) GMail already has all the information needed to offer mailing list functionality to every user. The header of every message delivered via the mailing list has full RFC 2369 fields https://tools.ietf.org/html/rfc2369> which is ample information, correctly structured for any application to provide the functions GMail is referring to. GMail support staff have known this for many years because RFC 2369 support has been requested for their interface over and over again. There are reports they even make some use of that standard information http://www.itworld.com/article/2693280/unified-communications/gmail-s--unsubscribe--tool-comes-out-of-the-weeds.html> though as I never use GMail I can't verify that. If not, then their refusal to follow a mature, well-implemented internet standard is no reason for anyone else to change behaviour. It is up to GMail to use the standard information. -- \ “Anything that we scientists can do to weaken the hold of | `\religion should be done and may in the end be our greatest | _o__) contribution to civilization.” —Steven Weinberg | Ben Finney ___ Python-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] Maybe, just maybe, pathlib doesn't belong.
Alexander Walters writes: > That is great news. I just couldn't see it myself in the threads Agreed. A summary posting, from someone who has a good handle on the issue and outcome, would be very helpful. -- \ “Firmness in decision is often merely a form of stupidity. It | `\indicates an inability to think the same thing out twice.” | _o__)—Henry L. Mencken | Ben Finney ___ Python-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] What does a double coding cookie mean?
Guido van Rossum writes: > I agree that the spirit of the PEP is to stop at the first coding > cookie found. Would it be okay if I updated the PEP to clarify this? > I'll definitely also update the docs. +1, it never occurred to me that the specification could mean otherwise. On reflection I can't see a good reason for it to mean otherwise. -- \ “Alternative explanations are always welcome in science, if | `\ they are better and explain more. Alternative explanations that | _o__) explain nothing are not welcome.” —Victor J. Stenger, 2001-11-05 | Ben Finney ___ Python-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] Thank you.
Alexander Walters writes: > I don't know if it is appropriate for this list, or not. I don't > exactly care. As much as I might disagree with some of you... If you intend to address the Python core developers, this is an appropriate forum in which to express thanks. > Thank you. > Your work on Python has made a notable difference in how happy my life is. Agreed. This community has robust disagreements that nevertheless remain civil and respectful. The ongoing development of Python makes my life, and the lives of many people whom I care about, significantly better. Thank you all. -- \ “Only the shallow know themselves.” —Oscar Wilde, _Phrases and | `\ Philosophies for the Use of the Young_, 1894 | _o__) | Ben Finney ___ Python-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] just a friendly developer
ty armour writes: > I am looking for tutorials on basically how to write the python > language. Newcomers to Python are especially invited to the Python ‘tutor’ forum https://mail.python.org/mailman/listinfo/tutor>, for collaborative tutoring in a friendly environment. -- \ “The internet's completely over.… Anyway, all these computers | `\and digital gadgets are no good. They just fill your head with | _o__) numbers and that can't be good for you.” —Prince, 2010-07-05 | Ben Finney ___ Python-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] Code formatter bot
Andrew Barnert via Python-Dev writes: > […] it can be helpful to have both suggested editor plugins that do > the auto formatting on the dev's computer, and VCS-triggered checkers > that ensure the formatting was correct. Right, I was not intending the different stages to be exclusive. I was seeking clarification from the OP on the intended stages proposed to be automated. It's also worth noting that neither of the above approaches you mention would qualify IMO to be termed a “bot”, since they still leave it to the human operator to deal with formatting violations before the edits reach the VCS. But that's another clarification I'm seeking from the OP: what “bot” is being proposed? -- \ “Nothing is more sacred than the facts.” —Sam Harris, _The End | `\ of Faith_, 2004 | _o__) | Ben Finney ___ Python-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] Code formatter bot
francismb writes: > what's your opinion about a code-formatter bot for cpython. What is the proposal? The opinions will surely depend on: * What formatting is to be applied automatically? * If you propose to enforce rigid interpretations of the style-guide PEPs as automatic rules, that will incur the wrath of those who have made clear those PEPs are not to be used that way. There is a clear opinion (from at least the BDFL) that the style guide PEPs are guidelines to be applied with human judgement. * If on the other hand you propose to enforce only those rules which are strict enough to be applied automatically (e.g. “don't mix spaces and TABs”, “encode source using UTF-8 only”) then that's best done by editor plug-ins like EditorConfig[0]. * At which point in the workflow will the formatting be applied? * If you propose to change the code *after* the programmer sees it in their text editor, that is sure to be unpopular. The code committed to VCS should exactly match what the programmer sees when they choose to commit. * If you propose to reject the code at time of committing, there are VCS hooks that can do that; I don't know what different system you propose. * If you propose to present formatting violations as errors in the programmer's text editor so they can be corrected before using the VCS, then there are tools like EditorConfig[0] to do that. [0]: EditorConfig http://editorconfig.org/> -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but isn't a cucumber that small called a gherkin?” | _o__) —_Pinky and The Brain_ | Ben Finney ___ Python-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 257 and __init__
Facundo Batista writes: > Note that I'm ok to include a docstring when the actual behaviour > would deviate from the expected one as per Reference Docs. My point is > to not make it mandatory. I disagree with the exception you're making for ‘__init__’. The parameters to that function (and how the function behaves in response) should be documented in the docstring, just as for any other function. > Yeap, but pep257 (the tool [0]) complains for __init__, and wanted to > know how serious was it. Omitting a docstring violates PEP 257, regardless which function we're talking about. So the tool is correct to complain. -- \ “If we don't believe in freedom of expression for people we | `\ despise, we don't believe in it at all.” —Noam Chomsky, | _o__) 1992-11-25 | Ben Finney ___ Python-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] Where is defined the grammar of Python?
"Stéphane Wirtel" writes: > I would like to understand this part of Python, could you help me? You should also know the Python Language Reference documentation https://docs.python.org/3/reference/>, especially the Full Grammar specification https://docs.python.org/3/reference/grammar.html>. -- \ “Holy astringent plum-like fruit, Batman!” —Robin | `\ | _o__) | Ben Finney ___ Python-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 8 recommends short module names because FAT is still common today
Guido van Rossum writes: > […] I've removed the offending paragraph from the PEP. Note that it > still recommends short, all-lowercase module and package names -- it > just doesn't use computers to motivate it. That suits me too. I think the justification was valid, but its absence doesn't harm the PEP. -- \ “I busted a mirror and got seven years bad luck, but my lawyer | `\thinks he can get me five.” —Steven Wright | _o__) | Ben Finney ___ Python-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 8 recommends short module names because FAT is still common today (was: PEP-8 wart... it recommends short names because of DOS)
"Gregory P. Smith" writes: > There haven't been computers with less than 80 character file or path > name element length limits in wide use in decades... ;) Not true, your computer will happily mount severely-limited filesystems. Indeed, I'd wager it has done so many times this year. It is *filesystems* that limit the length of filesystem entries, and the FAT filesystem is still in very widespread use — on devices mounted by the computers you use today. Yes, we have much better filesystems today, and your primary desktop computer will almost certainly use something better than FAT for its primary storage's filesystem. That does not mean Python programmers should assume your computer will never mount a FAT filesystem (think small flash storage), nor that a program you run will never need to load Python modules from that filesystem. You'd like FAT to go away forever? Great, me too. Now we need to convince all the vendors of every small storage device – USB thumb drives, network routers, all manner of single-purpose devices – to use modern filesystems instead. Then, maybe after another human generation has come and gone, we can finally expect every filesystem, in every active device that might run any Python code, to be using something with a reasonably-large limit for filesystem entries. Until then, the advice in PEP 8 to keep module names short is reasonable. -- \ “The most common of all follies is to believe passionately in | `\the palpably not true. It is the chief occupation of mankind.” | _o__) —Henry L. Mencken | Ben Finney ___ Python-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] An example of Python 3 promotion attitude
Terry Reedy writes: > There was peripherally mention of a 4-year-document called LPTHW that > recommends 2. I have no idea what they are referring to. It is expanded in passing, but for reference they are talking about “Learn Python the Hard Way” http://learnpythonthehardway.org/>, a book which (reportedly) has not been updated since 2010. -- \ “Liberal capitalism is not at all the Good of humanity. Quite | `\the contrary; it is the vehicle of savage, destructive | _o__) nihilism.” —Alain Badiou | Ben Finney ___ Python-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] Burning down the backlog.
Robert Collins writes: > However - 9 isn't a bad number for 'patches that the triagers think > are ready to commit' inventory. > > So yay!. Also - triagers, thank you for feeding patches through the > process. Please keep it up :) If I were a cheerleader I would be able to lead a rousing “Yay, go team backlog burners!” -- \ “I may disagree with what you say, but I will defend to the | `\death your right to mis-attribute this quote to Voltaire.” | _o__) —Avram Grumer, rec.arts.sf.written, 2000-05-30 | Ben Finney ___ Python-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] How do we tell if we're helping or hindering the core development process?
Paul Moore writes: > On 28 July 2015 at 13:35, Ben Finney wrote: > > People can, do, and probably must make many decisions through > > non-rational processes. I don't propose to change that. > > Good. > > > Choices can be made that, when challenged, lack compelling rational > > justification. I do propose that such a challenge should be taken as a > > healthy desire to improve Python, not a personal attack. > > While that is fine, you appear unwilling to accept the possibility > that people may not have the time/energy to develop a detailed > rational justification for a change that they have made, and demanding > that they do so when they are offering the time they do give on a > volunteer basis, is what I claim is unacceptable. I've said many times now that's not what I'm advocating. I've made a clear distinction between the need to *be able to* justify a change, versus arbitrary demands to do so by arbitrary members. The latter is what you're arguing against, and of course I agree. I've never advocated that. > The issue is not one of your motives in asking for explanations - it's > the implication that you are entitled to require others to *provide* > those explanations, to whatever level of detail *you* require. Hopefully this repetition is enough: I do not claim any such entitlement. > I hope that clarifies my position. Likewise. Thanks for engaging. -- \ “… correct code is great, code that crashes could use | `\ improvement, but incorrect code that doesn’t crash is a | _o__)horrible nightmare.” —Chris Smith, 2008-08-22 | Ben Finney ___ Python-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] How do we tell if we're helping or hindering the core development process?
Paul Moore writes: > But isn't the whole *point* of a non-rational decision (as you > describe it) that you *can't* articulate your reasons for making that > decision. You've conflated the process used to make a decision, with the justifications that support that decision. Those are separate. When I decide to avoid travelling a particular route to work one day, my decision could very likely be made non-rationally. Yet when challenged to say why it's a good choice, the non-rational processes I used to make the decision would rightly be dismissed. I can either present rationally compelling justification for choosing the route I used, or the challenger can rightly dismiss my choice as insufficiently justified. > You can't have your cake and eat it - are core devs allowed to make > "non-rational" judgements or not? All humans, core developers included, can and must continue to make most of our decisions in a non-rational manner. That's not the issue. > (In your view - in mine, they clearly are, and being required to > justify those decisions after the fact is *not* acceptable). I'm unsure what the objection is. The challenge is not to the person to justify themselves; it is to the change made, and what justification there is for it. This distinction is subtle but crucial. What do you imagine is the alternative? That changes which lack rational support should be allowed merely because of the person who made them? People can, do, and probably must make many decisions through non-rational processes. I don't propose to change that. Choices can be made that, when challenged, lack compelling rational justification. I do propose that such a challenge should be taken as a healthy desire to improve Python, not a personal attack. Challenging ideas can be misunderstood as challenging a person's character. That's a mistaken conflation, and I try hard to avoid it; I'd love for all of us to do the same. -- \ “If you don't know what your program is supposed to do, you'd | `\ better not start writing it.” —Edsger W. Dijkstra | _o__) | Ben Finney ___ Python-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] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)
"Stephen J. Turnbull" writes: > […] The "meta" of "special cases aren't special enough to break the > rules" is that no design decision that violates it should be dismissed > as "minor". Thank you. That dismissal was very upsetting; essentially telling Python users that their concerns for a clean API in the standard library aren't worth much to the Python core developers. > In context of a mailing list, doing so is going to be taken by readers > as "I know what I'm doing, and you don't know what you're talking > about, so STFU." That may not have been the intent. It certainly was how it was received by some of us here. > *Both* roles in this comedy of errors are natural, they are inherent > in human cognition (citations on request), and nobody is to be blamed. Since it can't seem to be said enough, I agree with what Stephen's saying here wholeheartedly: the above explications are not intended as blame, but an explanation of why calls to “stop talking about this, it's minor” had precisely the opposite effect. -- \ “Remember: every member of your ‘target audience’ also owns a | `\ broadcasting station. These ‘targets’ can shoot back.” —Michael | _o__) Rathbun to advertisers, news.admin.net-abuse.email | Ben Finney ___ Python-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] How do we tell if we're helping or hindering the core development process?
Robert Collins writes: > On 21 July 2015 at 00:34, Ben Finney wrote: > > Paul Moore writes: > > > >> Again, I'm sorry to pick on one sentence out of context, but it cut > >> straight to my biggest fear when doing a commit (on any project) - > >> what if, after all the worrying and consideration I put into doing > >> this commit, people disagree with me (or worse still, I made a > >> mistake)? Will I be able to justify what I decided? > > > > That seems quite healthy to me. On a collaborative project with > > effects far beyond oneself, yes, any change *should* be able to be > > justified when challenged. > > Depending on what you mean by justification , this leaves no leeway > for hunches, feelings, intuition, or grey area changes. This doesn't address what I've said; or, I've misunderstood what you've said. I'm well aware that *most* of the changes we actually work on and introduce will be based on hunches, feelings, intuition, grey areas, etc. That can't be expected to disappear. Indeed, these non-rational ways of reaching a decision are essential to allow us to act with any kind of speed. Non-rational decision making is much faster, and necessarily will form the great majority of our decision making. Good! What I'm making explicit is: those can't serve as *justification* for introducing a change. When a change is challenged (by someone to whom we are answerable), claiming that it just “felt right” is not enough. I'm not proposing to block every change based on those non-rational impulses. Those impulses reflect our internalised lessons that we've learned from experience. When someone's non-rational decisions prove reliably good *when challenged* by rational third-party interrogation, we correctly trust them to make more such decisions. That's not advocating subjecting a *person* to interrogation, with the connotations of moral judgement. Be clear: I'm talking only about interrogating the rational justification for a code change, separate from judgement of the person. So: we will inevitably make most of our decisions non-rationally, which means, among other things, *faster* than explicitly rational decision making. I don't propose to change that, and our trusted core developers are not expected to be any exception to this human truth. It has to be recognised, though, that there must be some third-party scrutiny, and if no *rational* justification can be presented for a change – whether tha justification is composed ahead of the change, or some time afterward, or even at the time of the challenge – then that change is rather likely to be a poor one. Again, this is *not* a call to subject every, or even most, changes to rigorous scrutiny. That would be an intolerably slow and oppressive environment, which I don't advocate. What I am rejectiong is the idea, expressed several times in this thread, that requesting rational justification for a change can be dismissed out of hand. That's abdicating any accountability, and I was quite concerned to see that attitute expressed. No one need feel accountable to me especially, or any other arbitrary member. Rather, I think it's healthy that core developers feel accountable to the principle that any change *should* be justifiable, when challenged by someone with sufficient authority; and that such an authoritative request is not answered by “it felt right to me”. > It's also a terrible way to treat people that are contributing their > own time and effort: assume good faith is a much better starting > point. Agreed, we should assume good faith. Most decisions will be reached non-rationally, and we have no option but to trust some people to make many non-rational decisions. Simultaneously, when entrusted with such decisions, we must assume that any changes we make which can't be justified *when later challenged* should fall away. What we mustn't assume is that just because we have made good non-rational decisions in the past, the next one we make will also be well-justified. Especially, we should assume that anyone who *asks* for that rational justification is also acting in good faith. -- \ “The only tyrant I accept in this world is the still voice | `\ within.” —Mohandas K. Gandhi | _o__) | Ben Finney ___ Python-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] Devguide - Add Communications Quick Start Section
Carol Willing writes: > The Communications Quick Start section would be brief and practical > much like the Quick Start section for downloading and testing the > source code. +1, thanks for the practical contribution! -- \ “Anyone who puts a small gloss on [a] fundamental technology, | `\ calls it proprietary, and then tries to keep others from | _o__) building on it, is a thief.” —Tim O'Reilly, 2000-01-25 | Ben Finney ___ Python-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] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)
Nick Coghlan writes: > On 20 July 2015 at 22:34, Ben Finney wrote: > > Paul Moore writes: > > > >> […] my biggest fear when doing a commit (on any project) - what if, > >> after all the worrying and consideration I put into doing this > >> commit, people disagree with me (or worse still, I made a mistake)? > >> Will I be able to justify what I decided? > > > > That seems quite healthy to me. On a collaborative project with > > effects far beyond oneself, yes, any change *should* be able to be > > justified when challenged. > > No, that's not how this works: if folks are thinking that being a > Python user, or even a CPython core developer, means that we're > entitled to micromanage core developers by demanding extensive > explanations for any arbitrary commit we choose, they're thoroughly > mistaken. Definitely agreed, and I'm not implying otherwise. There is a distinction to be drawn: * If challenged to do so, could one (the contributor) present a compelling justification for the change? This is what I claim Paul Moore's doubt (fear?) is indicative of. I maintain that this doubt is quite healthy: it helps the contributor to pause, reflect, seek assistance in making decisions, and thereby also tends to exclude poorly-justified changes which would otherwise be committed. * If a participant on this forum feels entitled to challenge a change, must the contributor present an arbitrary quantity of justification of each decision when challenged? This seems to be what many contributors object to, but I don't assert this at all. I never meant to imply that mere participation here entitles a person to demand justification for changes. > Folks are granted core committer privileges because we *trust their > instincts*. We trust them to know when they're acting within the > limits of their own expertise and experience, and we trust them to > know when it would be beneficial to seek feedback from a wider > audience before making up their minds. That's all good, and it's quite compatible with the healthy doubt I described above. > But the authority and responsibility to make changes, to decide what > constitutes a reasonable risk, to decide which updates are appropriate > to send out to tens of millions of Python users worldwide remains > *ours*. No objection from me. I am not asking that contributors be at the mercy of limitless demands for justification from arbitrary participants in this forum. I am asking that contributors should *have* compelling justification for any change they commit, if someone with sufficient authority were to ask for it. That doesn't make contributors any more answerable to arbitrary participants here. It does make explicit that contributors, while trusted of course, are answerable to more than their instincts and what “feels right”: they are answerable also the community of core contributors as a condition of that trust. They are also effectively answerable to their own conscience about what justification that community may ask in future. -- \ “We suffer primarily not from our vices or our weaknesses, but | `\from our illusions.” —Daniel J. Boorstin, historian, 1914–2004 | _o__) | Ben Finney ___ Python-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] How far to go with user-friendliness
Paul Moore writes: > Again, I'm sorry to pick on one sentence out of context, but it cut > straight to my biggest fear when doing a commit (on any project) - > what if, after all the worrying and consideration I put into doing > this commit, people disagree with me (or worse still, I made a > mistake)? Will I be able to justify what I decided? That seems quite healthy to me. On a collaborative project with effects far beyond oneself, yes, any change *should* be able to be justified when challenged. That isn't a mandate to challenge every change, of course. It does mean that every change should be considered in light of “Can I justify this, if challenged?” So what you describe sounds like a healthy barrier: one which works to keep out unjustifiable changes. What is needed is to have both that *and* the support of the community so it's not a barrier to the *contributors*. The contributors should not feel excluded merely because some of their changes might need to be. > Hmm, maybe I'd better hold off and let someone else make the > decision... What of the (obvious, to me) option to retain the authority to make the decision, but take the doubt as a sign that one should consult with others before making the decision? That is, there's no need to feel that one shouldn't make the decision. But perhaps one shouldn't make it solely on one's own experience or insight. Get others involved, even non-committers, and discuss it, and understand the issue better. With that improved basis, then make the decision. Am I naive to think that's desirable for PYthon core committers? -- \ “Ours is a world where people don't know what they want and are | `\ willing to go through hell to get it.” —Donald Robert Perry | _o__) Marquis | Ben Finney ___ Python-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] How far to go with user-friendliness
Nick Coghlan writes: > Sorry, I crossed a line there - I know everyone posting to this thread > is doing so with the best interests of Python at heart. Thanks for saying so, I was mulling a similar post but yours came first. > The *problem* with threads like this one is that they end up feeling > like punishment for being accommodating to the wishes of contributors > on minor design details. From this questioner's perspective, threads like this also end up feeling like an escalating dismissal (“this is just *not important*, and no discussion will be entered into”) of salient user concerns regarding the APIs on the standard library. Neither of those impressions, I'm sure, was intended by any party to this thread. > Potential core developers are also likely to be put off by the > prospect of "you too can volunteer to be micromanaged by a large > community mailing list, doesn't that sound like fun?" Requests for principled justification can be very easily misread as blame. The mere absence of that intention is not enough to quell suspicion; neither is the suspicion of it enough to respond as though that is the intent. We all need to remember that tendency, and take better care in expressing ourselves. For what it's worth: of course I think I speak for everyone here in saying that I greatly appreciate the work of core contributors in implementing CPython and the standard library, and continuing effort to maintain it. Thank you all. -- \“What if the Hokey Pokey IS what it's all about?” —anonymous | `\ | _o__) | Ben Finney ___ Python-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] How far to go with user-friendliness
Nick Coghlan writes: > On 17 July 2015 at 08:30, Ben Finney wrote: > > By definition, advocating to not add cruft to an API is going to be in > > advance of being bitten by those additions. > > That's not what people are doing. Folks are actually arguing for > *restoring* the ability to mock out method names starting with > "assret_*". You're describing a fait accompli. That doesn't justify the changes to get to that fait. I'm pointing out that what you call a situation to be “restored” is what we've got now, and a change away from that – to add a DWIM alias for one typo, seemingly arbitrary among typos – needs sufficient justification. I'm also pointing out that clarity and similicity of API is sufficiently important that there needs to be a strong benefit to justify moving away from that. > I still don't know why anyone thinks restoring that would be a > worthwhile use of a maintainers' time (or why they thinking arguing in > favour of such a capability is a worthwhile use of theirs). Just as easily, I could express surprise that adding DWIM aliases for some typos and not others has somehow been thought worthwhile of the maintainers's time. But in neither case does that argue for or against, so I don't think that's terribly germane to the discussion. > None of the perspectives presented in this thread are new Must they be new? I don't see how that matters. If they haven't been adequately addressed, it shouldn't matter how new they are; they're still salient objections to a change when it is announced. -- \ “In any great organization it is far, far safer to be wrong | `\ with the majority than to be right alone.” —John Kenneth | _o__)Galbraith, 1989-07-28 | Ben Finney ___ Python-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] How far to go with user-friendliness
Antoine Pitrou writes: > On Fri, 17 Jul 2015 06:59:16 +1000 > Ben Finney wrote: > > > > +1. > > > > These checks are a good thing, but they belong in a linter tool not as > > aliases in the API. > > Practicality beats purity. Unless you have been actually *bitten* by > those checks I don't think there's any serious reason to complain. By definition, advocating to not add cruft to an API is going to be in advance of being bitten by those additions. Your position seems to be, then, that any complaint about additions to an API can be dismissed out of hand. I hope that's not what you mean, but I can't see what else you could be saying. -- \ “Of all classes the rich are the most noticed and the least | `\ studied.” —John Kenneth Galbraith, _The Age of Uncertainty_, | _o__) 1977 | Ben Finney ___ Python-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] How far to go with user-friendliness
Ethan Furman writes: > On 07/16/2015 01:29 PM, Michael Foord wrote: > > On Tuesday, 14 July 2015, Christie Wilson wrote: > > >> Unless the line silently executes and they don't notice the mistake for > >> years :'( > > > > Indeed. This has been a problem with mock, misspelled (usually > > misremembered) assert methods silently did nothing. > > > > With this fix in place several failing tests were revealed in code bases! > > This is good. :) It's good that bugs were found. That does not argue for making an alias in the library, though; it better argues for those projects adding a linter check for the common misspellings. > > As for assret, it's the common misspelling people have told me > > about. It seems a ridiculous thing for people to get worked up > > about, but people enjoy getting worked up. Advocating for a clean API is ridiculous? That's a disturbing attitude to hear from a Python standard library contributor. > On the serious side, Python is not a DWIM language, and making > accommodations for a misspelling feels very DWIMish. As I said in an > earlier email part of writing good tests is double-checking that a > test is failing (and for the right reasons). And yes, I am guilty of > writing bad tests, and getting bit by it, and no, I still don't want > the testing framework (or any part of Python) guessing what I meant. +1. These checks are a good thing, but they belong in a linter tool not as aliases in the API. -- \ “You say “Carmina”, and I say “Burana”, You say “Fortuna”, and | `\I say “cantata”, Carmina, Burana, Fortuna, cantata, Let's Carl | _o__)the whole thing Orff.” —anonymous | Ben Finney ___ Python-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] Type hints -- a mediocre programmer's reaction
Chris Angelico writes: > On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich wrote: > > * It is not optional. Please stop saying that. The people promoting > > it would prefer that everyone use it. If it is approved it will be > > optional in the way that PEP8 is optional. If I'm reading your > > annotated code it is certainly /not/ optional that I understand the > > annotations. […] > > Maybe I'm completely misreading everything here […] I think you've misunderstood the complaint. > When you're writing a library, it can be a great help to provide type > annotations, because every application that uses your library can > benefit. When you're writing an application, you can completely ignore > them, but still get the benefit of everyone else's. Jack is not complaining only about *writing* code. He's complaining about the effect this will have on code that we all are expected to *read*. Programmers spend a great deal of time reading code written by other people. The costs of this proposal are only partly on the writers of the code; they are significantly borne by the people *reading* that code. For them, it is not optional. > I have no fears for my own code. Are you afraid for yours? Jack, if I understand correctly, fears for the code that will be written by others in conformance with this proposal, that he will then have to read and understand. -- \ “The opposite of a correct statement is a false statement. But | `\ the opposite of a profound truth may well be another profound | _o__) truth.” —Niels Bohr | Ben Finney ___ Python-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-committers] Do we need to sign Windows files with GnuPG?
Steve Dower writes: > Nathaniel Smith wrote: > > And I suspect python-dev generally doesn't put much weight on the > > extra effort required (release managers have all been using gpg for > > decades, it's pretty trivial) > > I'm aware of this, but still don't see it as a reason to unnecessarily > duplicate process. That's a good argument. But it's one against Authenticode, because that's a single-platform process that duplicates an existing convention to use an open, free standard: OpenPGP certificates. So the demands of “why do we need to duplicate this work?” should be made to Microsoft for choosing to re-invent that long-standing and superior (because open, free-software, and cross-platform) wheel. -- \ “At my lemonade stand I used to give the first glass away free | `\ and charge five dollars for the second glass. The refill | _o__) contained the antidote.” —Emo Philips | Ben Finney ___ Python-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] some minor questions about pep8
Lewis Coates writes: > In pep8 there are two conflicting statements, both > > https://www.python.org/dev/peps/pep-0008/#version-bookkeeping > https://www.python.org/dev/peps/pep-0008/#imports > > Stipulate that they should be "at the top of the file after any module > comments and docstrings." Which of these takes precedence? I don't know an official answer. The convention I've observed is overwhelmingly in one direction: import statements come before any assignment statements. > Secondly, we also have an "__author__", and "__project__" variables, I > assume these would be put with the version information as well? Yes. -- \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht? [What part of | `\‘gestalt’ don't you understand?]” —Karsten M. Self | _o__) | Ben Finney ___ Python-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.x and 3.x use survey, 2014 edition
Alex Gaynor writes: > Ben Finney benfinney.id.au> writes: > > > Rather, the claim is that *if* one's code base doesn't migrate to > > Python 3, it will be decreasingly supported by the PSF and the > > Python community at large. > > The PSF doesn't support any versions of Python. We have effectively no > involvement in the development of Python the language, or CPython. We > certainly don't care what version of Python you use. Okay, I was under the impression that the entity blessing Python releases as “official” is the PSF. What is that entity, then? Whatever entity is the one which makes “this is an official release of Python the language”, and “support for Python version A.B will end on -MM-DD”, that's the entity I meant. -- \ “I went to the museum where they had all the heads and arms | `\ from the statues that are in all the other museums.” —Steven | _o__) Wright | Ben Finney ___ Python-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.x and 3.x use survey, 2014 edition
Mark Roberts writes: > So, I'm the guy that used the "hate" word in relation to writing 2/3 > compliant code. And really, as a library maintainer/writer I do hate > writing 2/3 compatible code. You're unlikely to get disagreement on that. I certainly concur. The catch is, at the moment it's better that any of the alternatives for writing medium-to-long-term maintainable Python code. > The whole situation is made worse because I *KNOW* that Python 3 is a > better language than Python 2, but that it doesn't *MATTER* because > Python 2 is what people are - and will be - using for the foreseeable > future. Only if “people” means “any amount of people at all who are or might be using Python”. While developers might like something that allows them to serve such a broad user base indefinitely, it's simply not realistic – and *no* feasible support strategy for Python could allow that. So, as developers writing Python code, we must set our expectations for support base according to reality rather than wishing it were otherwise. > It's impractical to drop library support for Python 2 when all of your > users use Python 2 Right. The practical thing to do is to decide explicitly, per project, what portion of those users you can afford to leave behind in Python-2-only land, and how much cost you're willing to bear to keep than number low. > I suppose what I'm saying is that there's lots of claims that the > conversion to Python 3 is inevitable, but I'm not convinced about > that. I've never seen such a claim from the PSF. Can you cite any, and are they representative of the PSF's position on the issue? Rather, the claim is that *if* one's code base doesn't migrate to Python 3, it will be decreasingly supported by the PSF and the Python community at large. Happily, what's also true is there is a huge amount of support – in language features, tools, and community will – to help developers do that migration. Much more than most other migrations I've observed. So what's inevitable is: either a code base will benefit from all that support and be migrated to Python 3 and hence be maintainable as the Python ecosystem evolves; or it will be increasingly an outsider of that ecosystem. -- \ “I have one rule to live by: Don't make it worse.” —Hazel | `\ Woodcock | _o__) | Ben Finney ___ Python-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] Making it possible to accept contributions without CLA
Ethan Furman writes: > Well, this is the wrong mailing list for those questions. Thanks. I addressed the claim here where it was made; but you're right that a different forum is better for an ongoing discussion about this topic. Barry Warsaw writes: > My understanding is that the PSF needs the ability to relicense the > contribution under the standard PSF license, and it is the contributor > agreement that gives the PSF the legal right to do this. Okay, that's been raised before. If anyone can cite other specific dependencies that would necessitate a CLA for Python, please contact me off-list, and/or in the Python legal-sig https://mail.python.org/mailman/listinfo/python-legal-sig>. > Many organizations, both for- and non-profit have this legal > requirement, and there are many avenues for satisfying these needs, > mostly based on different legal and business interpretations. And many do not. It would be good to shift the PSF into the larger set of organisations that do not require a CLA for accepting contributions. Thanks, all. Sorry to bring the topic up again here. -- \ “When I was born I was so surprised I couldn't talk for a year | `\and a half.” —Gracie Allen | _o__) | Ben Finney ___ Python-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] Making it possible to accept contributions without CLA (was: My thinking about the development process)
Eric Snow writes: > There's no real way around this, is there? […] the CLA part is pretty > unavoidable. The PSF presently madates that any contributor to Python sign http://legacy.python.org/psf/contrib/contrib-form/contributor-agreement.pdf> the “Contributor Agreement”. This is a unilateral grant from the contributor to the PSF, and is unequal because the PSF does not grant these same powers to the recipients of Python. I raise this, not to start another disagreement about whether this is desirable; I understand that many within the PSF regard it as an unfortunate barrier to entry, even if it is necessary. Rather, I'm asking what, specifically, necessitates this situation. What would need to change, for the PSF to accept contributions to the Python copyrighted works, without requiring the contributor to do anything but license the work under Apache 2.0 license? Is it specific code within the Python code base which somehow creates this need? How much, and how would the PSF view work to re-implement that code for contribution under Apache 2.0 license? Is it some other dependency? What, specifically; and what can be done to remove that dependency? My goal is to see the PSF reach a state where the licensing situation is an equal-footing “inbound = outbound” like most free software projects; where the PSF can happily receive from a contributor only the exact same license the PSF grants to any recipient of Python. For that to happen, we need to know the specific barriers to such a goal. What are they? -- \ “A computer once beat me at chess, but it was no match for me | `\ at kick boxing.” —Emo Philips | _o__) | Ben Finney ___ Python-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 481 - Migrate Some Supporting Repositories to Git and Github
Brett Cannon writes: > Well, if I'm going to be the Great Decider on this then I can say > upfront I'm taking a pragmatic view of preferring open but not > mandating it, preferring hg over git but not ruling out a switch, > preferring Python-based tools but not viewing it as a negative to not > use Python, etc. (and you've later clarified that these will all be factors weighing in favour of a candidate.) Thanks for expressing your thoughts. Big thanks for taking on the role of consulting, evaluating, and deciding on this issue. -- \ “I think Western civilization is more enlightened precisely | `\ because we have learned how to ignore our religious leaders.” | _o__) —Bill Maher, 2003 | Ben Finney ___ Python-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 481 - Migrate Some Supporting Repositories to Git and Github
Donald Stufft writes: > It’s not lost, [… a long, presumably-accurate discourse of the many > conditions that must be met before …] you can restore it. This isn't the place to discuss the details of Git's internals, I think. I'm merely pointing out that: > The important thing to realize is that a “branch” isn’t anything > special in git. Because of that, Ethan's impression – that Git's default behaviour encourages losing history (by re-writing the history of commits to be other than what they were) is true, and “Git never loses history” simply isn't true. Whether that is a *problem* is a matter of debate, but the fact that Git's common workflow commonly discards information that some consider valuable, is a simple fact. If Ethan chooses to make that a factor in his decisions about Git, the facts are on his side. -- \ “One of the most important things you learn from the internet | `\ is that there is no ‘them’ out there. It's just an awful lot of | _o__) ‘us’.” —Douglas Adams | Ben Finney ___ Python-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 481 - Migrate Some Supporting Repositories to Git and Github
Donald Stufft writes: > I have never heard of git losing history. In my experience talking with Git users about this problem, that depends on a very narrow definition of “losing history”. Git encourages re-writing, and thereby losing prior versions of, the history of a branch. The commit information remains, but the history of how they link together is lost. That is a loss of information, which is not the case in the absence of such history re-writing. Git users differ in whether they consider that information loss important; but it is, objectively, losing history information. So Ethan's impression is correct on this point. -- \ “If you see an animal and you can't tell if it's a skunk or a | `\ cat, here's a good saying to help: ‘Black and white, stinks all | _o__) right. Tabby-colored, likes a fella.’” —Jack Handey | Ben Finney ___ Python-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 481 - Migrate Some Supporting Repositories to Git and Github
Donald Stufft writes: > I think there is a big difference here between using a closed source > VCS or compiler and using a closed source code host. Namely in that > the protocol is defined by git so switching from one host to another > is easy. GitHub deliberately encourages proprietary features that create valuable data that cannot be exported — the proprietary GitHub-specific pull requests being a prime example. So it is only true to say one can export the data to a different host if one entirely abandons all those features which create GitHub-proprietary data. If you want to re-write the PEP to be clear you are only talking about the repository hosting of GitHub, and *not* any of its extra features that make it so attractive to use their proprietary service, I'd be interested to see that. On the other hand, if you want to promote those proprietary features as part of the PEP, then it is disingenuous to claim the data can be easily exported to a different host. -- \“Do not enter the lift backwards, and only when lit up.” | `\—elevator, Leipzig | _o__) | Ben Finney ___ Python-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 481 - Migrate Some Supporting Repositories to Git and Github
Chris Angelico writes: > But what non-free software is required to use the community design > processes? The GitHub client is entirely optional; I don't use it, I > just use git itself. Using a free client to access a proprietary > server isn't the same as using non-free software. For that to remain true, there must be no advantage specifically to GitHub except as a commodity repository host. So all the verbiage about specific GitHub features in this PEP are undermined. On the other hand, if GitHub is being recommended specifically because of features that cannot be migrated elsewhere (such as its proprietary pull requests), then it is not possible to argue that Git alone is sufficient to realise these advantages. -- \ “DRM doesn't inconvenience [lawbreakers] — indeed, over time it | `\ trains law-abiding users to become [lawbreakers] out of sheer | _o__)frustration.” —Charles Stross, 2010-05-09 | Ben Finney ___ Python-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 481 - Migrate Some Supporting Repositories to Git and Github
Nick Coghlan writes: > 1. I strongly believe that the long term sustainability of the overall > open source community requires the availability and use of open source > infrastructure. I concur. This article http://mako.cc/writing/hill-free_tools.html> makes the arguments well, IMO. > 2. I also feel that this proposal is far too cavalier in not even > discussing the possibility of helping out the Mercurial team […] we'd > prefer to switch to something else entirely rather than organising a > sprint with them at PyCon to help ensure that our existing Mercurial > based infrastructure is approachable for git & GitHub users? Exactly. For such a core tool, instead of pushing proprietary platforms at the expense of software freedom, the sensible strategy for a project (Python) that hopes to be around in the long term is to use and improve the free software platforms. > As a result, I'm -0 on the PEP, rather than -1 (and will try to stay > out of further discussions). I don't get a vote. So I'm glad there are some within the Python core development team that can see the mistakes inherent in depending on non-free tools for developing free software. -- \ “The cost of a thing is the amount of what I call life which is | `\ required to be exchanged for it, immediately or in the long | _o__) run.” —Henry David Thoreau | Ben Finney ___ Python-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] Move selected documentation repos to PSF BitBucket account?
Nick Coghlan writes: > Are you volunteering to write a competing PEP for a migration to git > and GitHub? Anyone who does decide to propose either Git or GitHub for hosting Python resources: Please don't conflate the two. Git is a community-supported free-software DVCS system with many viable hosting platforms and providers. GitHub is one proprietary hosting service with features that encourage vendor lock-in, and as Barry Warsaw pointed out it is not answerable to the PSF nor under the PSF's control. There are other hosting solutions without these problems. Everyone here already knows this distinction at some level, but it's far too common to see people assume that an argument in favour of Git will also be a compelling case for GitHub. It isn't, and the case for the latter needs to be made quite separately from the case for the former. No, I'm not offering to write such a PEP either. I'm requesting that we recognise that a promotion of GitHub needs to account for its downsides too, and needs to promote its specific benefits separately from the benefits of Git. -- \“There are no significant bugs in our released software that | `\ any significant number of users want fixed.” —Bill Gates, | _o__) 1995-10-23 | Ben Finney ___ Python-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] Bytes path support
"Stephen J. Turnbull" writes: > Marko Rauhamaa writes: > > Unix programmers, though, shouldn't be shielded from bytes. > > Nobody's trying to do that. But Python users should be shielded from > Unix programmers. +1 QotW -- \“Intellectual property is to the 21st century what the slave | `\ trade was to the 16th.” —David Mertz | _o__) | Ben Finney ___ Python-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] Multiline with statement line continuation
Steven D'Aprano writes: > If people were going to be prone to mistake > > with (a, b, c): ... > > as including a tuple … because the parens are a strong signal “this is an expression to be evaluated, resulting in a single value to use in the statement”. > they would have already mistaken: > > with a, b, c: ... > > the same way. But they haven't. Right. The presence or absence of parens make a big semantic difference. -- \ “The process by which banks create money is so simple that the | `\ mind is repelled.” —John Kenneth Galbraith, _Money: Whence It | _o__) Came, Where It Went_, 1975 | Ben Finney ___ Python-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] Multiline 'with' statement line continuation
Ben Hoyt writes: > So -- although I'm not arguing for it here -- you'd be turning an code > (a runtime AttributeError) into valid syntax. Exactly what I'd want to avoid, especially because it *looks* like a tuple. There are IMO too many pieces of code that look confusingly similar to tuples but actually mean something else. -- \ “I have an answering machine in my car. It says, ‘I'm home now. | `\ But leave a message and I'll call when I'm out.’” —Steven Wright | _o__) | Ben Finney ___ Python-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] Multiline ‘with’ statement line continuation
Allen Li writes:
> Currently, this works with explicit line continuation, but as all
> style guides favor implicit line continuation over explicit, it would
> be nice if you could do the following:
>
> with (open('foo') as foo,
> open('bar') as bar,
> open('baz') as baz,
> open('spam') as spam,
> open('eggs') as eggs):
> pass
>
> Currently, this is a syntax error
Even if it weren't a syntax error, the syntax would be ambiguous. How
will you discern the meaning of::
with (
foo,
bar,
baz):
pass
Is that three separate context managers? Or is it one tuple with three
items?
I am definitely sympathetic to the desire for a good solution to
multi-line ‘with’ statements, but I also don't want to see a special
case to make it even more difficult to understand when a tuple literal
is being specified in code. I admit I don't have a good answer to
satisfy both those simultaneously.
--
\ “We have met the enemy and he is us.” —Walt Kelly, _Pogo_ |
`\ 1971-04-22 |
_o__) |
Ben Finney
___
Python-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] pathlib handling of trailing slash (Issue #21039)
Antoine Pitrou writes: > Le 06/08/2014 20:50, Alexander Belopolsky a écrit : > > There are many interfaces where trailing slash is significant. […] > > Loosing it when passing path strings through pathlib.Path() may be a > > source of bugs. > > pathlib is generally concerned with filesystem operations written in > Python, not arbitrary third-party tools. The operating system shell is more than an “arbitrary third-party tool”, though; it preserves paths, and handles invoking commands. You seem to be saying that ‘pathlib’ is not intended to be helpful for constructing a shell command. Will its documentation warn that is so? > Also it is probably easy to append the trailing slash in your > command-line invocation, if so desired. The trouble is that one can desire it, and construct a path knowing that the presence or absence of a trailing slash has semantic significance; and then have it unaccountably altered by the pathlib.Path code. This is worse than preserving the semantic value. -- \ “But Marge, what if we chose the wrong religion? Each week we | `\ just make God madder and madder.” —Homer, _The Simpsons_ | _o__) | Ben Finney ___ Python-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] [RELEASED] Python 3.4.0
Larry Hastings writes: > On behalf of the Python development team, I'm thrilled to announce > the official release of Python 3.4. Hooray! This is great news, the new release looks like a major step forward. Thank you to everyone involved with making the Python 3.4 release happen. -- \ “Why should I care about posterity? What's posterity ever done | `\for me?” —Groucho Marx | _o__) | Ben Finney ___ Python-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] Python3 "complexity" - 2 use cases
"Jim J. Jewett" writes: > > > Steven D'Aprano wrote: > >> I think that heuristics to guess the encoding have their role to play, > >> if the caller understands the risks. > > Ben Finney wrote: > > In my opinion, content-type guessing heuristics certainly don't belong > > in the standard library. > > It would be great if there were never any need to guess. But in the > real world, there is -- and often the user won't know any more than > python does. That's why I think it's great to have heuristic guessing code available as a third-party library. > So when it is time to guess, a source of good guesses is an important > battery to include. Why is it important enough to deserve that privilege, over the thousands of other candidates for the standard library? The barrier for entry to the standard library is higher than mere usefulness. > We should explicitly treat autodetection like time zone data -- > there is no promise that the "right answer" (or at least the "best > guess") won't change, even within a release. But there is exactly one set of authoritative time zones at any particular point in time. That's why it makes sense to have that set of authoritative values available in the standard library. Heuristic guesses about content types do not have the property of exactly one authoritative source, so your analogy is not compelling. -- \ “Unix is an operating system, OS/2 is half an operating system, | `\Windows is a shell, and DOS is a boot partition virus.” —Peter | _o__)H. Coffin | Ben Finney ___ Python-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] Python3 "complexity"
Steven D'Aprano writes: > I think that heuristics to guess the encoding have their role to play, > if the caller understands the risks. I think, for a language whose developers espouse a principle “In the face of ambiguity, refuse the temptation to guess”, heuristics have no role to play in the standard library. > There is already a third-party library, chardet, which does this. As a third-party library, it's fine and quite useful. > Perhaps the std lib should include this? In my opinion, content-type guessing heuristics certainly don't belong in the standard library. -- \ “Nothing is more sacred than the facts.” —Sam Harris, _The End | `\ of Faith_, 2004 | _o__) | Ben Finney ___ Python-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] Python3 "complexity"
Nick Coghlan writes: > On 9 January 2014 10:07, Ben Finney wrote: > > Kristján Valur Jónsson writes: > > > >> Believe it or not, sometimes you really don't care about encodings. > >> Sometimes you just want to parse text files. > > > > Files don't contain text, they contain bytes. Bytes only become text > > when filtered through the correct encoding. […] > Set the mode to "rb", process it as binary. Done. Which entails abandoning the stated goal of “just want to parse text files” :-) -- \ “All television is educational television. The question is: | `\ what is it teaching?” —Nicholas Johnson | _o__) | Ben Finney ___ Python-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] Python3 "complexity"
Kristján Valur Jónsson writes: > I didn't used to must. Why must I must now? Did the universe just > shift when I fired up python3? In a sense, yes. The world of software has been shifting for decades, as a reasult of broader changes in how different segments of humanity have changed their interactions, and thereby changed their expectations of what computers can do with their data. While for some programmers, in past decades, it used to be reasonable to stick one's head in the sand and ignore all encodings except one privileged local encoding, that is no longer reasonable today. As a result, it is incumbent on any programmer working with text to care about text encodings. You've likely already seen it, but the point I'm making is better made in this essay http://www.joelonsoftware.com/articles/Unicode.html>. -- \己所不欲、勿施于人。 | `\(What is undesirable to you, do not do to others.) | _o__) —孔夫子 Confucius, 551 BCE – 479 BCE | Ben Finney ___ Python-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] Python3 "complexity"
MRAB writes: > On 2014-01-09 00:07, Ben Finney wrote: > > Kristján Valur Jónsson writes: > >> Python 3 forces you to think about abstract concepts like encodings > >> when all you want is to open that .txt file on the drive and > >> extract some phone numbers and merge in some email addresses. What > >> encoding does the file have? Do I care? Must I care? > > > > Yes, you must. > > > >> Python forcing you to think about this is like the cashier at the > >> hardware store who won't let you buy the hammer you brought to the > >> cash register because you don't know what wood its handle is made > >> of. > > > > The cashier is making a mistake: the hammer, regardless of the wood in > > the handle, still functions just fine as a hammer. Hence, the question > > is unimportant to the purpose. > > On the other hand: > > "I need a new battery." > > "What kind of battery?" > > "I don't care!" That's a much better analogy. The customer may not care, but the question is essential and must be answered; if the supplier guesses what the customer wants, they are doing the customer a disservice. If the customer insists the supplier just give them a battery which will work regardless of what type of battery the device requires, the *customer is wrong*. Such customers need to be educated about the necessity to care about details they may have no interest in, if they want to get their device working reliably. We can all work toward a world where there is just one encoding which works for all text and no other encodings to confuse the matter. Until then, everyone needs to deal with the world as it is. (good sigmonster, have a cookie) -- \ “Ours is a world where people don't know what they want and are | `\ willing to go through hell to get it.” —Donald Robert Perry | _o__) Marquis | Ben Finney ___ Python-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] Python3 "complexity"
Kristján Valur Jónsson writes: > Believe it or not, sometimes you really don't care about encodings. > Sometimes you just want to parse text files. Files don't contain text, they contain bytes. Bytes only become text when filtered through the correct encoding. Python should not guess the encoding if it's unknown. Without the right encoding, you don't get text, you get partial or complete gibberish. So, if what you want is to parse text and not get gibberish, you need to *tell* Python what the encoding is. That's a brute fact of the world of text in computing. > Python 3 forces you to think about abstract concepts like encodings > when all you want is to open that .txt file on the drive and extract > some phone numbers and merge in some email addresses. What encoding > does the file have? Do I care? Must I care? Yes, you must. > Python forcing you to think about this is like the cashier at the > hardware store who won't let you buy the hammer you brought to the > cash register because you don't know what wood its handle is made of. The cashier is making a mistake: the hammer, regardless of the wood in the handle, still functions just fine as a hammer. Hence, the question is unimportant to the purpose. The same is not true of changing the encoding for text. The encoding matters, and the programmer needs to care. -- \ “How wonderful that we have met with a paradox. Now we have | `\some hope of making progress.” —Niels Bohr | _o__) | Ben Finney ___ Python-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] Discoverability of guides to Python 3 porting (was: 2.x vs 3.x survey results)
Lennart Regebro writes: > On Sun, Jan 5, 2014 at 5:20 AM, John Yeuk Hon Wong > wrote: > > If there is such reference available? > > I'm honestly despairing that people still don't know that there is a > free book on the topic. I have no idea how to increase the knowledge > on this point. John Yeuk Hon Wong, where did you look (unsuccessfully) for this information? Where, on the Python website, did you first expect to find this information and fail to find it? -- \ “If you do not trust the source do not use this program.” | `\—Microsoft Vista security dialogue | _o__) | Ben Finney ___ Python-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] 2.x vs 3.x survey results
Luca Sbardella writes: > you are my heroes but this survey is quite useless, can you include more > people? The survey cohort was self-selected from those who read the forums where it was posted. > I wasn't aware of it so many thousands of python users. That statement confuses me. Were you aware of it, or not? How did you become aware of it? > And after that, you are well aware that Python 3 or 2 is becoming a > liability, just stick with one, anyone (3) at this point. The policy of the Python core developers is quite clear, and has been for many years: Python 2 is a dead end, and Python 2.7 (released 2010-07-03, 3½ years ago) is the last Python 2. Python 2.7 is the last of the Python 2 line, there will never be new Python 2 features http://python.org/dev/peps/pep-0404/>, everyone should migrate to Python 3. That is already the Python core developers's published policy. So, to whom are you speaking here on the Python core developers' forum? > I don't want to go and learn a new language, please. Great! If you already know Python, then there is very little (certainly not “a new language”) different to move from Python 2.7 to Python 3. Enjoy! -- \ “Our task must be to free ourselves from our prison by widening | `\our circle of compassion to embrace all humanity and the whole | _o__) of nature in its beauty.” —Albert Einstein | Ben Finney ___ Python-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] 2.x vs 3.x survey results
Antoine Pitrou writes: > If wiki.python.org supports file uploads, it may be the place for > publishing the results. Dan, can your reporting tool produce the report in HTML format (and plots as SVG images)? That would be IMO more suitable for uploading. -- \“Good morning, Pooh Bear”, said Eeyore gloomily. “If it is a | `\ good morning”, he said. “Which I doubt”, said he. —A. A. Milne, | _o__)_Winnie-the-Pooh_ | Ben Finney ___ Python-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] Thanks for python!
Daniel Benamy writes: > I just wanted to say a quick thanks for python. The language, libs, docs, > and really the whole ecosystem are so well done, and I really appreciate > all your amazing work. Thanks for expressing this! It's good to let the Python developers know that, behind all the requests and complaints, lies a great current of mostly silent but appreciative Python users :-) And, of course, I heartily second the sentiment. A happy new year and good fortune to all Python core developers in 2014! -- \ “Software patents provide one more means of controlling access | `\ to information. They are the tool of choice for the internet | _o__) highwayman.” —Anthony Taylor | Ben Finney ___ Python-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 keyword in PEP URL?
Victor Stinner writes: > 2013/10/12 Ben Finney : > > Victor Stinner writes: > > > >> For draft PEP, the identifier may change. Note that this isn't a matter of the PEP being draft; once a PEP has a number, it deserves an official URL and (if I understand you correctly) a keyword. Then, *after* those official designations are associated with that PEP, another PEP can come along and be a better candidate for the same keyword. What use is a unique keyword-to-PEP mapping if it's not leading to the PEP most clearly associated with that keyword? > I would not be shocked if http://www.python.org/dev/peps/pep-enum/ > link is updated from the PEP 354 to the PEP 435, especially if both > PEPs are draft. On the other hand, what use is a keyword-to-PEP mapping if it isn't reliably going to persist over time? > Identifiers should be carefully chosen, "unicode" is maybe not the > best identifier for a PEP for example (they are many PEPs related to > Unicode). Right. I don't think it makes sense to have a keyword limited to exactly one PEP. > Hum, how are PEP numbers generated? PEP *354* and *435* for enum? > These numbers are not very random. We should check our PRNG :-) They're not random; they're sequential for the most part, IIUC. -- \“The restriction of knowledge to an elite group destroys the | `\ spirit of society and leads to its intellectual | _o__)impoverishment.” —Albert Einstein | Ben Finney ___ Python-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 keyword in PEP URL?
Victor Stinner writes: > For draft PEP, the identifier may change. For an idea implemented in several PEPs, the obvious identifier may be taken first, but the preferred PEP for that identifier may later change. For example, PEP 354 would have the obvious keyword “enum” when it was being discussed. Then it was rejected. Later, PEP 435 was introduced, and accepted. It is now even *more* deserving of the keyword “enum” than the earlier PEP. What do you propose in cases like this? Should the keyword always refer to the same PEP it did in the past, even when that PEP is no longer as relevant given later PEPs? Or should the keyword reach a different, newer PEP if that newer PEP becomes a “more relevant” PEP for the keyword? -- \“There are only two ways to live your life. One is as though | `\ nothing is a miracle. The other is as if everything is.” | _o__) —Albert Einstein | Ben Finney ___ Python-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] Use an empty def as a lambda
Westley Martínez writes: > My reasoning is that we use class to make classes, lambda to make > lambda functions, and def to make--well not defs--functions, which > doesn't really make sense to me. Your reasoning is flawed. There is no such thing in Python as a “lambda function”. Python has functions. It doesn't matter whether you use a ‘lambda’ or ‘def’ statement to create it, there's no resulting difference in the type of the object. It is a function. So: you make a class with a ‘class’ statement; you make a function using either a ‘def’ statement or a ‘lambda’ expression. There is no third type of object being discussed here. -- \ “Faith may be defined briefly as an illogical belief in the | `\ occurrence of the improbable.” —Henry L. Mencken | _o__) | Ben Finney ___ Python-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] Need testing audio files
Serhiy Storchaka writes: > I work on enhancement of audio modules testing [1], and I need free > (in both senses) small sample audio files in different formats. The Internet Archive https://archive.org/> has a wide selection of free-software media, many of which have free license terms that would be suitable for inclusion in Python. I haven't used it, but http://www.pdsounds.org/> appears to be a collection of sounds in the public domain. -- \“The whole area of [treating source code as intellectual | `\property] is almost assuring a customer that you are not going | _o__) to do any innovation in the future.” —Gary Barnett | Ben Finney ___ Python-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] Offtopic: OpenID Providers
Skip Montanaro writes: > >> On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft > >> wrote: > >>> Persona is the logical successor to OpenID. > >> > >> OpenID lived a short life and died a quiet death. I'm afraid Persona > >> wouldn't live even that much. Dead-born idea, in my so humble opinion. > > > > I don't think there's much evidence to support this. I'm seeing more sites > > support Persona > > not less. It solves some of the major problems with OpenID. > > I was completely unaware of OpenID's demise. It has failed at its stated purpose, which was to obviate the need for services to provide their own ad hoc systems and allow users to consolidate their digital identities. This is evident by lookig at how few sites have added OpenID login in the past several years, and how many that once had it have dropped it. If you're unaware of that, I can only surmise you haven't been trying to log in with an OpenID to anything newer than about 2009. > Can someone point me to/provide an explanation? An explanation in terms of what? I can point you to punditry http://www.25hoursaday.com/weblog/2011/01/30/LearningFromOurMistakesTheFailureOfOpenIDAtomPubAndXMLOnTheWeb.aspx> and hand-wringing http://geekyschmidt.com/2011/01/31/openid-death-greatly-exaggerated>. My own take is that most people choose convenience and expedience over security and freedom, hence Facebook and Twitter and Google have taken over the online identity game instead of a federated identity system. > I much prefer using OpenID to login to a site than having to either > come up with yet another username/password which I will just forget, > or using Facebook or similar (I don't really trust them with my info). Agreed. Our preferences are not enough though. -- \ “Anyone who believes exponential growth can go on forever in a | `\ finite world is either a madman or an economist.” —Kenneth | _o__) Boulding | Ben Finney ___ Python-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] Daemon creation code in the standard library
Antoine Pitrou writes: > Therefore I'd be -1 on [PEP 3143] until those issues are alleviated. Cameron Simpson writes: > I have always found the convention that daemons have a umask of 0 > to be utterly bogus, because almost all library code relies on the > umask to set default security policy for initial file permissions. > > Prone to rant on this at length if required... Thanks folks. We'd love to have this discussion over at the ‘python-daemon-devel’ discussion forum if you want to have it in more detail. -- \ “We are all agreed that your theory is crazy. The question that | `\ divides us is whether it is crazy enough to have a chance of | _o__)being correct.” —Niels Bohr (to Wolfgang Pauli), 1958 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Daemon creation code in the standard library
Ben Finney writes: > Work continues on the PEP 3143-compatible ‘python-daemon’, porting it to > Python 3 and aiming for inclusion in the standard library. At PyPI http://pypi.python.org/pypi/python-daemon/>, and development co-ordinated at Alioth https://alioth.debian.org/projects/python-daemon/>. > Interested parties are invited to join us on the discussion forums The correct link for the ‘python-daemon-devel’ forum is http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-daemon-devel>. For announcements only, we have http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-daemon-announce>. -- \“This sentence contradicts itself — no actually it doesn't.” | `\ —Douglas Hofstadter | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Daemon creation code in the standard library (was: Inherance of file descriptor and handles on Windows (PEP 446))
Guido van Rossum writes: > To reduce the need for 3rd party subprocess creation code, we should > have better daemon creation code in the stdlib -- I wrote some damn > robust code for this purpose in my previous job, but it never saw the > light of day. Work continues on the PEP 3143-compatible ‘python-daemon’, porting it to Python 3 and aiming for inclusion in the standard library. Interested parties are invited to join us on the discussion forums http://lists.alioth.debian.org/cgi-bin/mailman/admin/python-daemon-devel>. -- \“Politics is not the art of the possible. It consists in | `\ choosing between the disastrous and the unpalatable.” —John | _o__)Kenneth Galbraith, 1962-03-02 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
Serhiy Storchaka writes: > I'm asking only about this case, when the dash is used to denote a > break in a sentence or to set off parenthetical statements. That's two separate cases: * denote a break in a sentence * set off parenthetical statements In my experience, an em dash is commonly used for the former, and en dashes commonly used for the latter. Using the same dash for both is unusual (and IMO needlessly ambiguous to the reader). > Currently Python documentation uses fourth variants: All your examples are only for parenthetical statements. Can you find examples of the former, where a break (not parenthetical) in the sentence is intended? -- \ “When I was a kid I used to pray every night for a new bicycle. | `\Then I realised that the Lord doesn't work that way so I stole | _o__) one and asked Him to forgive me.” —Emo Philips | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
Serhiy Storchaka writes: > I'm sorry, I were wrong. Actually em-dash used much more then en-dash > in Python documentation. But, as you've also discovered, many authors will type two hyphens “--” when they want an em dash “—”, yet this is rendered to an en dash “–”. So the prevalence of the latter in the documentation probably does not reflect the preferences of the authors. -- \ “Nature hath given men one tongue but two ears, that we may | `\ hear from others twice as much as we speak.” —Epictetus, | _o__) _Fragments_ | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
Serhiy Storchaka writes: > 19.07.13 10:25, Ben Finney написав(ла): > > Serhiy Storchaka writes: > >> What type of dash is preferable in the documentation? The en dash > >> (–) or the em dash (—)? > > > > They have different purposes; use whichever is appropriate for the > > context. > > I mean only a context where a dash is used to denote a break in a > sentence or to set off parenthetical statements. Yes, and both of those are used for different purposes, so “what type is preferable (for all the purposes you mention)” is a poor way of looking at it, IMO. Local style guides have rules about when and how to use the different dashes for specific contexts. (For myself, I prefer parenthetic dashes to be en dashes ‘–’, and a break in a sentence to be marked by an em dash ‘—’. But I also prefer to surround the dash with space for the latter purpose, so my preference isn't universal.) Wikipedia's article (already referred) discusses the matter fairly well https://en.wikipedia.org/wiki/Dashes>. > Currently Python documentation uses four different variants (see my > answer to Ezio). I'd recommend that the Python documentation BDFL should choose and dictate an existing well-groomed style guide for Python documentation, preferably one which explicitly talks about when to use each of the commonly-used dashes. -- \“If you have the facts on your side, pound the facts. If you | `\ have the law on your side, pound the law. If you have neither | _o__) on your side, pound the table.” —anonymous | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
Serhiy Storchaka writes: > What type of dash is preferable in the documentation? The en dash (–) > or the em dash (—)? They have different purposes; use whichever is appropriate for the context. This isn't an official Python developer position. But all of ‘-’, ‘–’, ‘—’, ‘−’, etc. have distinct and common meanings in English text. So it's a mistaken idea to think of “which dash is preferable” since they are *all* preferable for their distinct uses. -- \“Science doesn't work by vote and it doesn't work by | `\authority.” —Richard Dawkins, _Big Mistake_ (The Guardian, | _o__) 2006-12-27) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 and Windows XP: just 45 days until EOL
"Stephen J. Turnbull" writes: > I don't see any good reason to take into account what Microsoft does > or doesn't support. It seems you're advocating a position quite ad odds with http://www.python.org/dev/peps/pep-0011/#id7>. Can you propose an amendment to PEP 11 that would remove that consideration? -- \ “If you do not trust the source do not use this program.” | `\—Microsoft Vista security dialogue | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)
Antoine Pitrou writes: > I don't always find it easy to summarize a function in one line. Difficulty in coming up with an accurate one-line summary of the intent of a function is a code smell: the function probably needs to be simplified so it is easier to describe accurately. This is, IMO, one of the primary benefits of having a convention of expecting a one-line summary for every function (and module and class). -- \ “Courage is not the absence of fear, but the decision that | `\ something else is more important than fear.” —Ambrose Redmoon | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)
Skip Montanaro writes: > Where I can [conform to PEP 257], I do, however I often find it > difficult to come up with a one-liner, especially one that mentions > the parameters to functions. I think it's far better to make the synopsis a summary of the purpose of the function; no need to force the parameters in there if they don't fit naturally in the sentence fragment. A list of the parameters and return value can go in the detailed description. -- \ “Theology is the effort to explain the unknowable in terms of | `\ the not worth knowing.” —Henry L. Mencken | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
Ethan Furman writes: > Thank you for the offer, but I think I'll go with GPS's idea of > calling it enum34. That name will be confusing once Python 3.5 exists (even as a development version). I'd argue that it is confusing even now, since this is a backport for Python version *earlier* than Python 3.4. The name ‘stdlib.enum’ avoids these problems, do you think that is suitable? -- \ “If trees could scream, would we be so cavalier about cutting | `\ them down? We might, if they screamed all the time, for no good | _o__)reason.” —Jack Handey | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
Donald Stufft writes: > On Jun 15, 2013, at 10:45 PM, Ben Finney wrote: > > Is there anything I can do to keep the ‘enum’ package online for > > continuity but make it clear, to automated tools, that this is > > end-of-life and obsoleted by another package? > > Right now the best you can do is make a note of it. Pep 426 let's you > do what you want. Thanks. What specifically in PEP 426 do you mean; how would I make a note of “this package is end-of-life as is, please migrate to ‘flufl.enum’ instead” using PEP 426 metadata? -- \“There are no significant bugs in our released software that | `\ any significant number of users want fixed.” —Bill Gates, | _o__) 1995-10-23 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backported Enum
Ethan Furman writes: > So I have the stdlb 3.4 Enum backported for both earlier 3.x and back > to 2.4 in the 2.x series. > > I would like to put this on PyPI, but the `enum` name is already > taken. I have for a long time approved of ‘flufl.enum’ becoming the One Obvious Way to do enumerations, and am glad to see PEP 435 bring it into the standard library. http://mail.python.org/pipermail/python-ideas/2011-July/010811.html> There are some people still contacting me about their use of the ‘enum’ package on PyPI, so I think that to just replace it with a different code base under the same name would not be helpful. > Would it be inappropriate to call it `stdlib.enum`? That sounds good to me. Is there anything I can do to keep the ‘enum’ package online for continuity but make it clear, to automated tools, that this is end-of-life and obsoleted by another package? -- \ “Free thought is a necessary, but not a sufficient, condition | `\ for democracy.” —Carl Sagan | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deciding against the CLA
Steven D'Aprano writes: > On 13/04/13 20:30, Ben Finney wrote: > > "Stephen J. Turnbull" writes: > >> A failure to sign the CLA is already a decision not to contribute > >> to the distribution > > > > As someone who cannot in good faith sign the CLA, that > > characterisation is far from accurate: I would very much like to > > contribute to the Python distribution, and so have not decided as > > you describe. > > Could you explain, briefly, why you cannot sign the CLA? Because software freedom in a work is undermined when any recipient is granted special legal privilege in the work. As it currently stands, the Contributor Agreement grants special legal privilege in the work (the power to unilaterally re-license the work) to the PSF. By “special privilege”, I mean that this power is granted specially to some but denied to all other recipients of the work. Hence to sign the Contributor Agreement as it currently stands is to undermine software freedom in the resulting work. -- \“Choose mnemonic identifiers. If you can't remember what | `\mnemonic means, you've got a problem.” —Larry Wall | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8
Ian Cordasco writes: > Are you concerned about the evolution of various code checkers? > Do you have questions or suggestions? > > Subscribe here: > http://mail.python.org/mailman/listinfo/code-quality Now available via Gmane also http://dir.gmane.org/gmane.comp.python.code-quality>. Thanks guys! -- \ “I have never imputed to Nature a purpose or a goal, or | `\anything that could be understood as anthropomorphic.” —Albert | _o__)Einstein, unsent letter, 1955 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deciding against the CLA (was: Introducing Electronic Contributor Agreements)
"Stephen J. Turnbull" writes: > Mark Lawrence writes: > > > People already use the bug tracker as an excuse not to contribute, > > wouldn't this requirement make the situation worse? > > A failure to sign the CLA is already a decision not to contribute to > the distribution As someone who cannot in good faith sign the CLA, that characterisation is far from accurate: I would very much like to contribute to the Python distribution, and so have not decided as you describe. Rather, I leave the matter of contribution undecided, while advocating (when opportunity arises) against the CLA. The decision that the current terms are unacceptable does not entail a decision not to contribute. (aside: good sigmonster, have a treat.) -- \ Lucifer: “Just sign the Contract, sir, and the Piano is yours.” | `\ Ray: “Sheesh! This is long! Mind if I sign it now and read it | _o__) later?” —http://www.achewood.com/ | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP for time zone support.
Terry Reedy writes: > On 12/12/2012 10:56 AM, Lennart Regebro wrote: > > >> It seems like calling get_timezone() with an unknown timezone > >> should just throw ValueError, not necessarily some custom > >> Exception? > > > > That could very well be. What are others opinions on this? > > ValueError. That is what it is. Nothing special here. I think it's useful to have this raise a custom exception UnknownTimeZoneError, subclassed from ValueError. That satisfies those (including me!) who think it should be a ValueError, while also making the exception more specific so it can be handled apart from other possible ValueError causes. In short: +1 to ‘class UnknownTimeZoneError(ValueError)’. -- \“Members of the general public commonly find copyright rules | `\implausible, and simply disbelieve them.” —Jessica Litman, | _o__) _Digital Copyright_ | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TZ-aware local time
Guido van Rossum writes: > On Mon, Jun 11, 2012 at 7:10 PM, Ben Finney > wrote: > > Unambiguous storage of absolute time can be achieved with POSIX > > timestamps, but that is certainly not the only nor best way to do > > it. > > > > For example, RFC 5322 specifies a standard serialisation for > > timestamp values that is in very wide usage, and those values are > > valid for transforming to a ‘datetime.datetime’ value. POSIX > > timestamps are not a necessary part of the data model. > > To the contrary, without the POSIX timestamp model to define the > equivalency between the same point in time expressed using different > timezones, sane comparisons and arithmetic on timestamps would be > impossible. Why is the POSIX timestamp model the only possible model? To the contrary, there are many representations with different tradeoffs but with the common properties you name (“equivalency between the same point in time expressed using different timezones”). I'm objecting to your assertion that the *specific* data format of POSIX timestamps is necessary for this, rather than being a contingent format that is one of many real world formats used for timestamps. > > Another example is database fields storing timestamp values; they are > > surely a very common input for Python ‘datetime.datetime’ values. > > But how does a database represent timestamps *internally*? My point is that the programmer using Python ‘datetime’, and not dealing with POSIX timestamps at any point, should not need to care how ‘datetime’ represents its values internally. You said “the *input* […] should be a POSIX timestamp, not a datetime object.”, but these use cases (RFC 5322 timestamps, database timestamp field values) have other inputs for timestamp values and there's no need for a POSIX timestamp in the data model. The programmer for these common use cases is dealing with input that is not POSIX timestamps, their output is not POSIX timestamps, and the data processing doesn't have any need for the concept of “seconds since epoch”. So why claim that the POSIX timestamp is necessary for such use cases? > > For many use cases a different storage is appropriate, a different > > input is appropriate, and POSIX timestamps are irrelevant for those > > use cases. > > POSIX timestamps are no good for human-entered input or human-readable > output. But they are hard to beat for internal storage. Perhaps so, and perhaps not. Either way, that's not an argument for requiring the user of ‘datetime’ to deal with that internal representation. The ‘datetime’ module provides a useful abstraction that allows different serialisation, without tying the programmer to POSIX timestamps. > >> > .. Users should be required to understand POSIX timestamps and > >> > the importance of UTC before they try to work with multiple > >> > timezones. > > > > Why? If they are using, for example, a PostgreSQL ‘TIMESTAMP’ object > > to store the value, and manipulating it with Python > > ‘datetime.datetime’, why should they have to know anything about > > POSIX timestamps? > > So they'll understand that midnight in New York != midnight In San > Francisco, while 4pm in New York == 1pm in San Francisco. And so they > understand that, while the difference between New York and San > Francisco time is always 3 hours, the difference between San Francisco > time and Sydney time can vary by two hours. You made two assertions in “Users should be required to understand POSIX timestamps and the importance of UTC before they try to work with multiple timezones.” I'm not objecting to “Users should be required to understand the importance of UTC before they try to work with multiple timezones”. I am objecting to “Users should be required to understand POSIX timestamps before they try to work with multiple timezones”. Your argument about timezones is irrelevant to my objection about requiring users to understand POSIX timestamps. > IMO you ignore the underlying POSIX timestamps at your peril as soon > as you are comparing timestamps. If another representation (e.g. a database field) allows the comparison safely, why require the programmer to understand a data representation irrelevant to their use case? > Anyway, we're very far from the original problem statement. That might be part of the misunderstanding, and I apologise if that confused matters. I don't want a useful abstraction like Python's ‘datetime’ to be intentionally leaky, so I don't think “Users should be required to understand POSIX timestamps before they try to work with multiple timezones” is helpful. That's the whole of my objection, and the only point I'm currently arguing in this wide-ranging thread. -- \ “Whatever you
Re: [Python-Dev] TZ-aware local time
Alexander Belopolsky writes: > On Mon, Jun 11, 2012 at 1:01 PM, Guido van Rossum wrote: > > Maybe the problem here is the *input*? It should be a POSIX > > timestamp, not a datetime object. > > No. "Seconds since epoch" or "POSIX" timestamp is a foreign data type > to the datetime module. On this point I must agree with Alexander. Unambiguous storage of absolute time can be achieved with POSIX timestamps, but that is certainly not the only nor best way to do it. For example, RFC 5322 specifies a standard serialisation for timestamp values that is in very wide usage, and those values are valid for transforming to a ‘datetime.datetime’ value. POSIX timestamps are not a necessary part of the data model. Another example is database fields storing timestamp values; they are surely a very common input for Python ‘datetime.datetime’ values. For many use cases a different storage is appropriate, a different input is appropriate, and POSIX timestamps are irrelevant for those use cases. > > .. Users should be required to understand POSIX timestamps and the > > importance of UTC before they try to work with multiple timezones. Why? If they are using, for example, a PostgreSQL ‘TIMESTAMP’ object to store the value, and manipulating it with Python ‘datetime.datetime’, why should they have to know anything about POSIX timestamps? On the contrary, for such use cases (and database timestamp values are just one such) I think it's a needless imposition on the programmer to force them to learn about POSIX timestamps, a data type irrelevant for their purposes. -- \ “My business is to teach my aspirations to conform themselves | `\ to fact, not to try and make facts harmonise with my | _o__) aspirations.“ —Thomas Henry Huxley, 1860-09-23 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
Ben Finney writes: > Georg Brandl writes: > > > list of possible features for 3.3 as specified by PEP 398: > > > > Candidate PEPs: > […] > > > * PEP 3143: Standard daemon process library > > Our porting work will not be done in time for Python 3.3. I will update > this to target Python 3.4. The PEP document currently says it targets “3.x”. I'll leave it in that state until we're more confident that the current work will be on track for a particular Python release. Do I need to do anything in particular to be explicit that PEP 3143 is not coming in Python 3.3? -- \“Human reason is snatching everything to itself, leaving | `\ nothing for faith.” —Bernard of Clairvaux, 1090–1153 CE | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] TZ-aware local time
MRAB writes: > datetime objects would consist of the UTC time, time zone and DST. “time zone” information always entails DST information doesn't it? It isn't proper time zone information if it doesn't tell you about DST. That is, when you know the full time zone information, that includes when (if ever) DST kicks on or off. Or have I been spoiled by the Olsen database? -- \ “Truth is stranger than fiction, but it is because fiction is | `\ obliged to stick to possibilities, truth isn't.” —Mark Twain, | _o__) _Following the Equator_ | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
Georg Brandl writes: > list of possible features for 3.3 as specified by PEP 398: > > Candidate PEPs: […] > * PEP 3143: Standard daemon process library Our porting work will not be done in time for Python 3.3. I will update this to target Python 3.4. -- \ “The best mind-altering drug is truth.” —Jane Wagner, via Lily | `\Tomlin | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] netiquette on py-dev
"Stephen J. Turnbull" writes: > I don't know of any webmail implementations that provide > reply-to-list, so a lot of us end up using reply-to-all. Right, that puts the responsibility in the right place: the webmail software vendor needs to add a reply-to-list command, as has been implemented in many clients for many years and supported explicitly by standard fields in every message header. > So in most cases I suppose that the duplicate going to the author is > just an issue of "energy conservation" on the part of the responder. I agree that's likely the usual reason. It's saving short-term effort by passing that effort on to others though, and to that extent is inconsiderate of other people. Better is for webmail users to pressure the vendor of the webmail software to add the “Reply to list” feature and make it clear this is the recommended way to reply on a mailing list. > Note that people who are really annoyed by the duplicates can set > their Mailman accounts to no-dupes, and Mailman won't send the post to > that person. Those of us who don't have a Mailman account don't have that option, as you noted. I'm not participating in this forum by email at all, and don't expect *any* copies of its messages in my email. The problem is with the missing feature of the webmail program, and the users of that program need to agitate for getting it fixed. Nick Coghlan writes: > So yeah, the basic problem is mail clients that don't offer a > "Reply-List" option, with the Gmail web client being a notable > offender. It doesn't even need to be extra effort for the user. The “Reply to author” command can change to a “Reply to list” command when the mailing list fields are present. That's one possible solution; but anything that gets more people to “Reply to list” when appropriate is acceptable to me. -- \ “Don't you try to outweird me, I get stranger things than you | `\ free with my breakfast cereal.” —Zaphod Beeblebrox, _The | _o__)Restaurant At The End Of The Universe_, Douglas Adams | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] netiquette on py-dev
Ethan Furman writes: > When responding to posts, should the poster to whom I am responding be > listed as well as python-dev, or should my responses just go to > python-dev? IMO, the poster to whom you are responding should expect to read your response in the same forum where their message appeared. So, no need to send them another copy individually. -- \ “There is something wonderful in seeing a wrong-headed majority | `\ assailed by truth.” —John Kenneth Galbraith, 1989-07-28 | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for developing a module to be used from postgreSQL/pl/python
Hannu Krosing writes: > Has anyone used Cython for developing a module to be used from > postgreSQL/pl/python. > > Something that calls back to PostgreSQL internals. Are you aware that PostgreSQL has long provided Python as a language for writing stored procedures in the database? http://www.postgresql.org/docs/current/static/plpython.html> Does that meet your needs? -- \ “You've got to think about big things while you're doing small | `\ things, so that all the small things go in the right | _o__) direction.” —Alvin Toffler | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs, iteration 2
Brian Curtin writes: > On Sun, Mar 25, 2012 at 14:50, Andrew Svetlov > wrote: > > I like to see new schema only for 3.3 as sign of shiny new release. > > Please don't do this. It will result in endless complaints. Complaints of what nature? Do you think those complaints are justified? -- \“… Nature … is seen to do all things herself and through | `\ herself of own accord, rid of all gods.” —Titus Lucretius | _o__) Carus, c. 40 BCE | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs, iteration 2
Georg Brandl writes: > Here's another try, mainly with default browser font size, more > contrast and collapsible sidebar again: > > http://www.python.org/~gbrandl/build/html2/ Great! You've improved it nicely. I especially like that you have https://en.wikipedia.org/wiki/Unobtrusive_JavaScript> done the collapsible sidebar with graceful degradation: the content is quite accessible without ECMAscript. Can you make the link colors (in the body and sidebar) follow the usual conventions: use a blue colour for unvisited links, and a purple colour for visited links http://www.useit.com/alertbox/20040510.html> so it's more obvious where links are and where the reader has already been. -- \ “I distrust those people who know so well what God wants them | `\to do to their fellows, because it always coincides with their | _o__) own desires.” —Susan Brownell Anthony, 1896 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
PJ Eby writes: > On Sat, Mar 24, 2012 at 1:32 AM, Greg Ewing > wrote: > > > If you don't want 1920-pixel-wide text, why make your browser window > > that large? > > Not every tab in my browser is text for reading; some are apps that > need the extra horizontal space. So, again, why make your browser window *for reading text* that large? You have control over how large your window size is, and if you have purposes so different that they demand different widths, then you can easily make different-width windows. Everyone has different needs for how large the text should be and how much of it should go across the window. Every one of us is in a minority when it comes to those needs; that's exactly what a configuration setting is good for. It's madness to expect web designers to hobble the flexibility of a web page to cater preferentially for one minority over others. -- \ “Come on Milhouse, there’s no such thing as a soul! It’s just | `\ something they made up to scare kids, like the Boogie Man or | _o__) Michael Jackson.” —Bart, _The Simpsons_ | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
Dirkjan Ochtman writes: > On Wed, Mar 21, 2012 at 07:00, Georg Brandl wrote: > > OK, that seems to be the main point people make... let me see if I > > can come up with a better compromise. > > Would it be possible to limit the width of the page? On my 1920px > monitor, the lines get awfully long, making them harder to read. −1. Please, web designers, don't presume to know what width the viewer wants. We can change the window size if that's what we want. -- \ “I hope some animal never bores a hole in my head and lays its | `\ eggs in my brain, because later you might think you're having a | _o__) good idea but it's just eggs hatching.” —Jack Handey | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 misnaming
Facundo Batista writes:
> if (width == 0 and height == 0 and
> color == 'red' and emphasis == 'strong' or
> highlight > 100):
> raise ValueError("sorry, you lose")
>
> In the example the line is broken after the 'and' or 'or' *keywords*,
‘and’ and ‘or’ are binary operators (that also happen to be keywords).
The description is accurate and IMO not misleading.
> not after the '==' *operator* (which is the nice way of doing it).
−1. The lower-priority binding operator is the better place to break the
line. The binary logical operators bind at lower priority than the
equality operator.
--
\ “If you do not trust the source do not use this program.” |
`\—Microsoft Vista security dialogue |
_o__) |
Ben Finney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Greg Ewing writes: > Guido van Rossum wrote: > > if there is an *actual* causal link between file A and B, the > > difference in timestamps should always be much larger than 100 ns. > > And if there isn't a causal link, simultaneity is relative anyway. To > Fred sitting at his computer, file A might have been created before > file B, but to George running from the other end of the building in > response to an urgent bug report, it could be the other way around. Does that change if Fred and George are separated in the building by twenty floors? -- \“Kill myself? Killing myself is the last thing I'd ever do.” | `\—Homer, _The Simpsons_ | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Guido van Rossum writes: > On Wed, Feb 15, 2012 at 6:06 PM, Greg Ewing > wrote: > > It probably isn't worth the bother for things like file timestamps, > > where the time taken to execute the system call that modifies the > > file is likely to be several orders of magnitude larger. > > Ironically, file timestamps are likely the only place where it > matters. Read the rest of the thread. And log message timestamps. The *two* only places where it matters, file timestamps and log messages. And communication protocols. The *three* only places – I'll come in again. -- \ “Why should I care about posterity? What's posterity ever done | `\for me?” —Groucho Marx | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] best place for an atomic file API
Brian Curtin writes: > On Wed, Feb 15, 2012 at 19:19, Ben Finney wrote: > > Charles-François Natali writes: > > > >> […] using rename() on POSIX systems and MoveFileEx() on Windows > >> (which are now available through os.replace()). It would also use > >> fsync() on POSIX to make sure data is committed to disk. > > > > These make it quite OS-specific. > > That'll happen when solving problems on different OSes. Do you propose > a more platform agnostic solution? No, I have no objection to that implementation. I'm pointing that out only because the nature of the functionality implies I'd expect to find it within the ‘os’ module hierarchy. -- \ “The man who is denied the opportunity of taking decisions of | `\ importance begins to regard as important the decisions he is | _o__)allowed to take.” —C. Northcote Parkinson | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] best place for an atomic file API
Charles-François Natali writes: > Issue #8604 aims at adding an atomic file API to make it easier to > create/update files atomically, using rename() on POSIX systems and > MoveFileEx() on Windows (which are now available through > os.replace()). It would also use fsync() on POSIX to make sure data is > committed to disk. These make it quite OS-specific. […] > What would be the best place for a such a class? > _pyio, tempfile, or a new atomicfile I would expect to find it within ‘os’ or submodules of ‘os’. -- \“We should be less concerned about adding years to life, and | `\ more about adding life to years.” —Arthur C. Clarke, 2001 | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
