Python

> Python
> variable = raw_input()

if you accidentally press enter twice or more quickly then it fills the next raw_input()

any way to make Python "forget" the enters ?

Other urls found in this thread:

stackoverflow.com/questions/24582233/python-flush-input-before-raw-input
twitter.com/NSFWRedditImage

Flush stdin before reading from it again.

First of all, switch to Python 3.

tried sys.stdin.flush()
doesn't seem to do anything

variable = ""
while variable.strip() == "":
variable = input("when I jack off while coding sometimes I hit the enter key twice")


Or just quit hitting enter more than once.

but.... everything fun is in 2.7

>if you accidentally press enter twice or more quickly then it fills the next raw_input()
>it fills the next raw_input
that's exactly how input is supposed to work. if you want to prevent it from accepting empty strings, check for it (see pic related)

I don't want to prevent it from accepting empty, I want it to not fill the next raw_input()

> that's exactly how input is supposed to work.

I disagree because between inputs you can do stuff and it shouldn't influence the next one

but I'm not a python

I think you're going to have to show us what you're working with. Sounds like you might be doing something fucky.

Sounds to me like they want to be able to keymash in between two different inputs if the program is off doing something else.

>I disagree
Doesn't really matter if you agree or not. Programs use input buffers, you are loading crap into a buffer to be read by your program and then asking the program to magically know not to use some of it. You need to either clear it before reading again or anticipate garbage entry. Looking around it seems there's no easy platform-independent to do the first. You've already been given the second.

It's not 2010 anymore

>Looking around it seems there's no easy platform-independent to do the first.

fuck , that sucks

This explains it a little better and gives some suggestions.
stackoverflow.com/questions/24582233/python-flush-input-before-raw-input

>Sounds to me like they want to be able to keymash in between two different inputs if the program is off doing something else.

I agree but I'm thinking that there is probably a better way to approach the situation if we know exactly what user is trying to accomplish rather than the roadblock they are at.

8 years later and still no one uses it

>I disagree because between inputs you can do stuff and it shouldn't influence the next one
i don't think you understand how your terminal works/ it's going to buffer input and pass it along to the shell when it becomes responsive again. try the following: type
$ sleep 10
$ echo "delayed oh fuck"


it's going to echo that when sleep ends. that's just how it works. it's not python.

if you want to discourage stupid users from doing stupid things, you can design stuff like confirmations when the input doesn't match expected values.

>pypidownloadstats
um

also see webm

This is actually proof that the python community is fucking autistic and not so much that python 3 is bad.

one of the biggest reasons is that there are a ton of libraries for 2.7 that aren't ported to 3. Gotta stick with what works.

okay I get it

but there should be a way to tell *Python* to spend 100 milliseconds collecting all the possible inputs and discarding them before asking for the next one, right?

I don't know where he got that from because I'm having trouble finding download stats, but for one thing, the image name suggests it's pypi usage, and assuming pypi is a representative sample is insanely stupid.

for another, my hunch is that those are stats from a single package - people can publish packages and get stats on what versions people are using, etc...
if that's the case, then this isn't just the unrepresentative sample of pypi users; it's a sample of that niche group.

it's *almost* as though some people on Sup Forums have no concept of statistics or sampling as a way of speaking to the broader population, and we're left to deal with their diarrheal conclusions.

Gotta stick with what works to make things that work which then stick to what work.

It's a vicious cycle. Say what you want about Microshaft, but they move forward and don't give a damn if they break backwards compatibility if they have to.

assert input != None

>there are a ton of libraries for 2.7 that aren't ported to 3
of the 200 most downloaded packages, only ~30 of them (a little less than that) are not python 3 compatible. the problem is "internal" legacy code. if you've written 2000+ lines of code (which frankly isn't a LOT of code), then what could possibly be offered in python 3 (or anything, for that matter) that would make you change?

couple that with the very very very long sunset period that tech tends to have, and nobody feels a particularly strong fire under their asses to learn and migrate. this won't be an issue in 10 years, but then again it will be when we're dealing with python 3 vs 4 or whatever.

yes, but at this point it's becoming really dubious that this is the best way to accomplish what you want to do. if you're not willing to take a step back and post the bigger picture (as requested) i'm not going to continue helping. it sounds like you want us to help engineer something overly complex for what i suspect is a pretty stupid, trivial problem.

>Say what you want about Microshaft, but they move forward and don't give a damn if they break backwards compatibility if they have to.
are you new to this world? you can run windows 95 programs in windows 10 under compatibility mode. it's that insane fear of leaving legacy code out in the cold that kept windows back for so long (and continues to do so).

maybe you're thinking of OS X, which breaks third-party shit on a nearly annual basis?

assert would raise an AssertionError. you could use try/except, but then how would you loop back around to ask for input again... unless you use a while loop?

Don't engineer exceptions into your code.

I was more thinking in terms of VC++ actually.

Yes the compatibility layer for applications is very good.

>Say what you want about Microshaft, but they move forward and don't give a damn if they break backwards compatibility if they have to.
i think you missed the entire point (and ironically, the great weakness of) of .NET

>yes, but at this point it's becoming really dubious that this is the best way to accomplish what you want to do.
it sounds like you don't know how to do it bro

I'm sure we could work out how to do it, but you're asking me to crabwalk backwards through an opening in a wall and I want you to confirm for me that you don't just need someone to help you open a door and walk through it like a normal person.

Here's a solution OP, let the user end a line with a # or something. That way when I press enter twice it wont accept the second one without a #

this works. much much much simpler than whatever the OP is asking for, trying to get around the shell's buffer behavior.

thanks man whatever that code is it works

I love this guy