Understanding Python through its builtins • Hacker News Board

Re: Understanding Python through its builtins

#131

Post by iwwr » Mon, Oct 11, 2021, 5:21 AM UTC

pansa2 wrote: post #119

btown wrote: post #118

Earlier quoted context omitted.

https://blog.peterlamut.com/2018/11/04/python-attribute-look... is a great overview of how this works. Start with the summary at the end! The really cool thing about this, how descriptors have their __get__ called, is that methods are implemented this way. So when you access instance.method(), it’s a normal lookup for the attribute named “method”, which is (normally) itself a descriptor, so the __get__ magic is calle…

Good article, thanks. It's worth pointing out that the summary (class hierarchy data descriptor > instance `__dict__` > class hierarchy other) only applies when looking up a normal attribute on a normal object: * Special-method lookup (e.g. of `__add__` when you do `a + b`) works differently because it doesn't look at the instance `__dict__`, only the class hierarchy. * Lookup on a class works differently because as…

You might even say that without classes python would be a simpler language, while keeping almost all its power :)

Re: Understanding Python through its builtins

#132

Post by fulafel » Mon, Oct 11, 2021, 6:09 AM UTC

Blikkentrekker wrote: post #54

adrusi wrote: post #52

Earlier quoted context omitted.

Random access into a clojure vector is going to need more memory lookups than conventional sequential buffer array (I don't recall the constants used in the implementation, I think it's either 4 or 8 lookups). But when you're indexing into the vector sequentially, the memory layout plays rather well with memory caching behavior, and most lookups are going to be in L1 cache, just like they would be in a conventional a…

How? I don't see how that's possible. The actual data of a Pvector is not in contiguous memory but scattered however the JVM wills it, and on top of that in order to find which address to retrieve it, an algorithm that runs in logarithmic time with respect to the length of the vector must be used opposed to a constant time one. How can most lookups end up in L1 cache if an element that is 32 indices removed is statis…

I think you are talking about arbitrary stride sequential access, and the comment you were responding to meant stride-1 access. But conventional arrays also fare poorly with arbitrary stride access, though probably they have an advantage with small strides close to the Clojure persistent vector chunk size.

Re: Understanding Python through its builtins

#133

Post by anttihaapala » Mon, Oct 11, 2021, 6:11 AM UTC

klyrs wrote: post #121

sireat wrote: post #43

I am a pretty average Python programmer(5 years teaching, 15 years writing). I still wonder what was the reasoning for allowing creation of local objects with the same name as builtins. Okay it can be nice to redefine pprint as print I suppose. Still how many sum, list, min, max, dict(!) have been erroneously redefined in beginner tutorials and beginner code. From my experience sum and list suffer the most. Sure ther…

False = None = True Is probably the most ridiculous thing for a language to support. And yet...

... and yet, it is a SyntaxError. False = True = None works in Python 2, and it is just because the separate Boolean type was a late addition.

Re: Understanding Python through its builtins

#134

Post by thrdbndndn » Mon, Oct 11, 2021, 6:28 AM UTC

>As a bonus, this also adds support for adding two MyNumber classes together:

Merely having `__add__` (without `__radd__`) is enough to add two MyNumber classes together in your case.

>It mostly exists to support type annotations,

The link for "type annotations" is broken.

Re: Understanding Python through its builtins

#135

Post by masklinn » Mon, Oct 11, 2021, 7:06 AM UTC

robot_no_419 wrote: post #114

BiteCode_dev wrote: post #86

Earlier quoted context omitted.

Unfortunatly you often can't use -o because of the 3rd party libs that didnt' get the memo and use assert for error checking. We still have -X dev and sys.flags but it's runtime only.

Unless I'm misunderstanding, they are wrapping their asserts in try/catch blocks? That's... yikes.

Most likely they just `assert` error conditions and let that blow up as error reporting, rather than write a full conditional and raise a custom exception.

I’ve been guilty of that in my own code when I just want to tell myself about an error.

Re: Understanding Python through its builtins

#136

Post by tyilo » Mon, Oct 11, 2021, 7:07 AM UTC

> Python has exactly 6 primitive data types (well, actually just 5, but we’ll get to that). 4 of these are numerical in nature, and the other 2 are text-based. Let’s talk about the text-based first, because that’s going to be much simpler.

What is your definition of a primitive data types? All of these have object as a superclass, so I wouldn't call them primitive data types in python.

Maybe there is just 1 primitive type: type? Or none at all?

Re: Understanding Python through its builtins

#137

Post by wmanley » Mon, Oct 11, 2021, 7:11 AM UTC

klyrs wrote: post #121

sireat wrote: post #43

I am a pretty average Python programmer(5 years teaching, 15 years writing). I still wonder what was the reasoning for allowing creation of local objects with the same name as builtins. Okay it can be nice to redefine pprint as print I suppose. Still how many sum, list, min, max, dict(!) have been erroneously redefined in beginner tutorials and beginner code. From my experience sum and list suffer the most. Sure ther…

False = None = True Is probably the most ridiculous thing for a language to support. And yet...

    $ python2 -c 'False = None = True'
      File "", line 1
    SyntaxError: cannot assign to None

    $ python3 -c 'False = None = True'
      File "", line 1
    SyntaxError: cannot assign to False

Re: Understanding Python through its builtins

#138

Post by ripe » Mon, Oct 11, 2021, 7:24 AM UTC

Thank you for writing the post. Newbie question about “nonlocal” from your example:

    def outer_function():
        x = 11

        def inner_function():
            nonlocal x
            x = 22
            print('Inner x:', x)

        inner_funcion()
        print('Outer x:', x)

I get how the example works, but don’t see the point of the declaration? If I just left out the “nonlocal x” line, wouldn’t the example still work the same?

Re: Understanding Python through its builtins

#139

Post by ekimekim » Mon, Oct 11, 2021, 7:34 AM UTC

ripe wrote: post #138

Thank you for writing the post. Newbie question about “nonlocal” from your example: def outer_function(): x = 11 def inner_function(): nonlocal x x = 22 print('Inner x:', x) inner_funcion() print('Outer x:', x) I get how the example works, but don’t see the point of the declaration? If I just left out the “nonlocal x” line, wouldn’t the example still work the same?

Python assumes that all assignments assign to the current scope. So by default when you reach "x = 22", it would create a new variable called "x" in the inner_function() scope which overrides the variable "x" in the outer_function() scope. So when you print "Inner x" you would only be printing the inner_function() version of x, not the outer_function() version, which would remain at 11.

Re: Understanding Python through its builtins

#140

Post by BiteCode_dev » Mon, Oct 11, 2021, 8:11 AM UTC

zarzavat wrote: post #95

BiteCode_dev wrote: post #91

Earlier quoted context omitted.

Nope, I just remember my server crashing years ago so I stopped ever since. Would be interesting to scan pypi and check if this is still a thing. Maybe create a bot warning lib authors.

Seems like a better idea would be to make a separate flag "--remove-assertions" for people who desire that.

"-o" is mostly "--remove-assertions" already, so that wouldn't help.

While today's use case for assert is unit testing, the actual killer feature of the keyword is that it's removed only from prod.

The idea is that you can write things like function contracts, that are expensive, but only exist in dev.

Now, if one of you dependencies use assert for something they expect to still be in prod, which is the problem we are talking about in the first place, "-o" or "--remove-assertions" will strip their assert too, breaking their code, and hence, yours since it depends on it.