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 th
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
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 at
Hmm, very good point.
Flushing standard error is essential:
- This is because output of standard output & standard error are often
redirected to the same file -- frequently the terminal -- and its important
to flush one of them before output to the other (since these are typically
li
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 t
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 calculating a
> >> subclass MRO"?
> >
> > I don't
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 type checks. At least just
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 th
I suppose anything is possible ;) Perhaps I'll try my hand at that next.
But no, I'm limiting the scope to the existing toggles only
(docstrings, __debug__, assert) for this pass.
I am aware of that thread though. I read it a few weeks back when I
was initially researching the existing implementa
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
Sent: Thursday, September 2
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 le
29.09.17 14:40, Steven D'Aprano пише:
Because the two-liner doesn't do what input() does. Testing it at the
interactive interpreter gives me:
py> def myinput():
sys.stdout.write("Name? ")
return sys.stdin.readline()
py> x = myinput()
Steve
py> ? py>
The output isn't displ
On Fri, Sep 29, 2017 at 01:45:05PM +0300, Serhiy Storchaka wrote:
> Why not use just the following two lines?
>
> f.write('Name? ')
> name = f.readline()
Because the two-liner doesn't do what input() does. Testing it at the
interactive interpreter gives me:
py> def myinput():
... s
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
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
print(name
On 29 September 2017 at 11:25, Steven D'Aprano wrote:
> I like it very much.
>
> But as an alternative, perhaps all we really need is a context manager
> to set the std* files:
>
> with open('/dev/tty', 'r+') as f:
> with stdio(stdin=f, stdout=f):
> name = input('Name? ')
>
> print(nam
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 speci
> 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
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.
>>
>> For example:
>>
>> python -N nodebug -N noa
19 matches
Mail list logo
