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

141–150 of 168 posts

Re: A bite of Python

#141

Post by viraptor »

wyldfire wrote: post #138
viraptor wrote: post #113

Earlier quoted context omitted.

Which version of pypy are you using? I can't reproduce the issue with 5.1.2 (ubuntu packaged one). The config uses YAML format. Regardless, config errors should be more verbose. I raised https://bugs.launchpad.net/bandit/+bug/1621552

EDIT: nevermind, couldn't reproduce it with a new virtualenv. Whatever problem occurred in that virtualenv likely wasn't that interesting (wild guess is a package name collision). pypy2-v5.3.1-linux64 / [PyPy 5.3.1 with GCC 4.8.2] If you can't reproduce it with that tarball I'll dig deeper to see the mechanism of failure, maybe it's not pypy and it's just something local to my config or venv.

Checked the same tarball (downloaded from bitbucket) and still can't repro. Just in case, what I'm doing is:

   cd path/to/bandit
   virtualenv -p path/to/pypy venv
   venv/bin/pip install -r./requirements.txt -e .
   venv/bin/bandit-config-generator -o tmp_file
   venv/bin/bandit -c tmp_file -r path/to/some/project

Re: A bite of Python

#142

Post by wyldfire »

viraptor wrote: post #141
wyldfire wrote: post #138

Earlier quoted context omitted.

EDIT: nevermind, couldn't reproduce it with a new virtualenv. Whatever problem occurred in that virtualenv likely wasn't that interesting (wild guess is a package name collision). pypy2-v5.3.1-linux64 / [PyPy 5.3.1 with GCC 4.8.2] If you can't reproduce it with that tarball I'll dig deeper to see the mechanism of failure, maybe it's not pypy and it's just something local to my config or venv.

Checked the same tarball (downloaded from bitbucket) and still can't repro. Just in case, what I'm doing is: cd path/to/bandit virtualenv -p path/to/pypy venv venv/bin/pip install -r./requirements.txt -e . venv/bin/bandit-config-generator -o tmp_file venv/bin/bandit -c tmp_file -r path/to/some/project

I did something similar, yes. I cannot reproduce this with a new virtualenv anymore. It may have been due to odd bits in my environment (likely not worth further investigation).

    virtualenv -p `which pypy` ~/pypy_env
    source ~/pypy_env/bin/activate
    # indeterminate  changes to this venv
    pip install bandit
    bandit-config-generator -o tmp_file
    bandit --help # "The following sets..." is empty
    bandit -c tmp_file -r path/to/some/project # gives the error regarding config file parse failure
I can reproduce the parse error given the nearly empty config file, but it's not clear to me whether the parse error is expected in this case or not.

    $ echo -e 'tests:\nskips:\n{}' > parse_err.cfg
    $ bandit -c parse_err.cfg .
[main] ERROR parse_err.cfg : Error parsing file.

Re: A bite of Python

#143

Post by ubernostrum »

skywhopper wrote: post #129
xapata wrote: post #126

Earlier quoted context omitted.

But Python is OO from the bottom up. Unlike Java, everything in Python is an object. Perhaps your experience with objects in other languages has given you a different mental model for what an object is. I find Python objects to be more straightforward than in other languages, especially because classes are objects, too.

If it really is OO, then the global `len()` function and like explicitly declaring "self" in method declarations makes it _feel_ bolted on (to me). Why is `len()` special? I immediately question what other basic operations aren't methods, but global functions. And as for method declaration, if you aren't satisfied with implicit self, I much prefer Go's choice of having you declare the self reference for methods befor…

If it really is OO

Python is a multi-paradigm language in the sense that it does not explicitly force the programmer to write all code in a particular way. So, for example, Python does not forbid the existence of standalone functions, or the execution of functions without looking them up through a class of which they happen to be a member.

But given that it is inescapably true that every function call in Python is translated to a call of a method of an object, it's hard to argue that it isn't "really" OO.

Re: A bite of Python

#144

Post by ubernostrum »

xapata wrote: post #137
skywhopper wrote: post #129

Earlier quoted context omitted.

If it really is OO, then the global `len()` function and like explicitly declaring "self" in method declarations makes it _feel_ bolted on (to me). Why is `len()` special? I immediately question what other basic operations aren't methods, but global functions. And as for method declaration, if you aren't satisfied with implicit self, I much prefer Go's choice of having you declare the self reference for methods befor…

You can find explanations for both those questions in the design FAQ. The explicit self came from Modula-3. https://docs.python.org/2/faq/design.html#why-must-self-be-u... The explanation for len is a little lacking. https://docs.python.org/2/faq/design.html#why-does-python-us... Guido once explained further in an email to the mailing list. I've forgotten some of it, but the gist is that he didn't want anyone to acci…

almost everything is a method

Not "almost". Just "everything is a method", in terms of function calls. Even user-defined standalone functions. Consider:

    def my_func(arg):
        return arg + 5
The following are equivalent, and show how things work:

    my_func(3)
and

    my_func.__call__(3)
and

    types.FunctionType.__call__(my_func, 3)

Re: A bite of Python

#145

Post by dr_zoidberg »

Singletoned wrote: post #105
noobiemcfoob wrote: post #102

Earlier quoted context omitted.

In my experience and implied by the rising popularity of python, you would be among the minority. Personally, I find python to be the most clear of any language I've worked with, most resembling natural language in the way I typically speak. Do you have some examples of how you find it self-contradictory? Here's an example of its expressiveness a colleague and mine I discussing the other day: Python: [os.remove(i.loc…

I've always found the fork bomb page on Wikipedia to be a good example of different languages. https://en.wikipedia.org/wiki/Fork_bomb The Python is example is both short and obvious, whereas the other examples tend to be either cryptic or complicated.

I'd slightly change the wikipedia article to use "while True:" instead of "while 1:". Also, the C# is also quite readable (though very verbose).

Re: A bite of Python

#146

Post by ubernostrum »

marklgr wrote: post #81
masklinn wrote: post #73

Earlier quoted context omitted.

Is conventional, it doesn't do anything at the language level.

Which is my point, it's still roll-your-own, with some magic when necessary. I don't want to make a fuss about it, I mean, it's great for tinkering or small projects, but I prefer when my compiler works harder for me and actually enforces what is intended (bar some runtime reflection for very special cases).

Or it's just a philosophy that you happen not to like, which doesn't make it objectively bad or wrong. There's room for people to have different tastes and preferences.

Re: A bite of Python

#147

Post by amyjess »

tomato123 wrote: post #96
amyjess wrote: post #75

On the float behavior: I really wish Python 3 had the sense to do what Perl 6 did and interpret all literals with decimal points (except those that use scientific notation) as Fractions instead of floats. That would solve all these floating-point errors without requiring significant modification of code, plus Python 3 would be the perfect time to do it because they're already throwing out backwards compatibility beca…

That would kill Python for scientific use. Also, while nice, Fractions have their own pitfalls due to potentially catastrophic runtime behavior.

> That would kill Python for scientific use.

If Python used the Perl 6 model, you could still use floats by writing your literals in scientific notation, so if you want floating-point performance, you can still get it. For example, 2.2 would be a Fraction, but 2.2e0 would be a float. I don't want to eliminate floats from the language, just hide them from average users by default.

And it's not like rationals-as-default are just some weird Perl 6-ism. Haskell does the same thing, and the language is fairly well-received.

> Also, while nice, Fractions have their own pitfalls due to potentially catastrophic runtime behavior.

Elaborate?

Re: A bite of Python

#148

Post by sitkack »

dfox wrote: post #94
sitkack wrote: post #70

Earlier quoted context omitted.

I would argue that one should never use '-O' it also strips doc strings from running code. Not really an `optimization` but they had do something right? One couldn't run __unoptimized__ in production could they?

I assume that almost nobody uses -O in production.

Probably the same folks who don't test their code probably also remove their assertions in production.

Re: A bite of Python

#149

Post by breatheoften »

p4wnc6 wrote: post #101
humanrebar wrote: post #78

Earlier quoted context omitted.

That is certainly one approach, and the article agrees. > The root cause of this weakness is that the assert mechanism is designed purely for testing purposes, as is done in C++. However, C and C++ are perhaps unique in how much undefined behavior is possible and in how simple it is to create. Inserting into a vector while iterating through it, for instance. Or an uninitialized pointer. That's why many C++ experts be…

All of the C/C++ experts I know, as well as people who have interviewed me coming from primarily that background, have always been among the most adamant to stress that an application crashing unexpectedly should never happen and is always the wrong outcome. I imagine they would say that your statement about crashing vs. e.g. launching the missiles is a false dilemma. You don't crash and you don't incorrectly launch…

I'm a big fan of fatal errors and crashing the program with a stack trace:

1. Stack trace at point of a contract violation tends to capture the most relevant context for debugging -- the faster it is to discover and debug an issue the easier it is to fix 2. Interacting code has to become sufficiently coupled to preserve "sane program state" -- an exception may or may not be recoverable -- a fatal error never is and there's no point in building code to try to recover. If the programmerer has to design the interaction among program components to avoid fatal errors then there must be fewer total states in the program vs a program which recovers from errors -- this makes the program easier to reason about. 3. On delivering good User experience -- id rather have clear and obvious crashes which are more likely to include the most relevant debug information -- than delivering the user some kind of non-crash but non-working, behavior (with possibly unknown security consequences) which may take longer to get noticed and fixed as a result of an error handling mechanism that deliberately _tries_ to paper over programming problems ...

I've actually modified third party libraries I've used to remove catch blocks or replace error handling within with fatal errors -- when dealing with unknown code it really can vastly speed up the learning process and the understanding based on observational behavior ... -- especially in understanding the behavior around edge cases.

Re: A bite of Python

#150

Post by xapata »

ubernostrum wrote: post #144
xapata wrote: post #137

Earlier quoted context omitted.

You can find explanations for both those questions in the design FAQ. The explicit self came from Modula-3. https://docs.python.org/2/faq/design.html#why-must-self-be-u... The explanation for len is a little lacking. https://docs.python.org/2/faq/design.html#why-does-python-us... Guido once explained further in an email to the mailing list. I've forgotten some of it, but the gist is that he didn't want anyone to acci…

almost everything is a method Not "almost". Just "everything is a method", in terms of function calls. Even user-defined standalone functions. Consider: def my_func(arg): return arg + 5 The following are equivalent, and show how things work: my_func(3) and my_func.__call__(3) and types.FunctionType.__call__(my_func, 3)

I'm not certain, but I think the C API can avoid that. I've learned to say "almost" because every time I say Python can't X, someone shows me it can.
Post reply on HN