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

Why Python keeps growing, explained

github.blog

Post reply on HN
Print view View original

441–450 of 459 posts

Re: Why Python keeps growing, explained

#441

Post by PaulHoule »

CE02 wrote: post #169

One thing I’d add to this conversation, though I’m certain it’s already been stated: As many have mentioned, there is a large subset of the user base that uses Python for applied purposes in unrelated fields that couldn’t care less about more granular aspects of optimization. I work as a research assistant for international finance faculty and I would say that compared to the average Hackernews reader, I’m technologi…

Python is ideal for the non-professional programmer who wants to put their skills and knowledge on wheels.

Re: Why Python keeps growing, explained

#442

Post by jerpint »

milliams wrote: post #109

This was already posted at https://news.ycombinator.com/item?id=35000415 , I don't know why it didn't detect the duplicate. I'll repost my comment from there: This is a strange article. It's got the talking point about Python that we were hearing about 10 years ago - "tired of those pesky curly brackets in Java, try this new language you might not have heard of: Python!". Who reading the GitHub blog has not heard of…

The section that explains why python is good for AI talks about pybrain, a library that seems to date from 10 years ago. I’m pretty well versed in most ml frameworks and never heard of it. Last update to the website looks to be 2010. Weird to feature that and PyTorch as examples of ML libraries. No mention of sklearn which is vastly more popular

Re: Why Python keeps growing, explained

#443

Post by jerpint »

wodenokoto wrote: post #189
milliams wrote: post #109

This was already posted at https://news.ycombinator.com/item?id=35000415 , I don't know why it didn't detect the duplicate. I'll repost my comment from there: This is a strange article. It's got the talking point about Python that we were hearing about 10 years ago - "tired of those pesky curly brackets in Java, try this new language you might not have heard of: Python!". Who reading the GitHub blog has not heard of…

It's doubly weird, since the antigravity module doesn't have a fly attribute, and it "does its thing" on import. https://github.com/python/cpython/blob/main/Lib/antigravity....

Very suspect

Re: Why Python keeps growing, explained

#444

Post by sqlserver2008 »

mixmastamyk wrote: post #438
sqlserver2008 wrote: post #419

Earlier quoted context omitted.

>Two ways to delimit blocks is redundant. It isn't redundant though because without delimiting symbols for a code block you lose the ability to have your code autoformatted in certain situations. Here's a trivial example to illustrate the point: def example(): x = 5 print("Hello world") What's the mistake here? Depending on whether the print is part of the function, it should either be indented or have a newline befo…

The first example is a syntax error, which must be fixed, and takes a second. Not a PITA, just a part of normal day to day refactoring. I see how a formatter could help you out in this specific situation. However you are trading typing of redundant characters every few seconds and readability per minute, to avoid an issue that happens once or twice a day, per week on a mature project. In other words we generally don’…

>first example is a syntax error

The code runs so it's most definitely not a syntax error. May be against PEP styling rules, but it is valid Python code.

>which must be fixed, and takes a second.

And that was my earlier point. The responsibility to get the code in a state where it is formatted AND runnable falls entirely on you, as this work cannot be entirely delegated to software when the syntax uses significant indentation. And the fixing of the code would require you to reanalyze the code's semantics before you would even know what the appropriate fix is. Of course it would only take a second for a trivial example like the one I used, but real Python codebases aren't going to be trivial.

>typing of redundant characters

It actually doesn't require any additional typing as compared to Python. In modern editors the closing brace is automatically added when you type the opening brace. So you simply type the opening brace and hit enter, just as you would type the colon and hit enter in Python. Even the space between the closing parenthesis and opening brace in the function header is added automatically by formatters.

>readability per minute

Seems pretty subjective but I don't think there's a significant difference in readability between Python and braced languages, or even between Python and languages that use block delimiters other than braces, like Ruby. A lot of readability comes down to personal familiarity with a language.

>we generally don’t significantly reorganize code nearly as much as reading, tweaking, adding features etc.

Totally agree, and I think this is one of the big problems of software development. People generally don't want to make big reorganizational changes to code and instead prefer to change the code only through additions. As a result, legacy projects tend to accrete layers of cruft over time whether it is necessary or not. I'm not a Jonathan Blow fanboy by any means, but I recently saw this clip which I think makes a good point. https://www.youtube.com/watch?v=ubWB_ResHwM

Re: Why Python keeps growing, explained

#445

Post by mixmastamyk »

sqlserver2008 wrote: post #444
mixmastamyk wrote: post #438

Earlier quoted context omitted.

The first example is a syntax error, which must be fixed, and takes a second. Not a PITA, just a part of normal day to day refactoring. I see how a formatter could help you out in this specific situation. However you are trading typing of redundant characters every few seconds and readability per minute, to avoid an issue that happens once or twice a day, per week on a mature project. In other words we generally don’…

>first example is a syntax error The code runs so it's most definitely not a syntax error. May be against PEP styling rules, but it is valid Python code. >which must be fixed, and takes a second. And that was my earlier point. The responsibility to get the code in a state where it is formatted AND runnable falls entirely on you, as this work cannot be entirely delegated to software when the syntax uses significant in…

    $ python3
    Python 3.10.6 (...snip...)

    >>> def example():
    ...         x = 5
    ...     print("Hello world")
      File "", line 3
        print("Hello world")
                            ^
    IndentationError: unindent does not match any outer indentation level
Sort of an odd video, haha. But I liked the guy... think we could be friends. ;-)

It's idea is sort of neither here nor there however, regarding whitespace blocks. That we "rent" more often than own is just a reality of the system we find ourselves in. (For example cheap products sell more than expensive ones and that is expected and ok.)

I don't want to optimize my projects around large refactors since I only do it a few times per project, but will read it often.

Re: Why Python keeps growing, explained

#446

Post by compressedgas »

mixmastamyk wrote: post #445
sqlserver2008 wrote: post #444

Earlier quoted context omitted.

>first example is a syntax error The code runs so it's most definitely not a syntax error. May be against PEP styling rules, but it is valid Python code. >which must be fixed, and takes a second. And that was my earlier point. The responsibility to get the code in a state where it is formatted AND runnable falls entirely on you, as this work cannot be entirely delegated to software when the syntax uses significant in…

$ python3 Python 3.10.6 (...snip...) >>> def example(): ... x = 5 ... print("Hello world") File " ", line 3 print("Hello world") ^ IndentationError: unindent does not match any outer indentation level Sort of an odd video, haha. But I liked the guy... think we could be friends. ;-) It's idea is sort of neither here nor there however, regarding whitespace blocks. That we "rent" more often than own is just a reality of…

That's because the REPL has the additional restriction of requiring a definition (or any top level indented block) to end with an blank line. This restriction does not apply when running code from a file.

Re: Why Python keeps growing, explained

#447

Post by mixmastamyk »

compressedgas wrote: post #446
mixmastamyk wrote: post #445

Earlier quoted context omitted.

$ python3 Python 3.10.6 (...snip...) >>> def example(): ... x = 5 ... print("Hello world") File " ", line 3 print("Hello world") ^ IndentationError: unindent does not match any outer indentation level Sort of an odd video, haha. But I liked the guy... think we could be friends. ;-) It's idea is sort of neither here nor there however, regarding whitespace blocks. That we "rent" more often than own is just a reality of…

That's because the REPL has the additional restriction of requiring a definition (or any top level indented block) to end with an blank line. This restriction does not apply when running code from a file.

    $ python3 foo.py
      File "~/Desktop/foo.py", line 4
        print("Hello world")
                            ^
    IndentationError: unindent does not match any outer indentation level
I didn't understand your statement exactly, but it doesn't seem to be true in any case.

Re: Why Python keeps growing, explained

#448

Post by compressedgas »

mixmastamyk wrote: post #447
compressedgas wrote: post #446

Earlier quoted context omitted.

That's because the REPL has the additional restriction of requiring a definition (or any top level indented block) to end with an blank line. This restriction does not apply when running code from a file.

$ python3 foo.py File "~/Desktop/foo.py", line 4 print("Hello world") ^ IndentationError: unindent does not match any outer indentation level I didn't understand your statement exactly, but it doesn't seem to be true in any case.

The file:

  def foo():
     bar = 3
  print ('4')
runs fine when called as a file but when pasted into Python's REPL results in an error:

  >>> def foo():
  ...    bar = 3
  ... print ('4')
    File "", line 3
      print ('4')
          ^
  SyntaxError: invalid syntax
However with a blank line after the definition

  def foo():
     bar = 3

  print ('4')
results in:

  >>> def foo():
  ...    bar = 3
  ... 
  >>> print ('4')
  4

Re: Why Python keeps growing, explained

#449

Post by mixmastamyk »

compressedgas wrote: post #448
mixmastamyk wrote: post #447

Earlier quoted context omitted.

$ python3 foo.py File "~/Desktop/foo.py", line 4 print("Hello world") ^ IndentationError: unindent does not match any outer indentation level I didn't understand your statement exactly, but it doesn't seem to be true in any case.

The file: def foo(): bar = 3 print ('4') runs fine when called as a file but when pasted into Python's REPL results in an error: >>> def foo(): ... bar = 3 ... print ('4') File " ", line 3 print ('4') ^ SyntaxError: invalid syntax However with a blank line after the definition def foo(): bar = 3 print ('4') results in: >>> def foo(): ... bar = 3 ... >>> print ('4') 4

I see now. The issue was pasting the snippet into a terminal added an extra level of indentation from the post (pre must be indented). This changed the result.

Re: Why Python keeps growing, explained

#450

Post by di456 »

Yoric wrote: post #410
di456 wrote: post #257

Earlier quoted context omitted.

> the features that make Python quite good at prototyping make it rather bad at auditing for safety and security What's an example that makes it bad? Is it a case of the wrong tool for the job? For example I understand that garbage collection languages shouldn't be used with real time systems like flight controllers.

There are many examples, but let's speak for instance of the fact that Python has privacy by convention and not by semantics. This is very useful when you're writing unit tests or when you want to monkey-patch a behavior and don't have time for the refactoring that this would deserve. On the other hand, this means that a module or class, no matter how well tested and documented and annotated with types, could be enti…

Thanks for this, super insightful perspective
Post reply on HN