Python
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
> 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 ?
>>54869152
Flush stdin before reading from it again.
First of all, switch to Python 3.
>>54869159
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.
>>54869184
but.... everything fun is in 2.7
>>54869152
>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)
>>54869228
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
>>54869281
I think you're going to have to show us what you're working with. Sounds like you might be doing something fucky.
>>54869299
Sounds to me like they want to be able to keymash in between two different inputs if the program is off doing something else.
>>54869281
>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.
>>54869222
It's not 2010 anymore
>>54869329
>Looking around it seems there's no easy platform-independent to do the first.
fuck , that sucks
>>54869364
This explains it a little better and gives some suggestions.
http://stackoverflow.com/questions/24582233/python-flush-input-before-raw-input
>>54869329
>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 anon is trying to accomplish rather than the roadblock they are at.
>>54869184
>>54869344
8 years later and still no one uses it
>>54869281
>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.
>>54869418
>pypidownloadstats
um
>>54869453
also see webm
>>54869418
This is actually proof that the python community is fucking autistic and not so much that python 3 is bad.
>>54869482
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.
>>54869476
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?
>>54869482
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 /g/ 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.
>>54869497
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.
>>54869228assert input != None
>>54869497
>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.
>>54869511
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 >>54869299 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.
>>54869533
>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?
>>54869534
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.
>>54869571
I was more thinking in terms of VC++ actually.
Yes the compatibility layer for applications is very good.
>>54869533
>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
>>54869561
>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
>>54869594
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 #
>>54869628
this works. much much much simpler than whatever the OP is asking for, trying to get around the shell's buffer behavior.
>>54869375
thanks man whatever that code is it works
>>54869152
I love this guy
