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

Reasons Python Sucks

hackerfactor.com

Post reply on HN
Print view View original

451–460 of 554 posts

Re: Reasons Python Sucks

#451

Post by tom_mellior »

pdonis wrote: post #382
pstch wrote: post #303

Earlier quoted context omitted.

> Passing a variable to a function means passing a particular namespace binding from the caller's namespace to the function's local namespace. I don't think that's true, as the function will never be able to change the binding, and only gets a reference to the value of the binding. If the function was passed a particular namespace binding, it would be able to change this binding's value, and that's not possible. I ag…

> the function will never be able to change the binding, and only gets a reference to the value of the binding More precisely, the function's arguments when it is called are a set of values for variables taken from the caller's namespace, which then get bound to the corresponding names in the local namespace. You're right that "passing the binding" doesn't really describe that process very well.

> the function's arguments when it is called are a set of values for variables taken from the caller's namespace

Again, this is very obviously false, since a call need not involve any variables at all:

    foo(1, 2, "three")
The function's arguments when it is called are a set of values taken from the caller, yes. And those values are obtained from evaluating expressions that may involve variables. But they might not. Saying that the values are "a set of values for variables taken from the caller's namespace" is wrong.

You are mistaken, and your talk of namespace bindings is just obfuscation. Python arguments are passed by pointer. Python namespaces bind names to pointers. There is no "binding" object passed in a function call.

Re: Reasons Python Sucks

#452

Post by [deleted] »

pfranz wrote: post #270
acdha wrote: post #181

Earlier quoted context omitted.

What would you expect it to do differently in those cases? That seems like the API is following how most people would think about those operations as you'd expect in a language which isn't trying to be immutable.

I thought it was interesting that Ruby, by convention, used an exclamation mark to convey that a function would mutate. I haven't used Ruby all that much to see how well that works at scale.

[deleted]

Re: Reasons Python Sucks

#453

Post by tom_mellior »

pdonis wrote: post #384
tom_mellior wrote: post #142

Earlier quoted context omitted.

> Python variables aren't names for storage locations to begin with; they're namespace bindings. Can you explain the difference? What is a "namespace binding"? When accessing a variable's value, the interpreter's code sure looks like it treats the variable name as the name of a storage location. > Passing a variable to a function means passing a particular namespace binding "Passing a variable to a function" is not a…

> What is a "namespace binding"? An entry in a Python dictionary that is the namespace for the current scope. For example, to repeat a response I gave to someone else upthread, compare a variable assignment in C and Python. In C: int i = 17; Means "set aside one int's worth of storage and fill it with the bit pattern for the number 17". In Python: i = 17 means "create an int object with the value 17 and bind it in th…

In other words, the latter means "set aside one pointer's worth of storage and fill it with the bit pattern for the pointer pointing to the value 17 (which you may have to create first)". Variables have values. In C those values may be ints, floats, pointers, whatnot. In Python (at the implementation level) those values are pointers to objects.

Re: Reasons Python Sucks

#454

Post by be_erik »

unethical_ban wrote: post #446
geezerjay wrote: post #250

Earlier quoted context omitted.

> The "it's so cool to shit on Java" thing served an important purpose and is probably close to being retired I don't know in which world you live in, but in the real world Java is by far the dominant platform for web services.

Does that apply to any web service that meets the following criteria? * Created in the last 5 years * Built by an organization without a large Java heritage I bet that number goes waaaay down, way quick.

For sure it may, but I wonder how many of those decisions will be regretted? Java is a fast portable language with a decent type system and a bevy of time tested libraries. It certainly isn't perfect, but modern Java is a decent development environment (and this comes from a Rubyist). I suspect only Go can match its speed, productivity, and safety.

Re: Reasons Python Sucks

#455

Post by saagarjha »

Zopieux wrote: post #416
nicoburns wrote: post #133

Earlier quoted context omitted.

Indeed. My personal bugbear is lack of multiline lambdas. I use these all the freaking time in JS and it's infuriating that I can't in python. At the end of the day it's a minor complaint of course.

Though it doesn't take that much of an effort to just name your callback function and pass it as an argument. Python functions are first-class "objects" that can be passed around, use them! I've always found Python lambdas to be uncanny, weird and error prone. It's kinda syntactic sugar for expression-only defs with counterintuitive scope rules. I would recommend just not using them and fall back to named functions.…

This is extremely heavyweight syntax for something I like to use as a lightweight construct. If I wanted a function, I would make something a function.

Re: Reasons Python Sucks

#456

Post by saagarjha »

nicolashahn wrote: post #166
nicoburns wrote: post #133

Earlier quoted context omitted.

Indeed. My personal bugbear is lack of multiline lambdas. I use these all the freaking time in JS and it's infuriating that I can't in python. At the end of the day it's a minor complaint of course.

I think it makes more sense in a language where you have to write callbacks all the time. I consider it a feature in Python, because by using `def` you're forced to imbue the function with meaning by providing it a name. Otherwise, it's just reading through a potentially complicated function without any context of what it's supposed to be doing.

It also makes sense if you're trying to do any sort of functional programming.

Re: Reasons Python Sucks

#457

Post by saagarjha »

bakery2k wrote: post #165
setpatchaddress wrote: post #145

Earlier quoted context omitted.

Agreed. After indentation-as-syntax -- which I've always hated, and I've been using Python since version 1.5 -- lack of switch statement is my #1 problem with Python.

> indentation-as-syntax -- which I've always hated What would you prefer? C-style syntax? Ruby-style `end end end`?

C-style syntax. I'm not a fan of using something that is inherently invisible to scope my code, and be yelled at if it's not quite right (I'm writing this in Python because I want it to be done quickly; just leave my code style alone and I'll fix it later!)

Re: Reasons Python Sucks

#458

Post by daotoad »

davedx wrote: post #123
fhood wrote: post #100

Earlier quoted context omitted.

It's funny how far off the author was, because there are genuine things to complain about with python, though they may not be exclusive to python. I regularly wish python required some sort type indication for function parameters, because dealing with libraries that take complex objects as function parameters can be an absolute nightmare. I wish python had some equivalent to the switch statement that didn't involve w…

> I regularly find myself wanting to write something of the form do_x() if a.y() This is stupid, but I still kind of want it since do_x() if a.y() else do_y() is valid cough maybe you should be programming in Ruby ;)

Or Perl 5. `do_stuff() if $a->y();` is a common idiom.

Or Perl 6. `do-stuff() if $a.y;` is the Perl6 version. You can even declare your variables to be sigil-less so you end up with `do-stuff() if a.y;` if you want. See my Perl6 Advent Calendar article for a quick tour of the language, available docs, with practical examples focusing on using Perl6's novel features to write a self documenting command line script.

https://perl6advent.wordpress.com/2018/12/16/

I've written code in everything from assembly to ML, Java, and Prolog. Perl6 is the only language I've used that I would "mind-expanding". The more I use it, the I realize how radical its design is.

Re: Reasons Python Sucks

#459

Post by pdonis »

tom_mellior wrote: post #451
pdonis wrote: post #382

Earlier quoted context omitted.

> the function will never be able to change the binding, and only gets a reference to the value of the binding More precisely, the function's arguments when it is called are a set of values for variables taken from the caller's namespace, which then get bound to the corresponding names in the local namespace. You're right that "passing the binding" doesn't really describe that process very well.

> the function's arguments when it is called are a set of values for variables taken from the caller's namespace Again, this is very obviously false, since a call need not involve any variables at all: foo(1, 2, "three") The function's arguments when it is called are a set of values taken from the caller, yes. And those values are obtained from evaluating expressions that may involve variables. But they might not. Sa…

> this is very obviously false, since a call need not involve any variables at all

True, in which case the values would just be constants. But they will still get bound to names in the function's local namespace.

> You are mistaken

No, I left out a case which, it seemed to me, did not affect the main point I was making. If you want to make clear that that's a possible case, fine, you've done so. But you haven't refuted (or even engaged with) my main point at all.

> your talk of namespace bindings is just obfuscation

No, it's a very important difference between what Python variables mean and what variables in language like C mean. You might think the difference is unimportant, but not everyone agrees with you.

> Python arguments are passed by pointer. Python namespaces bind names to pointers.

At the C level inside the interpreter, yes, this is true: every "object", such as the 1, 2, and "three" in your example, is a pointer to a C struct containing the object's data (sometimes including further pointers). Again, that doesn't affect my main point at all.

> There is no "binding" object passed in a function call.

I already agreed to this in my response to pstch upthread (the post of mine you originally replied to). Once more, it doesn't affect my main point at all.

Re: Reasons Python Sucks

#460

Post by pdonis »

tom_mellior wrote: post #453
pdonis wrote: post #384

Earlier quoted context omitted.

> What is a "namespace binding"? An entry in a Python dictionary that is the namespace for the current scope. For example, to repeat a response I gave to someone else upthread, compare a variable assignment in C and Python. In C: int i = 17; Means "set aside one int's worth of storage and fill it with the bit pattern for the number 17". In Python: i = 17 means "create an int object with the value 17 and bind it in th…

In other words, the latter means "set aside one pointer's worth of storage and fill it with the bit pattern for the pointer pointing to the value 17 (which you may have to create first)". Variables have values. In C those values may be ints, floats, pointers, whatnot. In Python (at the implementation level) those values are pointers to objects.

> In other words, the latter means "set aside one pointer's worth of storage

Set aside one pointer's worth of storage on the heap, yes; not on the stack or in the program's data segment, which is what the C statement I gave does.

> and fill it with the bit pattern for the pointer pointing to the value 17 (which you may have to create first)"

Which has no analogue whatever in the C version.

Also, you completely left out the part about creating an entry in the namespace dictionary, which also has no analogue whatever in the C version, and which involves additional memory allocations.

Post reply on HN