Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A bite of Python

access.redhat.com

Post reply on HN
Print view View original

31–40 of 168 posts

Re: A bite of Python

#31

Post by marklgr »

guyzmo wrote: post #22

The part of the article about an issue with name mangling of private fields is somehow misleading. The feature is just some syntactic sugar. When within a class, private fields such as: class Foo: def __init__(self): self.__bar are accessible from within other methods of class Foo as `self.__bar`. But that's just syntactic sugar, the real name of `self.__bar` is `self._Foo__bar`. So from the outside "world", includin…

> The feature is just some syntactic sugar.

I would not call it "syntactic sugar", but rather a leak of implementation details. It could be deliberate, like Perl did for its OO (showing the entrails of all its objects), but it's not particularly sugary-sweet-yummy.

Re: A bite of Python

#32

Post by tehwalrus »

Having written code in Python for a few years, I've come across most of these (some of the ways to hack builtins/modify the code on a function reference were new to me).

However, it had also never occurred to me to make anything I cared about the security of in python. Perhaps this article is aimed at people who are writing system utilities for linux distributions, and are considering Python? Presumably some such utilities are written that way already.

It comes down to doing a proper security analysis before you define the requirements of the software: Specifically what attack vectors you want to defend against. A valid conclusion for some types of software, given the list of "bugs" in the post, would be don't write it in Python. (Indeed, I have done exactly this before writing 200 lines of C instead of 20 lines of Python.)

Re: A bite of Python

#33

Post by viraptor »

tehwalrus wrote: post #32

Having written code in Python for a few years, I've come across most of these (some of the ways to hack builtins/modify the code on a function reference were new to me). However, it had also never occurred to me to make anything I cared about the security of in python. Perhaps this article is aimed at people who are writing system utilities for linux distributions, and are considering Python? Presumably some such uti…

> A valid conclusion for some types of software, given the list of "bugs" in the post, would be don't write it in Python.

Do you have some specific types in mind? I know some types of protection are not reachable from python directly and require native modules, but I'm not sure what would cause you to drop Python altogether. I'd be interested to hear some examples.

Re: A bite of Python

#34

Post by JonnieCache »

catnaroek wrote: post #24
coldtea wrote: post #20

Earlier quoted context omitted.

Neither "real" nor "imagined". An asserts checks DESIRED constraints. > AFAICT, an assert only tells me what you wish your program did, but that has absolutely no bearing on what it will actually do. Depending on the implementation, an assert can either merely log or absolutely stop a program that doesn't pass its test, so it very much has a bearing on what the program will actually do.

> An asserts checks DESIRED constraints. Then imagined it is. Your desires are totally a part of your imagination, unless you make them become real. > Depending on the implementation, an assert can either merely log or absolutely stop a program that doesn't pass its test, so it very much has a bearing on what the program will actually do. Point taken. Unfortunately, logging errors or aborting the program won't make a…

If you have the process quit it definitely stops them from being false though. I thought that was the point of assert()?

Re: A bite of Python

#35

Post by hacker42 »

alex-yo wrote: post #2

I wouldn't call it 'traps'. I would call it 'read and understand documentation before writing code' like: what is 'is' operator, or how floats behave in EVERY programming language, or why you should sanitize EVERY user input. So, basically, I can write such a list for every language I know.

That's like saying people shouldn't read FAQs because they should rather read the documentation. These things aren't actually mutually exclusive.

Re: A bite of Python

#36

Post by masklinn »

viraptor wrote: post #19
commenter23 wrote: post #16

The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. It's because the comparison operators are defined for every value. That is, "True https://docs.python.org/3.0/whatsnew/3.0.html#ordering-compa... ). This is also not a case of Python doing something useful, like with '"foo"*2'. The result of the comparison is defined, but it'…

> The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. Do you mean this example? (it's the only one I can find about floating point comparison) > 2.2 * 3.0 == 3.3 * 2.0 It's definitely due to accuracy error. (rather than type comparison) How would you explain it otherwise?

Accuracy problems in floating-point computations: https://en.wikipedia.org/wiki/Floating_point#Accuracy_proble...

Re: A bite of Python

#37

Post by guyzmo »

marklgr wrote: post #31
guyzmo wrote: post #22

The part of the article about an issue with name mangling of private fields is somehow misleading. The feature is just some syntactic sugar. When within a class, private fields such as: class Foo: def __init__(self): self.__bar are accessible from within other methods of class Foo as `self.__bar`. But that's just syntactic sugar, the real name of `self.__bar` is `self._Foo__bar`. So from the outside "world", includin…

> The feature is just some syntactic sugar. I would not call it "syntactic sugar", but rather a leak of implementation details. It could be deliberate, like Perl did for its OO (showing the entrails of all its objects), but it's not particularly sugary-sweet-yummy.

Yes, it is intended and fully part of the philosophy behind the language's design (as shown in PEP-20, aka the Zen of Python):

> Explicit is better than implicit

So there's no "leaking" of implementation details, because the implementation shall always be fully exposed.

As said in a sibling post, the private fields are just public fields, which are not documented as part of the public API and start with a `_`.

And as I said in the parent post, the reason to use the name mangling mechanism on top of that is to ensure that those variables won't be used by descendants in the class hierarchy, when a given class is intended to be subclassed by a peer.

The the sugar /is/ actually sugary-sweet-yummy, as it's preventing potential faults from people who blindly subclass stuff they haven't read the source code of.

Re: A bite of Python

#38

Post by viraptor »

masklinn wrote: post #36
viraptor wrote: post #19

Earlier quoted context omitted.

> The point the article makes on comparing floating point values and the floating point type is true, but it's not because of any rounding error. Do you mean this example? (it's the only one I can find about floating point comparison) > 2.2 * 3.0 == 3.3 * 2.0 It's definitely due to accuracy error. (rather than type comparison) How would you explain it otherwise?

Accuracy problems in floating-point computations: https://en.wikipedia.org/wiki/Floating_point#Accuracy_proble...

My bad, wrote rounding not accuracy. (corrected now) But my point was that it's not related to weak typing as the parent seems to suggest.

Re: A bite of Python

#39

Post by masklinn »

marklgr wrote: post #31
guyzmo wrote: post #22

The part of the article about an issue with name mangling of private fields is somehow misleading. The feature is just some syntactic sugar. When within a class, private fields such as: class Foo: def __init__(self): self.__bar are accessible from within other methods of class Foo as `self.__bar`. But that's just syntactic sugar, the real name of `self.__bar` is `self._Foo__bar`. So from the outside "world", includin…

> The feature is just some syntactic sugar. I would not call it "syntactic sugar", but rather a leak of implementation details. It could be deliberate, like Perl did for its OO (showing the entrails of all its objects), but it's not particularly sugary-sweet-yummy.

It's not an implementation detail, it is a deliberate, specified and documented feature of the language dedicated to namespace conflict resolutions in the context of inheritance.

ref: https://docs.python.org/2/reference/expressions.html#atom-id...

ref: https://docs.python.org/2/faq/programming.html#i-try-to-use-...

Re: A bite of Python

#40

Post by guyzmo »

mkesper wrote: post #27
guyzmo wrote: post #22

The part of the article about an issue with name mangling of private fields is somehow misleading. The feature is just some syntactic sugar. When within a class, private fields such as: class Foo: def __init__(self): self.__bar are accessible from within other methods of class Foo as `self.__bar`. But that's just syntactic sugar, the real name of `self.__bar` is `self._Foo__bar`. So from the outside "world", includin…

"Private" fields and methods should use one underscore. Two underscores are for name mangling issues and __method__ is for "magic" methods.

Well, private fields are all members starting with an underscore and that are not publicised in the documentation.

/That/ includes double underscores mangled members and and "magic" methods.

Post reply on HN