Re: [Python-ideas] Changes to the existing optimization levels

Oh, I like this idea! I had very briefly considered treating the existing flag as a bitfield, but then promptly forgot to explore that line of thought further. I'll play with that approach next week, see where it takes me, and then report back. Thanks so much for taking the time to think this

Re: [Python-ideas] allow overriding files used for the input builtin

So, I was just thinking, maybe we don't want an errfile arg, but an arg that is a sequence of file objects that need to be flushed before showing the prompt. That's certainly more complicated, but it seems more general if we want to cover this case. Thoughts? wt

Re: [Python-ideas] allow overriding files used for the input builtin

Oh, I thought that stderr was unbuffered. Like the following C program: #include int main() { fprintf(stdout, "stdout0"); fprintf(stderr, "stderr0"); fprintf(stdout, "stdout1"); return 0; } This outputs: stderr0stdout0stdout1 Turns out fprintf in glibc will also implicitly flush

Re: [Python-ideas] allow overriding files used for the input builtin

Steven and Amit, I originally configured the mailing list for digest delivery and can't reply directly to his message. However, I now seen it, I will update the PR with the suggested name changes as soon as my "make test" finishes. FWIW, I've changed to direct message delivery. With regard

Re: [Python-ideas] PEP 560 (second post)

On 29 September 2017 at 08:57, Nick Coghlan wrote: > On 29 September 2017 at 08:04, Ivan Levkivskyi > wrote: > >> How would you feel about calling it "__mro_entry__", as a mnemonic for > >> "the substitute entry to use instead of this object when

Re: [Python-ideas] PEP 560 (second post)

On 29 September 2017 at 10:14, Victor Stinner wrote: > > Title: Core support for generic types > > Would it be possible to mention "typing" somewhere in the title? If > you don't know the context, it's hard to understand that the PEP is > related to type annotation and

Re: [Python-ideas] allow overriding files used for the input builtin

Yes, infile, outfile & errfile would be consistent with python naming convention (also mentioned by Steven D'Aprano above) One of python's greatest strength is its library, the consistency of the library, and how well documented the library is (in fact, I think the library is a greater strength

Re: [Python-ideas] allow overriding files used for the input builtin

I am happy to rename the args. What do you think about infile, outfile, and errfile? FWIW, I did consider "in", "out", and "err", but "in" is a keyword, and I didn't think those quite captured the full meaning. wt From: Amit Green

Re: [Python-ideas] Changes to the existing optimization levels

On 9/28/17 2:48 PM, Diana Clarke wrote: Hi folks: I was recently looking for an entry-level cpython task to work on in my spare time and plucked this off of someone's TODO list. "Make optimizations more fine-grained than just -O and -OO" There are currently three supported optimization

Re: [Python-ideas] allow overriding files used for the input builtin

Hello, it seems that there are two independent issues – a way to temporarily replace all sys.std* streams, and a way to use the special interactive readline logic for arbitrary terminal-like file. I thought that OP's concern was the latter. In that case shouldn't there just be a way to produce an

Re: [Python-ideas] allow overriding files used for the input builtin

29.09.17 08:53, Wren Turkal пише: This is meant to turn code like the following: orig_stdin = sys.stdin orig_stdout = sys.stdout with open('/dev/tty', 'r+') as f:     sys.stdin = f     sys.stdout = f     name = input('Name? ') sys.stdin = orig_stdin sys.stdout = orig_stdout

Re: [Python-ideas] allow overriding files used for the input builtin

On Fri, Sep 29, 2017 at 05:53:58AM +, Wren Turkal wrote: [...] > The basic idea is to add fin, fout, and ferr file object parameters > and default to using what is used today when the args are not > specified. I believe this would be useful to allow captures input and > send output to

Re: [Python-ideas] PEP 560 (second post)

> Title: Core support for generic types Would it be possible to mention "typing" somewhere in the title? If you don't know the context, it's hard to understand that the PEP is related to type annotation and type checks. At least just from the title. Victor

Re: [Python-ideas] Changes to the existing optimization levels

On 29 September 2017 at 05:02, Antoine Pitrou wrote: > On Thu, 28 Sep 2017 12:48:15 -0600 > Diana Clarke > wrote: >> >> 2) Added a new command line option N that allows you to specify >> any number of individual optimization flags. >> >>

Re: [Python-ideas] PEP 560 (second post)

On 29 September 2017 at 08:04, Ivan Levkivskyi wrote: > On 28 September 2017 at 08:27, Nick Coghlan wrote: >> >> On 27 September 2017 at 19:28, Ivan Levkivskyi >> wrote: >> > If an object that is not a class object appears in the

Re: [Python-ideas] allow overriding files used for the input builtin

I'm fine with the idea in general of extra keyword parameters to the input function. A few points: Your example code, needs try/catch to match what the input with parameters does -- and yes, its way nicer to be able to use it the example you have shown than play games with try/catch (Personally