38 comments

[ 2.1 ms ] story [ 92.5 ms ] thread
(comment deleted)
Ok now this truly awful

  print(1, 2) # prints "2 2"
Pointers are bad but this implementation is broken. There is no way to do this using pointers IRL.
1 and 2 are objects in Python. You can change the field corresponding to the int value of the field for the object pointed to by 1. Even worse small ints are cached, so now you have changed 1 for the entire interpreter.
One small step towards Fortran
(comment deleted)
(comment deleted)
It's absolutely pure unadulterated evil, deliberately overwriting memory owned by the interpreter in ways that the author knows will result in corruption, bizarre behaviour and crashes.

It's also a 13 year old awesomely messing around with cpython internals in their spare time. Bravo!

I don’t understand the problem people have with pointers, they are an amazing tool. And the negative attitude towards manual memory allocation just seems like laziness to me and even suggests a lack of understanding for both what you’re doing and how computers work.
Laziness is one of the cardinal virtues of a programmer.
There is good laziness:

  - Don't Repeat Yourself
  - Don't Reinvent the Wheel
  - ...
And bad laziness:

  - I don't want to do this because I need to be careful
  - I don't need/want to understand what's going on as long as it works
  - ...
The latter is what leads to most issues/bugs.
I wouldn't cast 'I don't want to do this because I need to be careful' as laziness, it's just being smart/pragmatic. Take that statement in the context of home grown cryptography instead of pointes and it'll make sense. People might have different thresholds for the need to be careful.

Also, with regards to 'I don't need/want to understand what's going on as long as it works' ...isn't not needing to understand the implementation the entire point of creating abstractions?

> I don't want to do this because I need to be careful

The topic here is more about: how reliable is the worst version of the weakest part of your team on this particular development tool? People life can be filled with terrible events that will have side effect on their vigilance at work. And even just counting on the catastrophe that just happened in production, pressure can make you trade scrupulosity for immediate operational efficiency.

I prefer tools that help me to reduce cognitive load.

The others being Impatience and Hubris.
They're a good tool for sure, but I take issue with your characterization. It's not "laziness" or "lack of understanding" that makes them ill-suited for python, but just that they're too expressive for the goals python seeks to fulfill.

I suspect that people's aversion to manual memory management is more an expression of that semantic mismatch rather than some kind of reveling in their own stupidity.

(comment deleted)
Why not?

Because pointers are broken and harmful.

Once compiled to assembly, every data is accessed via pointers. Every data structure is represented with pointers. Almost everything is a pointer.

According to you, all softwares are broken and harmful?

Programming languages can provide a safe interface to pointers (just like Rust do with `Box<>`, `Rc<>`, `Arc<>`, or C++ in some ways with `shared_ptr<>` and `unique_ptr<>`).

Also, "Why not?" here clearly means "I did it for fun" / "Because I can".

Cmon. In a good faith reading, he means as a matter of developer access. And he's not wrong as concerns what 90+% of devs have to get done at their jobs.
Yes pointers are hard to get right. No, depicting it as "broken and harmful" is not ok, even with good faith reading.
Exactly. Should have written "access to raw pointers for developers".
Its the same crowd that goes screeching when they see „goto“ eyeroll
Wait until you see people saying "exceptions are glorified goto".

Basically, every statement of the form "X is broken and harmful" either don't understand X, or have read it somewhere else without giving a second thought.

X exists because it had some use at some point. Y and Z are implemented thanks to X. Now we no longer need to do X by hand. This does not make it broken nor harmful.

You could extrapolate this right down to the binary layer.

Are lower level technology’s more dangerous, no.

Are they more difficult to get right? Yes.

Do we want to stop worrying about finicky correctness or pointers and worry about building more complex things? Probably yes also.

> Do we want to stop worrying about finicky correctness or pointers and worry about building more complex things? Probably yes also.

Which is why I mentioned the safe higher-level interfaces provided by programming languages.

Yet, I think it's important to learn about the lower level technology to better understand the higher level technology.

And definitely stop spitting on lower level technologies.

I’ll notify the kernel team of this development.
if you don’t understand how to use pointers you probably shouldn’t be writing software.
Respectfully I disagree. Machines with heap are not the only model of computation, and the fact that useful software has been written in python suffices to prove this.

I mean... are we to throw away all code in numerical methods because the canonical, automatic memory management is good enough for most professionals?

No True Scotsman would dream of doing such a thing.
Wow! Thanks! :D

Please ignore the haters, they have little to no idea. :D

(comment deleted)
Cool project, did you learn anything interesting from implementing it?

I think I see that the malloc functionality is provided by some DLLs that you import: https://github.com/ZeroIntensity/pointers.py/blob/master/src... I haven’t tried that yet any lessons learned on that or was it pretty straightforward to import some DLLs and start using them in python?

use C++ instead of python. there you go.
> Why not?

See, Prometheus: the gods really don't fancy this line of questioning.

Note that this is even more interesting/impressive based on OPs age:

“I am a 13 year old developer who likes writing libraries, webservers, and command line apps.”

(comment deleted)
What an absolute terror. I love it.