Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
First, why there is no end in python? Second, the fact that there is tabs and there is no end make python the best readable/beautiful language, why they do not introduce these characteristics in other languages?
You'll have to ask Guido van Rossum about why he didn't introduce an end construct, since it's a language design issue - but as you say, there are aesthetic reasons not to do so.
The reason this isn't introduced to existing languages is that there are already billions of lines of code written in them, and you don't want to force people to change all of that just for some aesthetics.
Why not have it as a backward-compatible change, such as e.g. allowing languages with C-like syntax to have the opening { but not the closing }? Probably because programmers in those languages are very used to it and might actually prefer it to not having closing marks, and probably don't see this as a useful feature. Also, it would be necessary to make it a per-file decision, as a mixture of explicit and implicit block ends would be extremely confusing and probably not parseable.
As a matter of fact, Python itself contains a joke about this, which I believe reflects the authors' opinion on the matter:
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
(__future__ is a module which you can use to import certain pieces of functionality that were introduced in newer versions of Python and have been backported to older versions.)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am looking for resources that help me interpret python documentation effectivley. In particular, I am reading through the pythondocx module documentation, but am finding it hard to understand some sections.
As an example, when I read the Style Objects Section
, I am confused by lines such as class docx.styles.styles.Styles and what it is actually saying.
Any ideas on what I can do the to interpret documentation better?
I honestly think reading pythondocx module documentation is a bit of overkill.
The hard part of reading python documentation is understanding the specific logic of how objects and builtin's are organized in python. The best place to start, IMHO, is the index Python 3.8.1 documentation together with standard library and collections.
Even if you had studied other common languages before, like Java and C#, their API's are laid out in a different style. Each takes its own time for the reader to get used to. The python docs were written to be self-explanatory and after an initial learning curve that isn't especially steep the docs start making lots of sense.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Should i annotate types in my unit tests functions?
What also with overridden django methods like save and get or post functions in generic view?
This is arguably an opinion question but I think that there is a generally accepted answer, which is roughly "No".
One way of categorising programming languages is into statically typed and dynamically typed. Statically typed languages are generally more robust, especially for "programming in the large", and dynamically typed languages have advantages ito programming speed, and in modelling problems where it is beneficial to be able to accept data of various types. Type hints try to strike a balance. The rough rule being: if you are using the dynamic nature of the language to achieve something, don't worry about annotating it. If however, you are writing code that doesn't make specific use of the dynamic nature of the language, annotate
Perhaps to make the point clear, consider that if you DO annotate everything, well then why not just use Cython? Same effort but you actually get some speed up as well. The reason people use Python with annotations instead of Cython is that some problems are naturally better solved without specifying types.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Im not positive on the terminology here, so that may explain why searching on my own yielded no results.
I was just curious if there is a widely accepted, general method to writing a module in python. Obviosuly people prefer splitting things into segmented .py scripts, importing when needed, and packing it all into a folder.
What I want to know: Is there a general method to how/when/why we stop writing things together in one .py and begin a new one (And i mean other than obvious things like... one script .py for the main job, and then a preferences.py to handle reading/writing prefs)
You should split your code into multiple modules when it begins to be unwieldy to keep it all in one module. This is to some extent a matter of taste. Note that it may unwieldy for the code author (i.e., file is too big to navigate easily) or for the user of the library (e.g., too many unrelated functions/classes jammed together in the same namespace, hard to keep track of them).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Or, should we have a virutal environment and continue to run this on 2.3?
EDIT: I take it back; porting between different 2.x versions is not trivial. Note that raise "Oops" worked in 2.5 but not in 2.6. However, the port should be pretty easy; for one thing, I believe that anything that would break in version n+1 will warn in n, so you should be able to step through the versions. Alternatively, just change over and let your test suite catch everything =).
Given the choice, you might as well rewrite to Python 2.7, which is the latest (and final) 2.x version.
Here are the things that I can find that might break, from looking at the docs (2.6, 2.5, 2.4):
Previously valid variable names are now reserved keywords:
with
as
Some builtins are shadowed:
set
frozenset
reversed
sorted
bytes
You can no longer raise a string.
There are probably others.
You need to weigh up the pros and cons of doing the port
2.5/6/7 gives you better programming structures, more libraries, etc.
but you won't know how much work is involved with the port until you try it.
I would imagine it's worthwhile spending say a day or two on the port
If you feel you are getting nowhere after that time, careful reconsider whether the advantages will still make the port worth doing
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Which is preferred
def method(self):
or
def method( self ):
With spaces in the parenthesis.
Check out PEP 8. It says to do the first one.
The common reference for Python style is PEP8, see: http://www.python.org/dev/peps/pep-0008/
To answer your question specifically, this is under "Pet Peeves":
Avoid extraneous whitespace in the following situations:
Immediately inside parentheses, brackets or braces.
Yes: spam(ham[1], {eggs: 2})
No: spam( ham[ 1 ], { eggs: 2 } )
There's PEP 8 the Python Style Guide:
http://www.python.org/dev/peps/pep-0008/
It suggests the former style, but note the introduction carefully.
I find the latter to be visual nails-on-chalkboard, personally.
http://www.python.org/dev/peps/pep-0008/
Python Style Guide
No space around the inside of function signatures. Occasionally I put space inside the parens of a function call if the arguments are particularly hairy, but never on the definition. I don't think any language makes a habit of that, actually.
I don't think you should blindly follow the PEP-8 style, like a vow upon a bible.
The PEP8 is intended for code that goes in the python standard library, i.e. the modules you can import just after you've installed Python, but they have very different development constraints than most of the software I write.
So I tend to think a lot about each "rule" (either from the PEP8, the pylint/pychecker ones, or the Google Style Guide) and see how it can apply to my code -- the pros and cons.
As for your question, people usually don't use spaces inside parentheses, although I've seen it in some code by coworkers that like it, IMHO it detracts a little from readability, but it's a minor issue.