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

51–60 of 168 posts

Re: A bite of Python

#51

Post by marklgr »

masklinn wrote: post #39
marklgr wrote: post #31

Earlier quoted context omitted.

> 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-...

It's so crude that, again, it looks like implementation details having been promoted to specs. Field visibility and name mangling done with very magic underscores just doesn't look right, to me.

Re: A bite of Python

#52

Post by sangnoir »

michaelfeathers wrote: post #28
blowski wrote: post #11

Earlier quoted context omitted.

It's not an anomaly, but it can be a surprise for people who don't understand what it does. For example, they use asserts for validation and then the validation doesn't work in production. It's absolutely right the way it works, but it's still a gotcha for the audience this blog post is aimed at.

> but it's still a gotcha for the audience this blog post is aimed at. Would be nice if they had a pointer to the reason, however.

Unless the article was updated after your comment: the reason is right there in the article:

"However, Python does not produce any instructions for assert statements when compiling source code into optimized byte code (e.g. python -O). That silently removes whatever protection against malformed data that the programmer wired into their code leaving the application open to attacks.

The root cause of this weakness is that the assert mechanism is designed purely for testing purposes, as is done in C++. Programmers must use other means for ensuring data consistency."

Re: A bite of Python

#53

Post by coldtea »

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…

>Then imagined it is.

Only in the most pedantic and useless sense of the term.

Asserts are not just some random imagination, they are added based on the program's specifications and expected/desired functionality and constraints. The CS term for those kind of constraints are "invariants", and asserts are a way to be notified if those invariants are violated.

>unless you make them become real.

Only there are no assurances for that. If the invariants in your program were somehow guaranteed to be "real" then you wouldn't need asserts.

Asserts are there because whether you tried to make your invariants "become real" or not, you'll still miss things, have bugs, have unexpected interactions with code/systems outside your control etc. So they are there to tell you about those misses.

>Point taken. Unfortunately, logging errors or aborting the program won't make assertions magically become true, though.

Assertions are not expected to "magically become true" -- just to (a) inform about anytime they are violated, and, optionally, (b) not be violated and still have the program continue to run.

Re: A bite of Python

#54

Post by viraptor »

mrswag wrote: post #46
viraptor wrote: post #29

Earlier quoted context omitted.

> but come on, if an attacker has write access to your code Why is this relevant for this article? The article doesn't say anything about attackers having write access to the source.

It's in their threat model under 'Module injection': > The mitigation is to maintain secure access permissions on all directories and package files in search path to ensure unprivileged users do not have write access to them.

Ok, I see. To be honest I read that as "keep your PYTHONPATH sane". I think that's a bit different from worrying about someone having write access to the source, but still related - point taken.

Re: A bite of Python

#55

Post by aikah »

the last one (script injection) isn't limited to python but any language that make use of template engine. escaping variables should be the default behavior.

Now I like python, it has many useful libraries, in fact it is one of the language that has the most libraries for any purpose. I wish, even as a dynamically typed language, it was stricter sometimes though.

Re: A bite of Python

#56

Post by pvdebbe »

One Python gotcha that has bitten people in my company a lot:

    fun_call('string1',
             'string2'
             'string3')
That is, missing commas and subsequent string concatenations can lead to nasty errors. I wish Python didn't nick this from C and would have just enforced the use of + to concat over-length strings, if they need to be split to multiple lines.

Re: A bite of Python

#57

Post by coldtea »

catnaroek wrote: post #43
JonnieCache wrote: post #34

Earlier quoted context omitted.

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

> If you have the process quit it definitely stops them from being false though. The assertion remains false for the final process state, before the process quits. Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process.

>The assertion remains false for the final process state, before the process quits.

Which is inconsequential. Programmers don't expect automatic "recovery" from assertions, they expect them to notify them of the violated constraint, and/or to ensure that a program wont go on and use a value that violates an assertion further down -- which program termination achieves.

>Outside of the process, the assertion is simply meaningless (neither true nor false), because the assertion's free variables are only bound inside the process.

Captain Obvious?

Re: A bite of Python

#58

Post by marklgr »

guyzmo wrote: post #37
marklgr wrote: post #31

Earlier quoted context omitted.

> 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 get full well what it does, but I find the syntax "magic" and not very attractive. Why no special keyword for visibility, proper namespaces etc.?

In c++ and likes, I know there's a vtable somewhere, and I get why there must be one for virtual funcs, but I don't want to deal with it directly, it's the compiler job. Same for Python, I know it must prevent fields from getting clobbered when inheriting, but I don't want to be exposed to its mangling or whatever other mechanism it uses.

Re: A bite of Python

#59

Post by masklinn »

marklgr wrote: post #51
masklinn wrote: post #39

Earlier quoted context omitted.

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-...

It's so crude that, again, it looks like implementation details having been promoted to specs. Field visibility and name mangling done with very magic underscores just doesn't look right, to me.

> Field visibility

It has nothing whatsoever to do with field visibility.

Re: A bite of Python

#60

Post by masklinn »

marklgr wrote: post #58
guyzmo wrote: post #37

Earlier quoted context omitted.

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 get full well what it does, but I find the syntax "magic" and not very attractive. Why no special keyword for visibility, proper namespaces etc.? In c++ and likes, I know there's a vtable somewhere, and I get why there must be one for virtual funcs, but I don't want to deal with it directly, it's the compiler job. Same for Python, I know it must prevent fields from getting clobbered when inheriting, but I don't wan…

> Same for Python, I know it must prevent fields from getting clobbered when inheriting, but I don't want to be exposed to its mangling or whatever other mechanism it uses.

Python does not prevent anything, it gives the developer a name mangling tool, it's up to the developer whether they want to use it or not. By default, identical names will conflict and you will clobber supertype fields or methods.

Post reply on HN