Re: [Python-ideas] PEP: Distributing a Subset of the Standard Library

On 28 November 2016 at 13:28, Tomas Orsava wrote: > The ``.missing.py`` extension will be added to the end of the list, and > configured to be handled by ``SourceFileLoader``. Thus, if a module is not > found in its proper location, the ``XYZ.missing.py`` file is found and >

Re: [Python-ideas] Decorator to avoid a mistake

On 26 November 2016 at 07:16, Nick Coghlan wrote: > On 26 November 2016 at 13:26, Guido van Rossum wrote: >> I think one reason why such proposals are unwelcome to experienced users may >> be that when done right this is totally legitimate, and the

Re: [Python-ideas] Decorator to avoid a mistake

On 23 November 2016 at 08:08, François Leblanc wrote: > It's why I'd prefer this integrate in language, but if there no way to get > it without performance cost > I will have a look to a pylint solution... The point here is that if there is a way to get it without a

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 17 November 2016 at 14:45, Chris Angelico wrote: > Personally, when I hit step 6, I search the web. PyPI search is > exhaustive but not very usefully ranked (for this purpose). Searching > for a keyword or protocol will give undue weight to a module whose > name is simply

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 17 November 2016 at 12:27, Cory Benfield wrote: > This isn’t me disagreeing with you, just me pointing out that the fuzziness > around this makes me nervous. It has been my experience that a large number > of protocol implementations in the standard library are already

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 17 November 2016 at 11:12, Stephen J. Turnbull wrote: > > However, when it comes to draconian security policies, *transitive > > recommendations have power*: if CPython is approved, and python-dev > > collectively says "we recommend pip, virtualenv, and

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 17 November 2016 at 10:58, Cory Benfield wrote: > Paul, you mentioned that discovery on PyPI is a problem: I don’t contest that > at all. But I don’t think the solution to that problem is to jam modules into > the standard library, and I think even less of that idea when

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 17 November 2016 at 02:42, Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > But I am not a draconian security policy QA/security reviewer. I'd > take anything Paul Moore says pretty seriously, as he operates in such > an environment. For context, my env

Re: [Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]

On 17 November 2016 at 03:07, Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Paul Moore writes: > > > PS Note for anyone who wants to take this off on a wild tangent - my > > above comment is *in the context of Python as it has been defined for >

Re: [Python-ideas] Support for OAuth2/OIDC in the standard distribution ?

On 16 November 2016 at 13:55, Cory Benfield wrote: >> If you have any idea about how we could reach more coders I’m all ears. > > Coders who need OIDC will go looking for it and will find their options. > Ultimately, a huge number of projects haven’t suffered from being

Re: [Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]

On 16 November 2016 at 08:51, Mikhail V wrote: > What semantics it will fundamentally break or so hard to implement? I'm afraid I don't have time at the moment to fully review your email, but my first impression is that you are proposing that the name "self" be treated

Re: [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)

On 15 November 2016 at 02:59, Matthias welp wrote: > Mikhail, what Paul probably means here is that python 'operators' are actually > 'syntactic sugar' for functions (it is not recommended to call > these functions directly, but it is possible): More specifically, the

Re: [Python-ideas] Reverse assignment operators (=+, =-, =*, =/, =//, =**, =%)

On 14 November 2016 at 22:13, Mikhail V wrote: >> we don't want A = A + 1 to be the same as A += 1 " > > This sounds quite frustrating for me, what else could this be but A += 1? > Would I want a copy with same name? How that will make sense? >>> A = [1,2,3] >>> B = A >>> A

Re: [Python-ideas] "Proposing a change" document? (was: Civility on this mailing list)

On 10 November 2016 at 21:18, Ethan Furman <et...@stoneleaf.us> wrote: > On 11/10/2016 01:07 PM, Franklin? Lee wrote: >> >> On Fri, Oct 21, 2016 at 11:07 AM, Paul Moore <p.f.mo...@gmail.com> wrote: >>> >>> >>> I wonder. Would there be valu

Re: [Python-ideas] Null coalescing operator

On 1 November 2016 at 10:11, Nick Coghlan wrote: > > I do think it would be worth covering the symbol+keyword option > discussed in PEP 531 (i.e. "?else" instead of "??", but keeping "?.", > and "?[") FWIW, I'm not keen on it. As a technical question, would it be treated in

Re: [Python-ideas] Query Language extension to Python

On 1 November 2016 at 08:33, Pavel Velikhov wrote: > We have released PythonQL, a query language extension to Python (we have > extended Python’s comprehensions with a full-fledged query language, > drawing from the useful features of SQL, XQuery and JSONiq). Take a

Re: [Python-ideas] Null coalescing operator

On 31 October 2016 at 17:16, Guido van Rossum wrote: > I think we should try to improve our intutition about these operators. Many > things that are intuitively clear still require long turgid paragraphs in > reference documentation to state the behavior unambiguously -- but

Re: [Python-ideas] Non-ASCII in Python syntax? [was: Null coalescing operator]

On 30 October 2016 at 14:43, wrote: > Just picking a nit, here, windows will happily let you do silly things like > hook 14 keyboards up and let you map all of emoji to them. Sadly, this > requires lua. Off topic, I know, but how? I have a laptop with an external and

Re: [Python-ideas] Non-ASCII in Python syntax? [was: Null coalescing operator]

On 30 October 2016 at 12:31, Chris Angelico <ros...@gmail.com> wrote: > On Sun, Oct 30, 2016 at 11:22 PM, Paul Moore <p.f.mo...@gmail.com> wrote: >> In mentioning emoji, my main point was that "average computer users" >> are more and more likely to want

Re: [Python-ideas] Non-ASCII in Python syntax? [was: Null coalescing operator]

On 30 October 2016 at 07:00, Stephen J. Turnbull wrote: >> as I imagine Unicode characters would be for me. I really hope it > > isn't... > > I think your imagination is running away with you. While I understand > how costly it is for those over the age of

Re: [Python-ideas] Null coalescing operator

On 29 October 2016 at 18:19, Stephen J. Turnbull wrote: >> For better or worse, it may be emoji that drive that change ;-) > > I suspect that the 100 million or so Chinese, Japanese, Korean, and > Indian programmers who have had systems that have no trouble >

Re: [Python-ideas] PEP 531: Existence checking operators

On 29 October 2016 at 07:21, Nick Coghlan wrote: > A short-circuiting if-else protocol for arbitrary "THEN if COND else > ELSE" expressions could then look like this: > > _condition = COND > if _condition: > _then = THEN > if hasattr(_condition,

Re: [Python-ideas] PEP 531: Existence checking operators

On 28 October 2016 at 15:40, Nick Coghlan wrote: > I also don't think the idea is sufficiently general to be worthy of > dedicated syntax if it's limited specifically to "is not None" checks > - None's definitely special, but it's not *that* special. Unifying > None, NaN,

Re: [Python-ideas] A better interactive prompt

On 27 October 2016 at 01:49, Steven D'Aprano wrote: >> (a bit like readline, >> but I dislike the way you can't switch off readline integration if >> it's installed)? > > This comment surprises me. To me, that's like saying "I dislike the way > you can't switch off breathing"

Re: [Python-ideas] A better interactive prompt

On 26 October 2016 at 22:40, Nikolaus Rath wrote: > It also imposes a significant burden on scripting. I often have elements > like this in shell scripts: > > output=$(python < import h5py > with h5py.File('foo', 'r') as fh: > print((fh['bla'] * fh['com']).sum()) > EOF > )

Re: [Python-ideas] A better interactive prompt

On 26 October 2016 at 22:11, Todd wrote: > Isn't this what aliases are for? Just set "python" to be an alias for > "ipython" for your interactive shell. I hadn't thought of that option. I might give it a try. Although I'm not sure how I'd set up a Powershell function (I'm on

Re: [Python-ideas] A better interactive prompt

On 26 October 2016 at 18:25, Nick Coghlan wrote: > The built-in REPL serves two quite divergent use cases, and I think > we're well past the point where we can't readily support both use > cases with a single implementation: > > - a minimalist interactive environment, that is

Re: [Python-ideas] Showing qualified names when a function call fails

On 25 October 2016 at 20:17, Nathaniel Smith wrote: > I get that this list's default is to push > back on proposed changes, and it's a good principle in general, but > "improved error messages" are *really* cheap. The bar should be pretty > low, IMO. If someone's willing to do the

[Python-ideas] A better interactive prompt

I've seen a lot of syntax proposals recently that are based around providing better ways of writing "one liner" styles of code. Typically, the proposals seem to get into trouble because: 1. They duplicate things that can already be done, just not in a single expression/statement. 2. They are seen

Re: [Python-ideas] f-string, for dictionaries

On 25 October 2016 at 20:11, Michel Desmoulin wrote: > Similarly, I'd like to suggest a similar feature for building dictionaries: > foo = 1 bar = 2 {:bar, :foo} > {'bar': 1, 'foo', 2} I don't see a huge advantage over >>> dict(foo=foo, bar=bar)

Re: [Python-ideas] More user-friendly version for string.translate()

On 24 October 2016 at 18:39, Mikhail V wrote: > I would be happy to see a somewhat more general and user friendly > version of string.translate function. > It could work this way: > string.newtranslate(file_with_table, Drop=True, Dec=True) Using a text file seems very odd.

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

On 23 October 2016 at 17:10, Danilo J. S. Bellini wrote: >> Ah, that makes SIX existing solutions. Do we need a seventh? > > It might have dozens of solutions, perhaps an infinity of solutions. > Brainfuck and assembly can be used, or even turing machine instructions...

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

On 22 October 2016 at 08:17, Chris Angelico wrote: > On Sat, Oct 22, 2016 at 5:49 PM, Ryan Birmingham > wrote: >> this proposed change aims to solve the problem caused when editors, mail >> clients, web browsers, and operating systems over-zealously

Re: [Python-ideas] Deterministic iterator cleanup

On 21 October 2016 at 21:59, Chris Barker wrote: >> So (it seems to >> me) that you're talking about changing the behaviour of for-loops to >> suit only a small proportion of cases: maybe 10% of 10%. > > > I don't see what the big overhead is here. for loops would get a new

Re: [Python-ideas] Civility on this mailing list

On 21 October 2016 at 15:26, Nick Coghlan wrote: > - Remember that even if something we vehemently consider "wrong" makes > it into the reference implementation, the language does have a design > policy that allows us to correct design mistakes after a suitable > deprecation

Re: [Python-ideas] Deterministic iterator cleanup

On 21 October 2016 at 12:23, Steven D'Aprano <st...@pearwood.info> wrote: > On Fri, Oct 21, 2016 at 11:03:51AM +0100, Paul Moore wrote: > >> At the moment, the take home message for such users feels like it's >> "you might need to scatter preserve() around your co

Re: [Python-ideas] Deterministic iterator cleanup

On 21 October 2016 at 10:53, Steven D'Aprano wrote: > On Wed, Oct 19, 2016 at 12:33:57PM -0700, Nathaniel Smith wrote: > >> I should also say, regarding your specific example, I guess it's an >> open question whether we would want list_iterator.__iterclose__ to >> actually do

Re: [Python-ideas] Deterministic iterator cleanup

On 19 October 2016 at 20:21, Nathaniel Smith <n...@pobox.com> wrote: > On Wed, Oct 19, 2016 at 11:38 AM, Paul Moore <p.f.mo...@gmail.com> wrote: >> On 19 October 2016 at 19:13, Chris Angelico <ros...@gmail.com> wrote: >>> Now it *won't* correctly call th

Re: [Python-ideas] Deterministic iterator cleanup

On 19 October 2016 at 19:13, Chris Angelico wrote: > Now it *won't* correctly call the end-of-iteration function, because > there's no 'for' loop. This is going to either (a) require that EVERY > consumer of an iterator follow this new protocol, or (b) introduce a > ton of edge

Re: [Python-ideas] Civility on this mailing list

On 19 October 2016 at 12:29, Michel Desmoulin wrote: > I feel like people are really getting hyper sensitive about communications. > While I do prefer talking to calm rational people with a friendly tone, I > acknowledge this is not always the case and it's ok if

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18 October 2016 at 07:31, Nick Coghlan wrote: > > Forcing ourselves to come up with a name for the series of values > produced by the outer iteration then makes that name available as > documentation of our intent for future readers of the code. This is a key point, that

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 17 October 2016 at 22:28, Mark Lawrence via Python-ideas wrote: > How about changing https://wiki.python.org/moin/HowTo/Sorting ? Good point. Better still, https://docs.python.org/3.6/howto/sorting.html Paul ___

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 21:43, Sven R. Kunze wrote: > The statement about "cumbersomeness" was specific to this whole issue. Of > course, importing feature-rich pieces from the stdlib is really cool. It was > more the missed ability to do the same with list comprehensions of what

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 21:30, Random832 <random...@fastmail.com> wrote: > On Mon, Oct 17, 2016, at 16:12, Paul Moore wrote: >> And finally, no-one has even *tried* to explain why we need a third >> way of expressing this construction. Nick made this point, and >>

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 21:22, Random832 wrote: > For a more concrete example: > > [*range(x) for x in range(4)] > [*(),*(0,),*(0,1),*(0,1,2)] > [0, 0, 1, 0, 1, 2] > > There is simply no way to get there by using flatten(range(4)). The only > way flatten *without* a

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 20:35, Sven R. Kunze wrote: > P.S. It's very artificial to assume user are unable to use 'from itertools > import chain' to try to make chain() seem more cumbersome than it is. > > I am sorry but it is cumbersome. Imports are a fundamental part of Python.

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17 October 2016 at 18:32, Steven D'Aprano wrote: > On Mon, Oct 17, 2016 at 12:11:46PM -0400, Random832 wrote: > >> Honestly, it goes beyond just being "wrong". The repeated refusal to >> even acknowledge any equivalence between [...x... for x in [a, b, c]] >> and [...a...,

Re: [Python-ideas] Fwd: Fwd: unpacking generalisations for list comprehension

On 14 October 2016 at 10:48, Paul Moore <p.f.mo...@gmail.com> wrote: > On 14 October 2016 at 07:54, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: >>> I think it's probably time for someone to >>> describe the precise syntax (as BNF, like the syntax in

Re: [Python-ideas] Fwd: Fwd: unpacking generalisations for list comprehension

On 14 October 2016 at 07:54, Greg Ewing wrote: >> I think it's probably time for someone to >> describe the precise syntax (as BNF, like the syntax in the Python >> docs at >>

Re: [Python-ideas] Fwd: Fwd: unpacking generalisations for list comprehension

On 13 October 2016 at 21:40, Sjoerd Job Postmus wrote: > However, consider the following spelling: > > l = [from f(t) for t in iterable] > > To me, it does not seem far-fetched that this would mean: > > def gen(): > for t in iterable: > yield

Re: [Python-ideas] Fwd: Fwd: unpacking generalisations for list comprehension

On 13 October 2016 at 20:51, Random832 wrote: > On Thu, Oct 13, 2016, at 15:46, Random832 wrote: >> so, under a similar 'transformation', "*foo for foo in bar" likewise >> becomes "def f(): for foo in bar: yield from foo" >> >> bar = [(1, 2), (3, 4)] >> (*(1, 2), *(3, 4))

Re: [Python-ideas] Fwd: unpacking generalisations for list comprehension

On 13 October 2016 at 15:32, Sven R. Kunze wrote: > Steven, please. You seemed to struggle to understand the notion of the > [*] construct and many people (not just me) here tried their best to > explain their intuition to you. And yet, the fact that it's hard to explain

Re: [Python-ideas] Fwd: unpacking generalisations for list comprehension

On 12 October 2016 at 20:22, David Mertz wrote: > I've followed this discussion some, and every example given so far > completely mystifies me and I have no intuition about what they should mean. Same here. On 12 October 2016 at 20:38, אלעזר wrote: > What is

Re: [Python-ideas] INSANE FLOAT PERFORMANCE!!!

On 12 October 2016 at 11:16, Steven D'Aprano wrote: > On Wed, Oct 12, 2016 at 12:25:16AM +, Elliot Gorokhovsky wrote: > >> Regarding generalization: the general technique for special-casing is you >> just substitute all type checks with 1 or 0 by applying the type

Re: [Python-ideas] INSANE FLOAT PERFORMANCE!!!

On 11 October 2016 at 17:49, Nick Coghlan wrote: > On 12 October 2016 at 02:16, Elliot Gorokhovsky > wrote: >> So I thought, wow, this will give some nice numbers! But I underestimated >> the power of this optimization. You have no idea. It's

Re: [Python-ideas] PEP8 dictionary indenting addition

On 9 October 2016 at 01:25, Steven D'Aprano wrote: > On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote: >> I have an idea to improve indenting guidelines for dictionaries for better >> readability: If a value in a dictionary literal is placed on a new line, it >>

Re: [Python-ideas] Add "equal" builtin function

On 6 October 2016 at 14:45, Filipp Bakanov wrote: > For now there are many usefull builtin functions like "any", "all", etc. I'd > like to propose a new builtin function "equal". It should accept iterable, > and return True if all items in iterable are the same or iterable is

Re: [Python-ideas] async objects

On 5 October 2016 at 21:28, Rene Nejsum wrote: > But, are the runtimes for Python and Erlang that fundamentally different? Is > it Python’s tight integration with C that is the big difference? I don't know *that* much about Erlang, but Python's model is that of a single

Re: [Python-ideas] Improve error message when missing 'self' in method definition

On 5 October 2016 at 18:17, Lisa Roach wrote: > +1 > > I've definitely seen a lot of new users make this error, an improved message > could go a long way. I'm not a new user by any means, and I still regularly make this mistake. Because I've got the experience, I recognise

Re: [Python-ideas] if-statement in for-loop

On 5 October 2016 at 17:26, Nick Coghlan wrote: > Compared to those, locally modifying the token stream to inject ": > INDENT" pairs when the if and for keywords are encountered between an > opening "for" keyword and a closing ":" keyword would be a relatively >

Re: [Python-ideas] if-statement in for-loop

On 5 October 2016 at 05:09, Ken Kundert wrote: > On Wed, Oct 05, 2016 at 03:07:42AM +1100, Steven D'Aprano wrote: >> >> Extra newlines are cheap. Writing >> > > The cost is paid in newlines *and* extra levels of indentation. No extra indentation if you ise "if not

Re: [Python-ideas] if-statement in for-loop

On 4 October 2016 at 08:56, Stephen J. Turnbull wrote: > These are my opinions; I don't claim any authority for them. I just > don't find the proposed syntax as obvious and unambiguous as you do, > and would like to explain why that is so. > > Ken Kundert

Re: [Python-ideas] async objects

On 3 October 2016 at 15:52, Giampaolo Rodola' wrote: > Independently from what the proposed solution is, I think you raised a very > valid concern: the DRY principle. > Right now the stdlib has tons of client network libraries which do not > support the new async model. > As

Re: [Python-ideas] Conditional context manager

Resending, because Google Groups messes up replying to the list :-( On 1 October 2016 at 21:09, Paul Moore <p.f.mo...@gmail.com> wrote: > On 1 October 2016 at 19:07, Neil Girdhar <mistersh...@gmail.com> wrote: >> Sometimes, I want to conditionally enter a context manager. Th

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On 29 September 2016 at 08:08, Stephan Houben wrote: > I just tried with this official Python binary: > Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit > (Intel)] on win32 > > and CTRL-L for sure does clear the window. It just doesn't then move

Re: [Python-ideas] if-statement in for-loop

On 27 September 2016 at 16:54, Erik Bray wrote: > Then following my own logic it > would be desirable to also allow the nested for loop syntax of list > comprehensions outside them as well. I'd say that it's a case where we should either allow arbitrary concatenation

Re: [Python-ideas] Delay evaluation of annotations

On 27 September 2016 at 13:46, Neil Girdhar wrote: > Yes, I understand that, but I don't see how that would help at all with > annotations. Aren't annotations also evaluated at "compile time"? Yes, but a string whose value is a class name is treated as being the same

Re: [Python-ideas] from __pip__ import

On 20 September 2016 at 13:58, Random832 wrote: > On Tue, Sep 20, 2016, at 07:12, אלעזר wrote: >> Moreover, being able to do it programmatically is a security risk, >> since it requires elevated privileges that I don't know how to drop, >> and most people will not think

Re: [Python-ideas] from __pip__ import

On 20 September 2016 at 12:12, אלעזר wrote: > Moreover, being able to do it programmatically is a security risk, since it > requires elevated privileges that I don't know how to drop, and most people > will not think about doing, but a library implementation will. > > So if

Re: [Python-ideas] from __pip__ import

On 20 September 2016 at 11:46, אלעזר wrote: > So it should be something like > > from unsafe.__pip__ import benchmark > > Where unsafe is the hypothetical namespace in which exec(), eval() and > subprocess.run() would have reside given your concerns. In my opinion, it should

Re: [Python-ideas] from __pip__ import

On 20 September 2016 at 00:28, אלעזר wrote: > On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull > wrote: >> >> אלעזר writes: >> >> > Another use case, though I admit not the top priority of anyone here, >> is >> > that of assignment

Re: [Python-ideas] from __pip__ import

On 19 September 2016 at 23:46, אלעזר wrote: >> import pip >> pip.install('attrs') >> import attr > > Please forgive me for my ignorance, but it doesn't work as written - what's > the actual method? As David Mertz said, pip.main(['install', 'attrs']) works right now, but it is

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On 19 September 2016 at 21:35, João Matos wrote: > Hello, > > I don't see why creating a clear command would interfere with dict.clear() > which is a function/method. > > Although my first idea was a clear command, I have no problem if it is a > clear() function from site.py.

Re: [Python-ideas] from __pip__ import

On 19 September 2016 at 21:34, אלעזר wrote: > Paul, I understand what you say, except the part of compatibility with > Python3.5. Of course such a change is targeting future version more than the > current and previous versions. If we have this syntax for Python3.6, users > of

Re: [Python-ideas] from __pip__ import

On 19 September 2016 at 19:52, אלעזר wrote: > Of course it doesn't address the issues - for example, running a python > script from the file manager will result in a failed execution, unexplained. What you're talking about here is deployment of Python "applications" (where in

Re: [Python-ideas] from __pip__ import

On 19 September 2016 at 17:59, Joonas Liik wrote: > using pip from within python is not that difficult already. > as can be seen with a glance to: > http://stackoverflow.com/questions/12332975/installing-python-module-within-code Note that pip does not officially support

Re: [Python-ideas] from __pip__ import

On 19 September 2016 at 18:20, אלעזר wrote: > Obviously > > from __pip__ import "run-lambda>=0.1.0" If we were going to go down this route (which I'm not at all convinced we should) it should be "from __pypi__ import" not "from __pip__ import" (as PyPI is where the code is

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On 19 September 2016 at 13:10, Paul Moore <p.f.mo...@gmail.com> wrote: > > For this particular suggestion, though, I don't think that's the case. > I think it's going to either be something that's accepted into the > stdlib, or something that's rejected as too platform

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On 19 September 2016 at 12:56, Steven D'Aprano wrote: > > For relatively small pieces of functionality, if it is useful enough, we > should just add it to the std lib, and if it isn't, we should just say > it isn't useful enough. We shouldn't condemn supporters of the idea to

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On 19 September 2016 at 03:40, Chris Angelico wrote: > On Mon, Sep 19, 2016 at 12:32 PM, Steven D'Aprano wrote: >> (The fallback if all else fails is easy: get the height of the terminal, >> in lines, and print that many blank lines.) > > Assuming you can

Re: [Python-ideas] Naming convention for Enums

On 14 September 2016 at 12:51, Chris Angelico wrote: > Perhaps the advice needs to be along the lines of: Decide what the > purpose of the enum is, and follow a naming convention accordingly. > Uppercase if you're basically making constants; lowercase if you're > not; etcetera.

Re: [Python-ideas] Fwd: Null coalescing operator

On 12 September 2016 at 21:47, Eric Snow wrote: > Note that there's a subtle difference here when multiple lookups are > involved. Given: > > def f(spam): > return spam().eggs().ham > > With null-coalescing: > > def f(spam): > return

Re: [Python-ideas] if-statement in for-loop

On 11 September 2016 at 10:36, Dominik Gresch wrote: > I've recently found myself writing code similar to this: > > for i in range(10): > if i == 5: > continue > "body" > > which I find a bit ugly. I write code like this quite frequently. However, unlike you I

Re: [Python-ideas] Null coalescing operator

On 10 September 2016 at 18:26, Guido van Rossum wrote: > IMO the key syntax is > simply one for accessing attributes returning None instead of raising > AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to > `foo.bar.baz if (foo is not None and foo.bar is not

Re: [Python-ideas] Shuffled

On 8 September 2016 at 10:34, Arek Bulski wrote: > That wont work because I would have to type the expression that is used as > argument twice in a test. I need shuffled. Enough said. You've probably spent way more time debating shuffled here than you would have needed to

Re: [Python-ideas] Typecheckers: there can be only one

On 7 September 2016 at 22:31, Hugh Fisher wrote: > The average programmer such as myself will expect that if I write code > specifying the type of a variable or whatever it should *do > something*. It's code, I wrote it, it should be interpreted. Reading the documentation

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

On 27 August 2016 at 23:39, Arek Bulski wrote: > They can be used simply out of convenience, like 4K is a shorthand for 4000. > And 9G is definitely easier to write and *therefore less prone to error* > than a full literal. I dispute "less prone to error". Like it or not,

Re: [Python-ideas] SI scale factors in Python

On 25 August 2016 at 19:02, Ken Kundert wrote: > This proposal basically has two parts. One part is that Python should > naturally support printing real numbers with SI scale factors. Currently > there > are three formats for printing real number: %f, %d, %g.

Re: [Python-ideas] SI scale factors in Python

On 25 August 2016 at 09:54, Ken Kundert wrote: > 1G -> 1e+09 > 1M -> 1e+06 > 1k -> 1e+03 While these suffixes are suitable for a scientific context, in a computing context, 1k=1024, 1M=1024*1024 and 1G=1024*1024*1024 make just as much, if not more, sense

Re: [Python-ideas] Let’s make escaping in f-literals impossible

On 20 August 2016 at 04:57, C Anthony Risinger wrote: > The two string parts are string-colored and the x.partition bits would look > like > any other code in the file. It won't look like concatenation at that point. That's entirely subjective and theoretical (unless you've

Re: [Python-ideas] Let’s make escaping in f-literals impossible

On 19 August 2016 at 21:50, C Anthony Risinger wrote: > The only real point I'm trying to make is that expressions within an > f-string are an *escape*. They escape the normal semantics of a string > literal and instead do something else for a while. Therefore, the escaped >

Re: [Python-ideas] Fix default encodings on Windows

On 11 August 2016 at 01:41, Chris Angelico wrote: > I've almost never seen files stored in UTF-32 (even UTF-16 isn't all > that common compared to UTF-8), so I wouldn't stress too much about > that. Recognizing FE FF or FF FE and decoding as UTF-16 might be worth > doing, but it

Re: [Python-ideas] Fix default encodings on Windows

On 11 August 2016 at 00:30, Random832 wrote: >> Python could copy how >> configure_text_mode() handles the BOM, except it shouldn't write a BOM >> for new UTF-8 files. > > I disagree. I think that *on windows* it should, just like *on windows* > it should write CR-LF for

<    3   4   5   6   7   8