Python was a mistake

WTF am I reading
0/10

print() isn't broken, your code is. print does exactly what it's supposed to do, just not what you think it should do (thank god). use sys.stdout.write() instead you LARPer

Gee Holla Forums, it's almost as if python is above your skill level.

Are you retarded or something? echo doesn't take stdin. Use xargs. python3 760661.py | xargs echo

Apparently, sys.stdout is not the same as /dev/stdout. It's probably for comparability with normie OSes.
try: with open("/dev/stdout", 'w') as stdout: stdout.write("poo pee\n")except: passnormie

please be trolling

Meanwhile on superior, modern operating systems
$ python -c 'for i in range(10000): print("Hello, world!")' | head -n1 | cowsay _______________Traceback (most recent call last):< Hello, world! > --------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || File "", line 1, in BrokenPipeError: [Errno 32] Broken pipe

You're trying to fix the test case instead of the bug. It's written that way intentionally.

Hi, Pajeet.

It's a low-level python bug, it doesn't matter what method you use, they'll all fail. And it's used correctly.

Before I get another autistic reply, I should clarify, "it doesn't matter what method you use as long as you aren't bypassing python".

If that "bug" bothers you so much why don't you fix it? Python is open source, here is the repository: hg.python.org/ Go on we're waiting...

This is what causes sensible people to avoid your project.

Nobody is forcing you to use Python. If you don't like it then don't use it.

The UNIX Way(tm) sucks

Can someone explain what is going on here? Why does python bail like this when normal programs don't?

Got any more excuses for this?

ATTENTION
dont use python 3. shit is not even turing complete.

zed shaw pls go

No, it was intentional. Python and other Self derived languages are CIA tools invented to make programmers powerless and brainwash them into postmodern thought.
As programmers we are gods, and the goal of these languages is to take our divinity away from us. They remove the concept of instantiation, ie. divine creation, and substitute it with a process of duplication and mutation.
There is only individuality, and no universalism; it is a denial of intelligent creation, denial of your own intelligence as the creator.
Ask yourself: do you accept your divine role as a programmer? do you prefer to be remain a child who assembles lego bricks? I am thankful that a friend has enlightened me, and I elevated from the latter category.
Python is a particularly vicious language, because it has the deceptive 'class' keyword. Python does not have classes.
Note how these languages perfectly fit with constructivist theory: one object can be created as 'Man', but it can become a 'Fox'/'Cat' chimera if it wants to, because everything is an algorithmic construct. Does it surprise you that so many SJWs use these languages?
If you are a programmer your role is to be a (lesser) God, and if you have dignity you must reject programming languages which deny your divinity.

Is this something to do with interpreted languages in general? Just tried it with Go (both with go run and an executable) and got picrel as a result.

I think interpreters are generally more ok with verbosity when shit hits the fan because all the error messages just need to be kept in the interpreter, not in every single generated binary.

20:44:32 ~> cat hello.rsuse std::io::{self, Write};fn main() { let stdout = std::io::stdout(); let mut stdout = stdout.lock(); for _ in 0..10000 { match stdout.write_all(b"Hello, world!\n") { Ok(()) => {} Err(e) => { if e.kind() == io::ErrorKind::BrokenPipe { break; } else { panic!(e); } } } }}20:44:34 ~> rustc -C opt-level=3 hello.rs20:44:38 ~> ./hello | head -1Hello, world!20:44:46 ~>
is rust the embodiment of the unix way?

here i used a search engine so you didnt have to:
unix.stackexchange.com/questions/84813/what-makes-a-unix-process-die-with-broken-pipe

Also pic related.
[email protected]/* */: cat hello.c #include int main(){ int i; for (i = 0; i < 10000; i++) { printf("Hello World!\n"); } return 0;}[email protected]/* */: gcc hello.c [email protected]/* */: ./a.out | head -1Hello World![email protected]/* */:

Only Lisp can do such beautiful indentation control, other languages BTFO once again.
(require '#:asdf)(import 'uiop:nest)(nest (dotimes (i 10)) (dotimes (j 10)) (dotimes (k 10)) (dotimes (l 10)) (dotimes (m 10)) (format t "Hello, World!~%"))

checked
Is....is that the reason why I can't get comfy with python? When I think programming-like, I always think in C. I also had no problems coding in Java, C++ or VB.net. But with Python it is something different. It just feels....indirect...

what do you have against error handling?

[code][use std::io::{self, Write};

fn main() {
let stdout = std::io::stdout();
let mut stdout = stdout.lock();

(0..10000)
.map(|_| stdout.write_all(b"Hello, World!\n"))
.filter_map(|r| r.err())
.take_while(|e| e.kind() != io::ErrorKind::BrokenPipe)
.next()
.map(|e| panic!(e));
}
/code]

shit. this would not have happened with rust.

ah i see. you just ignore errors. typical c programmer.

BRUTALLY PRACTICAL

well? explain yourselves!

PCJ please leave

...

Nothing when used where it makes sense to use it. Sending "Hello World!\n" to stdout really doesn't require error handling.
Also what is the point of all the map filter list comprehension magic? Doesn't Rust have simple print statement? Let me share this with you:

??????????????????????????????????????
it can fail. so why would you not handle that failure?

some user was complaining about the indentation in my first version

You're not supposed to check errors on stdout, you're supposed to just quietly discard if stdout is closed. The semantics are different than a file write. Lots of shitter langauges made by webdevs layer heavily in file I/O then reuse file writers to handle stdout and you get this bug where depending on write size the pipe chain can fail.

Don't take just a part of my statement to create your response. I said:

God became man, so that man could become a programmer.

can i get some source on that?

it is actually sending hello world 10000 times to stdout. so if you pipe that into head -1 you can stop wasting resources.

That pipes don't fucking work otherwise. This is why lint never warned about not checking the return code from printf.

Let's see if I understood this correctly: When head is done it sends a signal to the program on the other end of the pipe "I'm done you can stop now", but Python is not aware of what this means, so it shits its bed. When run with fewer iterations this crash does not happen, does that mean Python finished writing everything and terminated on its own before head told it to stop?

in my rust version, where i do check errors, pipes do work. can you explain that?

That you've been stupidly verbose to accomplish the exact same thing. Great job, user. Padding work is key to success in the real world.

no. i handled errors like aresponsible programmers and acted accordingly.

Why?

It's entirely lost on you that your code handles the exact same cases but with much more code and massively increased complexity, isn't it? Stay out of systems work, you were meant for Java.

No, Python understands very well what happens, which is why it tells you. It's the C program that shits the bed silently because it doesn't know how to handle it (which is considered acceptable and desired for Unix-style programs that only exist to generate output).

You're too much of a Pajeet to understand why one shouldn't open /dev/stdout to print. Words would be wasted.

alright. i've read the documentation and i found out that because of c programmers not handling their errors SIGPIPE terminates the process by default.
thanks c.

...

i understood signals. i just didnt know that sigpipe terminates the process. that is because i dont use shitty programming languages like c where it is acceptable/possible to ignore errors.

Too lazy to open a man page, eh? Yeah, I can see how this would make rust attractive to some.

no. just not retarded enough to use c.

It wasn't my point.

printf("Hello, World!\n");
let stdout = std::io::stdout(); let mut stdout = stdout.lock(); (0..10000) .map(|_| stdout.write_all(b"Hello, World!\n")) .filter_map(|r| r.err()) .take_while(|e| e.kind() != io::ErrorKind::BrokenPipe) .next() .map(|e| panic!(e));
This is why everyone makes fun of rustfags.

Maybe you could explain your point then, sa-ge kun.

you are retarded

i forgot: that is why every c program has countless amounts of bugs

OK, so let's try again: I read that the SIGPIPE signal is sent when writing on a pipe with no reader. This means that head terminated, and then when Python tried to keep writing the OS sent it the signal because there was nowhere to send the data. Correct?

How about this, is this correct?

I.e. Python terminated before head, so there never was an issue of writing to a pipe with no reader.

What do you mean that C programs shit their bad? Does that mean the C program crashes in reality, but no one noticed because there was no error message, whereas Python did the same thing while providing an error message?

Wouldn't it be better to write C programs to handle this signal as well? Why is it not done? Because if there is no error displayed no one cares?

This happens and is uncatchable because of stdout buffering. It has nothing directly to do with python, really, it's just that python catches a broken pipe signal when it detects it and re-throws it as an exception. The problem with this is that when you do the print, it might not try to flush until the program is ending, so when you are trying to catch the error, your "try" block is long-finished by the time the error is actually thrown.
You'll be able to properly catch it if you do a manual flush, but chances are, this flush will be caught, but leave the data in the buffer, and you'll get the warning again when your program actually closes anyway.

$ cat ./test.py#!/usr/bin/env python3import systry: print("hello world")except BrokenPipeError: print("whoops", file=sys.stderr)$ ./test.pyhello world$ ./test.py | falseException ignored in: BrokenPipeError: [Errno 32] Broken pipe$ cat test2.py #!/usr/bin/env python3import systry: print("hello world") sys.stdout.flush()except BrokenPipeError: print("whoops", file=sys.stderr)$ ./test2.py | falsewhoopsException ignored in: BrokenPipeError: [Errno 32] Broken pipe$

See what I mean? The stdout stream is still re-flushed when the program closes. It's a catchable error, but you'd have to fuck with the signal handling manually if you want to prevent the "Exception ignored" at the end. I'd leave it in, because it is exceptional behavior to dump data into a closed stream regardless.

C dies instantly if you take no countermeasures. Python catches the signal, complains about it, and then dies manually if you take no countermeasures.
C programs can catch the signal if they choose to do so. Many of them don't because dying immediately is a sensible reaction.
A program like cat only exists to send stuff to stdout. If it gets a SIGPIPE it's no longer able to send stuff to stdout so it might as well die. It dies silently because getting interrupted that way tends to be acceptable. If it gets interrupted because head -n 100 stopped listening the user doesn't need to be warned.

fixed

You all have the bad autism.

no error handling. kernel kill your shit
you are responsible for error handling

kill yourself or stop writing buggy code.

You really are broken, aren't you? You literally can't see that explicitly ignoring the error is the same as implicitly ignoring the error.

errors are handled not ignored
lets just ignore it #yolo

What's the problem with that?
The kernel actually has to do less work this way. If caught, it has to tell the program about the SIGPIPE, wait for the exit syscall, and kill the process. If not caught, it can just kill the process right away.
This is something the kernel has to implement anyway. There's nothing wrong with making use of it.

the reason sigpipe exists is because retard c programmers didnt handle their epipe errors.

You shouldn't be forced to do error handling in a hello world program.

No, it's an outdated idea about how to deliver feedback based on how it used to work in assembly where it'd be handled via an ISR. That was '70s UNIX. '80s UNIX went to signal blocking and using return codes for it. '90s UNIX switched to using sendmsg flags for everything but console I/O. '00s Linux switched to copying Microsoft Windows and using message queues for it.
Most of you have at best an understanding of '70s UNIX and have likely never even heard that the modern way is Microsoft's way.

The cleanest way to check errors with stdio is to invoke fflush() at the end of output, and then check ferror() immediately after that. Anything more is unnecessary bloat.

well either that or he's very obviously shitposting.

...

It writes to stderr, user. It's kinda obvious.

What languages do you recommend?

Not him, but the logical language for a God of the machine would be assembly as there is nothing you can't do. Read-only text segments are for mortals.

It's the same fucking device file

Please be a troll. I don't want to think Holla Forums is this far gone.

What do you mean by this? stderr and stdout are different file descriptors, they're only merged together by the terminal.

well you are wrong and retarded

well them the microsoft way is objectively superior.

It is. Most improvements by Linux to UNIX are just stolen features from Windows. Threads, message queues, sendfile / zero copy, async I/O, capabilities, logical volumes, UI priority scheduling like CFS, etc..

I don't think you understand what you're talking about.

I do low level development for a living. Try me, faggot.

Microsoft didn't invent that stuff, and NT kernel is from OS/2. Some of those features are really old too. AmigaOS had message queues in 1985, on cheap micros.

Message queues in relation to delivering this kind of signal, not message queues in general.

I can believe Windows had those things before Linux - I'm no expert, but I know Unix is pretty shitty and Windows is not as uniformly shitty as the average Holla Forums poster claims.
But are they really stolen from Windows in particular? I know Windows didn't invent threads. Does Linux's implementation match Windows' implementation more closely than that of any other operating system or something? I would like to know more.

Linus for years refused to add threads and said we didn't need them as we had processes. It took getting faces rubbed in the shit by Windows programmers demonstrating threaded performance on their OS to get him to give in, and even then, he only initially allowed such a thin set of functionality that cancellation couldn't be properly implemented. While Windows didn't invent threads, it was what pushed the Linux implementation.

s/Windows/Solaris/

Solaris didn't exist back then, and SunOS was a clusterfuck.

Winfags truly are retarded.

...

Meanwhile it's 2017 and fork() on win32 is still slow as dogshit.

In 2017 (3 CYE) we know fork() was a mistake and avoid it as much as possible. Microsoft didn't make that mistake and has no reason to implement it.

Microsoft was a mistake. They set the bar so fucking low that now people are running 70's mainframe OS just so they don't have to use that nasty shit.