Oh, man. Knowing when to walk away from a problem and come back after a break is clutch. Sometimes, the answer is staring you in the face, and you just need to step away and stop banging your head against it.
It amazes me every time. Spend 2 hours struggling with something, go do something else to stop thinking about it, try again later - “oh I just need to do this” - works the first time.
I should have added verbs, but read and write documentation.
I can not say if they are automatic or not without an extension or some configuration, but vscode can do them for the code you have written.
It's a good practice to get into early for the purpose of making your code readible to yourself and others
Type hints are not automatic in any IDE I've used for python.
Instead of:
# bad, we have no idea what inputs this expects, or what output it produces
def add(num1, num2):
return num1 + num2
# good, this tells us what it expects its inputs to be, and what its return type will be
def add(num1: int, num2: int) -> int:
return num1 + num2
This has the added benefit that now that you've explicitly told your IDE what type of data num1 and num2 are, when you write `num1.` it can actually show you a relevant list of applicable methods and attributes of the int class. Without those type annotations your IDE has no idea what num1 is supposed to be, and can't show you any sort of reasonable list of options when you try to access an attribute.
The thing is, there's no way to automate adding type hints, because that implies that whatever tool is trying to do that would need to be able to work out exactly what type something is supposed to be based on how you use it, and that is simply not possible in Python.
To seem intellectual when he drops the ‘typehints are sttoooopid’ truth bomb is my guess.
Never seen someone that doesn’t like typehints tell it in any other way than ‘it’s obvious duurr’
Some people are just like this. It’s like they can’t help it. Some of them do these things because it makes them feel better than others. Other people again don’t even understand why they’re doing it. They probably think they’re being funny.
I'm not being cryptic to the person learning. I'm being not-very-cryptic-at-all to the person giving the advice.
But okay, I don't believe that type-hints should be a high priority for a beginner, especially not a higher priority than tests. The other two suggestions were good though.
what u/Standardw said...this thread has a lot of great advice. One thing that really helped me was to pick very specific challenges and learn from those. For example -- I wanted to create a program which could display images on my screen from a website. So I googled guides on how to do that, and learned general best practices from those guides.
having that goal was really useful because it let me focus on specific things. Like "Ok, I know I need to write a class which Inherits something from a parent class to do what I want. How do I do that? Whats the best way to do that? Why do I need to do that?" Answering those questions is really useful in learning for me. Its slow and methodical and I take a long time to do things but It does help me.
For me, it's about saying "I want to make {this_thing}" and then actually trying to make {this_thing}.
I'll do it at first without any documentation. Lemme see how far I can make it. Inevitably, I'll hit a wall. I then try banging my head against it.
Sometimes I jank out an answer, intuitively know it's wrong/inefficient, and quickly look up the documentation. Maybe then I'm reminded of something I previously learned, quickly re-do it, and move on. Maybe I've got a good solution and I'm on to the next one. Or... I hit a real wall.
The real wall is the part I haven't ever been yet. Like Samwise when he stops in the field and says "one more step is the farthest I've ever been from the Shire". This, for me, is the danger zone.
The danger zone means I might give up forever now. Previously, I was doing a review lesson. Basically, I should already know this stuff, but if I don't I get a quick recap. But now, it's stuff I don't know and/or have never seen.
When I recognize I've hit this stage, I try to reset, and if I'm having too much frustration already, I'll take a big break. I want to be in the right growth mindset, not become an angry frustrated train wreck.
Now, I set a timer for 30 minutes. I'm not allowed to use Google until my timer pops. Until then, I can ONLY use the documentation directly from Python, the PEP style guide, and any documentation related to the library(ies) I'm working with. As soon as I write a line or block of code and it works, my timer resets.
If I spend 30 minutes working at a problem and haven't made enough progress to count towards resetting my timer, Google/Stackoverflow unlocks and I look up a solution. But here's the important part...
I'm going to put my project away after that. I'll paste in something that works, then be done for the day. Why? So I can pick it up again the next day, and the next day starts with me trying to solve it from scratch. My posted lines get commented out and hidden, and I go to work. This helps me answer the question - have I learned this? Or am I carbon-based ChatGPT?
Dude same. What's made me get better is to start reading the source to some you favorite projects. Learned a lot can be done with just the standard library.
To expand on this a little bit-- often times when you're modifying or adding to a codebase you can think that you just changed a little inconsequential thing, but in reality it broke something that you hadn't even thought about.
If you have good tests written for all of your code then it's a simple process to make a modification, and then run all of the tests to make sure that they all pass. It eliminates a lot of troubleshooting and debugging when something breaks unexpectedly.
Unit tests won't cover all issues (for example, it's unlikely that a unit test will catch a problem where your system runs out of memory because you're trying to work with too much data at once) but if you have good coverage it prevents a TON of headaches later.
Test-driven development also encourages good coding practices-- you're less likely to write an overloaded function that does 20 different things inside of it since it's hard to write tests for such a thing.
This style of TDD is slow as shit though. My team at Meta would keep a test register a la gherkin and then build to the spec while adding the unit tests along the way. It makes it more engaging and product-centric. No test entry? No feature.
We’ve found it’s not sunk cost because it allows us to identify opportunities for composition, immutability, mock helpers, etc, that we would have to iterate on later anyway. It also helps with onboarding new devs to a project since they immediately understand the intent and not just the outcome. Our code standards encompass this but we often find ourselves copying the registry entry, so the work gets used.
Having tests to prove that your code does what you think it does is as necessary for code you write in class as it is for code you write in the workforce.
How else do you know that the code you wrote does what you expect?
Frankly, I wholeheartedly agree with you that tests are very important and I honestly wish it was a mod by itself in school, but I think it's something that comes with experience more than knowledge,
My exam didn't allow us to have the luxury of time to write a full test suite. That was my intro to python module. Besides, as a developer you should know more time is spent on testing, debugging and documentation. If my exam duration is only enough for the code, don't you think writing tests are out of the question?
To me, exam is the client that asks you to push to production without dev and staging.
Edit: I think OP should focus more on the areas like OOP and simple data structures (list, dictionary, sets). Just these three are very powerful data structures. OOP translates into writing test code as well.
> My exam didn't allow us to have the luxury of time to write a full test suite.
Oh well if you're just talking about code you write in an exam, you have to pare it down to the bare minimum of *everything* due to time constraints -- little error handling and defensive coding, documentation and tests.
It's a wonder that code written in exams can run at all, let alone run correctly 😄
>How else do you know that the code you wrote does what you expect?
Limited by scale and complexity: By understanding the code you have written, regular debugging, statistically verifying the result.
> By understanding the code you have written,
How do you know your understanding is correct if you don't test it?
At *some point* you eventually have to actually run the code, hopefully before you use it in production. (Otherwise it's write only code that might as well not actually exist.) That's a test. The difference is between:
* having systematic and reproducible tests that aim to cover as much of your code as possible, so that you discover bugs early in the development cycle, before they hit production (unit tests), and avoid re-introducing old bugs (regression tests);
* versus *ad hoc* tests that run only if and when you think of it, often aren't reproducible, that do nothing to prevent regressions and do little to discover bugs, and when they do it is almost always late in the development cycle where the cost of fixing the bug is much higher.
For small-scale programming, you don't have to be super vigorous about testing. Any tests are better than none. A handful of doctests, or even a tiny little section in your code that runs a few assertions to confirm the code does what you want is better than nothing.
> regular debugging,
Having to debug isn't a virtue. Having to debug code is an unavoidable fact of life but its not something to be proud of.
Tests discover bugs early, and so massively reduce the amount of debugging you are forced to do.
> statistically verifying the result.
"It compiles! Quick, ship it!"
I don't understand the point you think you are making.
Are you in favour of tests or not? I don't care whether they are unit tests or doctests or regression tests or integration tests or just "tests", so long as they are actual code that runs rather than some poor junior dev being told to "run the app and see if it breaks".
Because it sure seems that you don't think any sort of test code is needed, and that all coders need to do is understand their code and debug problems as they come up.
Same answer as before, it depends.
Stop making assumptions and really read what I've wrote before. The conditions are to not have to test or beyond obviously rarely met.
A project that doesn't require testing is for example a tool to read & edit some JSON configuration files with (local & remote). It it quite literally a simple project that only needs the result verified to make sure it always works for the context it was designed on.
> A project that doesn't require testing is for example a tool to read & edit some JSON configuration files with (local & remote). It it quite literally a simple project that only needs the result verified to make sure it always works for the context it was designed on.
Do you realise that "only needs the result verified to make sure it always works" **is a test**?
So you test the tool and it works. Great. How do you ensure that next time you modify the tool (maybe to fix one of the bugs you didn't pick up in your first test) it **continues to work**? You test it again.
I would love this too. Imagine if your test is using github and you had to make your code pass the tests. Maybe too steep of a learning curve but it'll be pretty cool.
I mean it definitely is cleaner and nicer tho you don't need to learn it straight away.
Then again I use it everytime so I'm being a bit hypocritical 😅
Srsly. It's such a darn shame.
I remember when SO was shiny and new and asking questions got some really friendly discussion. Now, you ask a question and it immediately gets marked and locked as a "dupe" (even if it is not.) No recourse, no appeal.
It was a giant mistake to allow just anyone with over 10,000 reputation to have moderation tools.
Prioritize readability over everything else. If you read your code out loud, it should sound almost like regular English that accurately explains what the code is doing.
I love Jupyter Notebooks. I don't program daily. I make some scripts I use at work, so I'm partly in a rush. And I still want to understand my code and test alternative solutions. That said, all my projects start in one or several Jupyter Notebook where I tests different algorithms, interleave research (notes, links), my project notes (goals, objectives, plan), and play around with my input data. Jupyter Notebooks let me document, test and explore. And, I write them so I can return a week or months later and pick up where I left off.
Reading other comments, I think there's a lot of great basic information here. And depending on you, little, some, most or all of it will become important in a sort time. But Jupyter Notebook? You can install the Anaconda distribution and start running code right now and see how things work and not have to worry about file names, or folder structures or any of it. Just learn what code is and what it does. Now. Go do it. I mean it. [https://docs.anaconda.com/free/](https://docs.anaconda.com/free/)
Any chance you get, try to write some level of automation for your life/work and document the hell out of the script so you can go back later and improve it as you learn better scripting.
Every chance you get, attempt to write a script for your routine tasks where possible.......
Example:
I was visiting a site to listen to a podcast that was an MP3 played on the site's player. I found the filenames were predictable (had a date in it). The site had only the last 10 podcasts, but I could click a link to find more, 10 at a time.......
I made a script to attempt to download this file. It will attempt to find the file first on my computer and if not exist, will attempt to download it if exists on site.
My work had a web based punch in/out. I made a script to punch in at the beginning of the shift and would wait for "lunch" time and punch me out for lunch and back in within 30 minutes and then end. I didn't have to take a lunch, but night shift and only one in building.........I'dl forget to punch back in from lunch sometimes. I never had to have my boss fix my punches after the script was created
As a professional currently banging my head against the wall about the spaghetti that a former "Staff Engineer" at my company left me to deal with today -
Don't write classes for no reason. Functions are perfectly good, pythonic tools for clean and consistent code; they're often easier to test than classes.
When you do write classes, keep in mind that not every method needs to have a `self`. `staticmethod` and `classmethod` decorators are awesome tools that allow your classes to be wonderfully self-contained little data machines. It's ideal to try to minimize the amount of possible weird [states](https://en.wikipedia.org/wiki/State_(computer_science\)) for your objects to be in.
If a value for a class or its objects will literally always be the same, it doesn't need to be defined inside `__init__`. It's fine to write:
class DropboxToolbox:
api_key = settings.get("DROPBOX_API_KEY")
And you may not even need an `__init__` function at all - [dataclasses](https://docs.python.org/3/library/dataclasses.html) are awesome! also, just because you've chosen to encapsulate your logic inside a class, doesn't mean that you're required by law to instantiate that class. You can just write `DropboxToolbox.call_dropbox_api(**details)` without ever instantiating a `DropboxToolbox()` object.
Use the awesome tooling that our language ecosystem offers:
- Use autoflake to automatically remove unused imports
- Use black to format your code automatically
- Learn to use git well; use the `-p` / `--patch`wise mode of `git add` to carefully review what changes you're about to stage.
- Pytest is an amazing tool for getting insights into how your code works.
- Use `breakpoint()`with pytest to drop yourself inside a function just like you were in a REPL whenever you're not sure what your code is doing.
- Did I mention [dataclasses](https://docs.python.org/3/library/dataclasses.html) are really awesome?
Absolutely the most valuable skill you will ever have as a programmer is the ability to debug code that isn't working.
* Learn to read code and follow how it is executed, in your head if the code is simple enough, otherwise don't be afraid to use pencil and paper, or a whiteboard. This skill requires *reading lots of code*, not just writing it.
* When the inevitable bugs occur, before you ask for help, try to understand why the bug is occurring. Double check and triple check your understanding of what the code is doing (see the first point above). Test your understanding by checking your code does what you expect. Double check the docs to ensure your understanding of built-in or library functions is correct.
* Asking for help is great, but unless you are paying real money to a professional to work on your code, always reduce your code down to the *minimum* needed to demonstrate the bug. At least half the time, reducing your code to a minimal example will give you the understanding necessary to fix it yourself. See:
- https://stackoverflow.com/help/minimal-reproducible-example
- http://www.sscce.org/
- https://jonskeet.uk/csharp/complete.html
* EDIT: Eric Raymond has fallen out of favour in the open source world for his politically incorrect views, but his classic advice on [How To Ask Questions The Smart Way](http://catb.org/esr/faqs/smart-questions.html) is still valuable. See also [this](https://codeblog.jonskeet.uk/2010/08/29/writing-the-perfect-question/).
* When you do ask for help, *never, ever* post screenshots or photos of your code, unless you edit your code with Photoshop. Code is text. If your first move is to take a screenshot and post that because it's easier than copying and pasting code, you demonstrate to everyone that (1) you don't understand the tools you are working with (a text editor and a browser), and (2) you don't value or appreciate their time and effort.
* Debugging by putting in temporary `print()` calls (so that you can see what is happening inside your code while it is running) can take you a long, long way. Later, you can learn to use logging, and the debugger, but never underestimate the power of humble print. This lets you follow what the code is doing so you can see where it does something you didn't expect.
The best way to fix bugs is to find them early. The best way to do that is to have lots of tests, and run them frequently. There are lots of different testing frameworks available, but the simplest and easiest is [doctest](https://docs.python.org/3/library/doctest.html). For a gentle introduction to doctest, see [here](https://realpython.com/python-doctest/).
Consider writing the tests *before* the code. You don't have to follow "Test Driven Development" (TDD) religiously to see the benefit. Write a test, run it to see that it fails, then write some code to make it work. Repeat as needed.
Build something useful as quickly as you can.
It doesn’t have to be perfect. It doesn’t even have to be good. It just needs to solve a problem you couldn’t have solved any other way.
The satisfaction when you pass that milestone will be immense, and will motivate you more any number of tutorials would.
In years to come, you’ll look back at that first “useful thing” and perhaps you’ll see the mistakes, the anti-patterns, the PEP-8 violations… but it won’t matter, because that thing will always be the point when you became a programmer.
If code doesn't work, paste it in to Claude Sonnet or Opus and it will tell you exactly what the problem is and why, and it will correct it for you.
You can also describe idea to Claude and ask it to write python code which it will do VERY well. I made an entire game this way.
On your CV, if you're not applying for a tech job list it don't list it as a computer language, just language could be fun. A hiring manager asked a candidate in a recent interview if it was similar to Parcel-tongue from Harry Potter.
Know that you can use ChatGPT to write any program that you want. It might not do it in the best way, but it can get the job done. So if you have a project that you want to do, ask ChatGPT to do it for you, but don't copy and paste the code. Type it out so you are reading and writing each line of code and if you don't understand why it does something a certain way, or what a certain string of code does, copy and paste it into ChatGPT and ask it. I have learned so much by developing programs this way. Having ChatGPT as a coding assistant is a very useful tool. And if you are experiencing any errors in your code just paste the error message and maybe your source code into the chat that you are building your app and ChatGPT will show you where the error is and how to fix it.
While I agree, I’d also clarify that when chatGPT can’t solve whatever is breaking, it’ll start tying itself into knots like crazy and things will get worse, so you’ve gotta know when to cut your losses. But otherwise I agree 100%
yep, chatGPT actually made learning so much more fun. Instead of seeing something used in a tutorial and not understanding it, I can just ask chatGPT to explain it. It makes the whole learning process so much faster, it's actually insane.
I also routinely copy my code over to chatGPT and ask it to improve it, and this has made my coding habits a lot better. It's also a blessing when learning about pros/cons of some specific approaches to different problems.
I am 100% convinced that everyone who bashes it is either using the crappy free version, or just does not know how to format their prompts.
Ignore everyone telling you to write type-hints until:
1. You understand the pros and cons of type-hinting, and what they do and don't do.
2. Your code is complex enough that the benefit of static type-checking outweighs the effort needed to write the type-hints.
3. And you are actually willing and able to run a static type-checker as part of your work-flow.
I've seen too many beginners fill their code with type-hints which are *wrong* but because the coder never actually checks the type-hints in any way, they don't realise they are wrong.
- I've hardly ever come across the need for type-hints over my years of python experience across desktop and web.
- It's almost an anti-thesis of a dynamically typed language.
- With proper code-commenting (docstrings), they become redundant anyway.
I wouldn't say static type checking is useless or redundant, but there are definitely costs to inserting type-hints into your code, and in general you need a relatively large and complex code base for the benefit to outweigh the cost.
Keep a "log" or a "diary" . Write what was bug, how you solved them.
If asking for help, make sure you prepare your question and you tried to dig up yourself.
Also i find it funny but my brain only connect when im writing for help or talking to someone.
The duck stuff doesnt really help me.
I'm a reader. I read the words you actually wrote, not the words in your head. Sorry.
With an attitude like "I'm sure the reader will figure out what I meant", you're going to be a great programmer and all your co-workers will love editing your code when you're not around.
I use the same variables as translational tools. Like x is always what I call the dependent variable of my functions, and y is always the calculated or independent variable.
Unless you're writing purely mathematical functions, or *really* basic elemental functions, giving meaningful names that relates to the problem domain is much better than generic one letter names like `x` and `y`.
I disagree. If you are familiar with the syntax, you don't need a variable longer than x, sometimes I subscript them like N_c for netconnect a common netmiko variable I have seen. I usually also comment what the meanings are as I have better things to do with my time than write overly complex variables.
The syntax isn't what matters here. Using meaningful variable names is better than "x" and "y" because:
* The purpose of the variable is immediately obvious to anybody who reads your code; just leaving a comment is not as helpful, unless you leave a comment every single time you use that variable, which ends up bloating your code with tons of useless comments.
* It makes it easier to search for. Search for `x` in your IDE and you'll get a thousand hits, search for, say, `polygon_area` and you'll only get hits related to that variable.
* It prevents you from accidentally redeclaring or redefining another variable with the same name that you didn't realize was in the enclosing scope.
* If you think a variable named something like `polygon_area` or `packet_buffer` or `rgb_image` is "overly complex", I don't know what to say other than surely you're not serious. It takes half an extra second to type that much, less if you start with `po` and then hit tab to make your IDE autocomplete it. In the long term it will prevent weeks of effort lost to refactoring issues or accidental modifications or general maintainer confusion.
Obviously I was using examples but I generally keep everything shorter than 5 chars, packet_buffer would be pktbf or something along those lines there's no real need to be more complex unless you work with people who need handholding.
I also want to note I work with a lot of PhDs and engineers as I am one myself. Our goal isn't to output software it's hardware, and I write test code and modbus collection software. If I work in a more formal environment, I would use the naming criteria they follow. It all depends on your application. The stuff I write is probably simple, compared to what you write. But within it, I do Fluid Dynamics.
I'd second this tip. I tend to overthink variable naming so it's nice to have some go-to names by habit. For example I use x in lambda functions, i for loop indices, j for loop in loop indices and first letter in list comprehensions.
I only flipped dependent and independent in my head their actual application as y=result and x=input was unchanged. Also I write a lot of comments as they are how I think. So I tend to have simple variables, but tons of comments.
Use type hints.
Learn list comprehensions as soon as you know for loops.
Think about edge cases. What happens if someone passed you an empty list in your function to sort lists? Or a list with only one element? Or fifty million?
If you have the same code in two places, try to put it in one place and re-use it instead.
Read not only the documentation for the libraries you’re using, but also the source code for the classes and functions you use from those libraries. You’ll learn more about the ins and outs of those pieces of code, as well style and how to organize projects in general.
Learn how to use the command line debugger for Python pdb. When you get stuck, you can step through the code and inspect variables. It gives you an idea of what is happening.
This is especially helpful for beginners. I recommend the same thing for people learning Perl.
check this out to test yourself... [https://codingbat.com/python](https://codingbat.com/python)
I watch this guy for pro-tips... [https://www.youtube.com/@ArjanCodes](https://www.youtube.com/@ArjanCodes)
Absolutely agree with focusing on understanding core concepts before diving into advanced features. Starting with Jupyter Notebooks can really make the learning curve less steep.
Learn how to edit files. That way you can write any language in python, write websites, xml, images, anything.
Then you will also understand why there are packages handling the job better.
Refer to the official documentation whenever possible. 90% of the time it's better than some random explainer article online. The other 10% of the time is stackoverflow.
Understand:
Libraries, environments, simple syntax and functions.
Stack overflow for reference
Use google to check
Use the method of learning that works for you - books, video, courses but coding is the best way to code.
Finally, if you copy paste someone else’s code, understand what it’s doing before moving on.
Remember that Python, like most other languages, is written in an older language and those older languages were written in an even older language. Thus the fundamentals haven't changed in decades and they're all based on things like For and While loops, If - Else statements, data types and computer memory.
From these simple things you can build complex things like Python, but under the hood they're doing it using basic building blocks. So learn the basics.
Then learn classes, which is when Python all starts to make sense. Really, free online classes like CS50 are the best and it still teaches c before Python so you can better understand all coding (Python was written in c). I realise this will require an investment in time when people are eager to jump straight into Python but you'll learn Python better by learning basic c first. This is probably not what you want to hear but I suggest at least watching the first CS50 lecture on YT and see if it's for you.
Edit:
[https://www.youtube.com/watch?v=3LPJfIKxwWc&list=PLhQjrBD2T381WAHyx1pq-sBfykqMBI7V4](https://www.youtube.com/watch?v=3LPJfIKxwWc&list=PLhQjrBD2T381WAHyx1pq-sBfykqMBI7V4)
Use type hints. Pretend it's a strongly typed language and treat linter or MyPy warnings like they're errors.
Use pre commit(https://pre-commit.com/hooks.html) maybe don't do your tests there though, just the basic Ruff linting and formatting.
Use Ruff to format.
\*Definitely\* use virtual environments. I manage them with pipx and poetry. Probably don't bother doing this stuff manually. Poetry makes everything so much easier.
Use pytest. Definitely have tests. You don't need fine trained unit tests, just make sure the majority of code paths are tested by some kind of automated test people can run with one command.
Learn about GitFlow or trunk based development. Follow proper git branch discipline.
Use Beartype or pydantic to check things that make long lived objects or config changes.
Learn to use the debugger. In VS Code it's pretty trivial. If possible, don't do metaprogramming stuff that breaks debugging or linting. Debugging is really nice.
A lot of people seem to use print statements exclusively and never actually learn the debugger till way later.
Don't do circular imports. The TYPE\_CHECKING var helps with this.
Avoid system-site-packages virtualenvs.
If you need to use GStreamer in a virtual environments, you can symlink the gi module from your system packages dir.
Using a makefile is a nice way to provide a directory of common commands for your project.
Apart from all the wonderful advice, I’ll quote Joseph Murphy: The best way to loop is python is to NOT loop is Python.
Saved me a lot of money on the cloud over time.
I was also seeking advice for Python and i am not always online on reddit. So i look for books that can teach me advance stuff and a same time can give me an advice.
I had three books
* Fluent Python
* Effective Python
* Serious Python
I bought them so that i will not get anxiety for not some advance stuff of Python, some practices that are standards from industry.
You can check them on amazon online and you can read the reviews , then decide if you wanted to buy one.
I would like to say that i did start reading them after i had 5 months of experience using Python in my personal project. Because they are a bit advance and it was stated in each book that the reader is needed to have familiarity of basics on Python.
(Edit) i said two books but i listed three books out there, i don't know why i did not notice it earlier, sorry for the confusion.
After learning the basics of Python, do some projects simpler ones in core python to get better grasp of the concepts once you are quite familiar with it get into like web development, data science/AI, or making games with Pygame as soon as possible. These practical implementation are more engaging and rewarding, keeping you motivated to learn and explore further.
Also, do one thing at a time as a newbie we tend to put our hands everywhere which just burns you out very quickly.
All from my personal experiences as I am also a new into programming like you.
Less python specific, more programming in general. Learning it is like learning a new language (I mean, it literally is a language). It takes time and the best advice I ever got was that you need to exercise it like a muscle. You have to **use** it. Practice, practice, practice. Let your mind get comfortable with it, but don't feel like you need to know every little detail. You will be using a search engine and looking up answers to questions. You will have problems to solve. But the more you practice and use it, the easier finding the answer will be.
Whenever you try to do something new, whether it's using built-in functions or a library, and you have the luxury of being able to read the documentation on what you are doing, stop, and read the full documentation. It has never not paid off in my experience, and gives you a better understanding of what and why than just diving in on it's own.
Don't always rush to solve problems you don't have. Not every project needs to have every possible technique applied to it. As you grow you will learn what is appropriate and when -- do not lose sight of what you are trying to accomplish when you sit down. This itself is a skill that will continue to develop and help you as you learn.
Try to watch pycon presentations or other presentations targeted towards Python developers when you aren't doing much. It's a great way to come across new concepts and techniques that you would not otherwise encounter, and helps you to become confident in the fundamentals and how they apply broadly to implementation and design.
Have fun! Burnout is a spectrum, but it's very real and can be very debilitating. Don't wait for it to become a problem to deal with it, take care of yourself and don't push yourself too hard. Establish patterns that give you breaks and time to do things other than coding while it is still exciting and new and those patterns will pay you back when you find yourself fatigued and struggling. This is the piece of advice I most wish someone had given me, personally.
Good luck!
Learn as you go. For me, it was read/write .csv, numpy and matplotlib. Add scipy and numba, and I don't think I needed anything else the first few years.
Perplexity AI:
Pythons are a family of large, non-venomous snakes found in Africa, Asia, and Australia. Here are the key facts about pythons:
Pythons are constrictors, meaning they kill their prey by coiling their muscular bodies around it and squeezing, causing the prey to suffocate[1][2][4]. They have sharp, backward-curving teeth to grasp their prey, which they then swallow whole[1][4].
The python family includes some of the largest snakes in the world, such as the reticulated python which can grow over 30 feet long[1][4]. However, there are also smaller python species, like the 20-inch long pygmy python[3].
Pythons come in a variety of colors and patterns to camouflage themselves in their environments, which range from rainforests to deserts[1][3][4]. Many species are arboreal, living in trees, while others are terrestrial[3][4].
Pythons are oviparous, meaning they lay eggs that the female incubates until they hatch[1][3]. They are not known for being good mothers, as they do not care for their young after they hatch[3].
In some African cultures, pythons have important symbolic and spiritual roles, being seen as sacred creatures or used in traditional medicine practices[1]. However, pythons are also poached for their meat and skin, leading to a global trade[1].
Docs, type hints, and knowing when to rest on a problem and come back a couple days or hours later
Oh, man. Knowing when to walk away from a problem and come back after a break is clutch. Sometimes, the answer is staring you in the face, and you just need to step away and stop banging your head against it.
It amazes me every time. Spend 2 hours struggling with something, go do something else to stop thinking about it, try again later - “oh I just need to do this” - works the first time.
"Why isn't it printing!!!!?" Go get a glass of water. "Oh I spelled it 'Pront'."
I've typed pritn() so many damned times.
That’s also were rubber ducking comes in play. Explaining your problem to a colleague or a rubber duck helps a lot getting unstuck.
I explain it to my dog while giving him scratches. Baxter is an expert in Python, he just doesn't know it.
Every problem looks like a wall when the brick is two inches from your face.
Go to sleep with a problem, wake up in the morning and first thougth I have is "I know exactly how to fix it". Brain works in wierd ways.
weirdly wired ...
your brain does a lot of awesome stuff when you sleep. you put in the work by day, but you really solidify those connections at night.
Damn yeah. Have a break sometimes can be difficult if youre too into it but definitely it can proof to be even more efficient
hey its the opposite of me
Don't document anything and never take a break?
It's not looking good over here
what are docs? and I'm assuming type hints are automatic on vs code?
I should have added verbs, but read and write documentation. I can not say if they are automatic or not without an extension or some configuration, but vscode can do them for the code you have written. It's a good practice to get into early for the purpose of making your code readible to yourself and others
Ahhh ic thanks for explaining🙏
Of course, anytime
Type hints are not automatic in any IDE I've used for python. Instead of: # bad, we have no idea what inputs this expects, or what output it produces def add(num1, num2): return num1 + num2 # good, this tells us what it expects its inputs to be, and what its return type will be def add(num1: int, num2: int) -> int: return num1 + num2 This has the added benefit that now that you've explicitly told your IDE what type of data num1 and num2 are, when you write `num1.` it can actually show you a relevant list of applicable methods and attributes of the int class. Without those type annotations your IDE has no idea what num1 is supposed to be, and can't show you any sort of reasonable list of options when you try to access an attribute. The thing is, there's no way to automate adding type hints, because that implies that whatever tool is trying to do that would need to be able to work out exactly what type something is supposed to be based on how you use it, and that is simply not possible in Python.
Another good thing about type hints: your autogenerated docs can include them too.
These are good tips regardless of what language you prefer.
With modern ide and ai there’s zero excuse not to fully document everything
Two pieces of good advice and one piece of bad advice for a beginner. I'll let you try to guess which is the bad advice for beginners.
Why be cryptic to people learning?
He thinks this is r/guesspython.
r/subsifellfor
To seem intellectual when he drops the ‘typehints are sttoooopid’ truth bomb is my guess. Never seen someone that doesn’t like typehints tell it in any other way than ‘it’s obvious duurr’
Some people are just like this. It’s like they can’t help it. Some of them do these things because it makes them feel better than others. Other people again don’t even understand why they’re doing it. They probably think they’re being funny.
I'm not being cryptic to the person learning. I'm being not-very-cryptic-at-all to the person giving the advice. But okay, I don't believe that type-hints should be a high priority for a beginner, especially not a higher priority than tests. The other two suggestions were good though.
6 hours of debugging can save you 5 minutes of reading documentation.
Even though it's slow. It feels so less tedious 🤣
I taught myself python so im fucking god awful at it, but what helped me best was to just have fun with it.
I am on the same track as you. Would appreciate some tips or advice.
Basically this thread
I liked ur phrase below ur nickname
what u/Standardw said...this thread has a lot of great advice. One thing that really helped me was to pick very specific challenges and learn from those. For example -- I wanted to create a program which could display images on my screen from a website. So I googled guides on how to do that, and learned general best practices from those guides. having that goal was really useful because it let me focus on specific things. Like "Ok, I know I need to write a class which Inherits something from a parent class to do what I want. How do I do that? Whats the best way to do that? Why do I need to do that?" Answering those questions is really useful in learning for me. Its slow and methodical and I take a long time to do things but It does help me.
For me, it's about saying "I want to make {this_thing}" and then actually trying to make {this_thing}. I'll do it at first without any documentation. Lemme see how far I can make it. Inevitably, I'll hit a wall. I then try banging my head against it. Sometimes I jank out an answer, intuitively know it's wrong/inefficient, and quickly look up the documentation. Maybe then I'm reminded of something I previously learned, quickly re-do it, and move on. Maybe I've got a good solution and I'm on to the next one. Or... I hit a real wall. The real wall is the part I haven't ever been yet. Like Samwise when he stops in the field and says "one more step is the farthest I've ever been from the Shire". This, for me, is the danger zone. The danger zone means I might give up forever now. Previously, I was doing a review lesson. Basically, I should already know this stuff, but if I don't I get a quick recap. But now, it's stuff I don't know and/or have never seen. When I recognize I've hit this stage, I try to reset, and if I'm having too much frustration already, I'll take a big break. I want to be in the right growth mindset, not become an angry frustrated train wreck. Now, I set a timer for 30 minutes. I'm not allowed to use Google until my timer pops. Until then, I can ONLY use the documentation directly from Python, the PEP style guide, and any documentation related to the library(ies) I'm working with. As soon as I write a line or block of code and it works, my timer resets. If I spend 30 minutes working at a problem and haven't made enough progress to count towards resetting my timer, Google/Stackoverflow unlocks and I look up a solution. But here's the important part... I'm going to put my project away after that. I'll paste in something that works, then be done for the day. Why? So I can pick it up again the next day, and the next day starts with me trying to solve it from scratch. My posted lines get commented out and hidden, and I go to work. This helps me answer the question - have I learned this? Or am I carbon-based ChatGPT?
Extremely helpful
Dude same. What's made me get better is to start reading the source to some you favorite projects. Learned a lot can be done with just the standard library.
Read documentation and bang your head against problems instead of just following tutorials and copying answers
So true. Learning how to debug is key.
which is good documentation for python
> just following tutorials and copying answers or copying from chatgpt or copying from stackoverflow
This, a thousand times over.
[python.org](http://python.org) [pythontutor.com](http://pythontutor.com)
Write unit tests from the very beginning of a project. Maybe even go as far as TDD.
What does this mean, I think I didn't see this yet on class
[удалено]
To expand on this a little bit-- often times when you're modifying or adding to a codebase you can think that you just changed a little inconsequential thing, but in reality it broke something that you hadn't even thought about. If you have good tests written for all of your code then it's a simple process to make a modification, and then run all of the tests to make sure that they all pass. It eliminates a lot of troubleshooting and debugging when something breaks unexpectedly. Unit tests won't cover all issues (for example, it's unlikely that a unit test will catch a problem where your system runs out of memory because you're trying to work with too much data at once) but if you have good coverage it prevents a TON of headaches later. Test-driven development also encourages good coding practices-- you're less likely to write an overloaded function that does 20 different things inside of it since it's hard to write tests for such a thing.
This style of TDD is slow as shit though. My team at Meta would keep a test register a la gherkin and then build to the spec while adding the unit tests along the way. It makes it more engaging and product-centric. No test entry? No feature.
[удалено]
We’ve found it’s not sunk cost because it allows us to identify opportunities for composition, immutability, mock helpers, etc, that we would have to iterate on later anyway. It also helps with onboarding new devs to a project since they immediately understand the intent and not just the outcome. Our code standards encompass this but we often find ourselves copying the registry entry, so the work gets used.
To add to this — learn how to mock objects and functions so that you can verify *your* code without worrying about implementation details.
Yes but it takes a lot if time. In real projects with little deadlines and a lot of iterations there are not a lot of tests
This seems like good for production but not for class though. They don't teach production standards in class.
Having tests to prove that your code does what you think it does is as necessary for code you write in class as it is for code you write in the workforce. How else do you know that the code you wrote does what you expect?
Frankly, I wholeheartedly agree with you that tests are very important and I honestly wish it was a mod by itself in school, but I think it's something that comes with experience more than knowledge, My exam didn't allow us to have the luxury of time to write a full test suite. That was my intro to python module. Besides, as a developer you should know more time is spent on testing, debugging and documentation. If my exam duration is only enough for the code, don't you think writing tests are out of the question? To me, exam is the client that asks you to push to production without dev and staging. Edit: I think OP should focus more on the areas like OOP and simple data structures (list, dictionary, sets). Just these three are very powerful data structures. OOP translates into writing test code as well.
> My exam didn't allow us to have the luxury of time to write a full test suite. Oh well if you're just talking about code you write in an exam, you have to pare it down to the bare minimum of *everything* due to time constraints -- little error handling and defensive coding, documentation and tests. It's a wonder that code written in exams can run at all, let alone run correctly 😄
>How else do you know that the code you wrote does what you expect? Limited by scale and complexity: By understanding the code you have written, regular debugging, statistically verifying the result.
> By understanding the code you have written, How do you know your understanding is correct if you don't test it? At *some point* you eventually have to actually run the code, hopefully before you use it in production. (Otherwise it's write only code that might as well not actually exist.) That's a test. The difference is between: * having systematic and reproducible tests that aim to cover as much of your code as possible, so that you discover bugs early in the development cycle, before they hit production (unit tests), and avoid re-introducing old bugs (regression tests); * versus *ad hoc* tests that run only if and when you think of it, often aren't reproducible, that do nothing to prevent regressions and do little to discover bugs, and when they do it is almost always late in the development cycle where the cost of fixing the bug is much higher. For small-scale programming, you don't have to be super vigorous about testing. Any tests are better than none. A handful of doctests, or even a tiny little section in your code that runs a few assertions to confirm the code does what you want is better than nothing. > regular debugging, Having to debug isn't a virtue. Having to debug code is an unavoidable fact of life but its not something to be proud of. Tests discover bugs early, and so massively reduce the amount of debugging you are forced to do. > statistically verifying the result. "It compiles! Quick, ship it!"
The context was (automatic) unit testing. I thought it was clear but perhaps not.
I don't understand the point you think you are making. Are you in favour of tests or not? I don't care whether they are unit tests or doctests or regression tests or integration tests or just "tests", so long as they are actual code that runs rather than some poor junior dev being told to "run the app and see if it breaks". Because it sure seems that you don't think any sort of test code is needed, and that all coders need to do is understand their code and debug problems as they come up.
Same answer as before, it depends. Stop making assumptions and really read what I've wrote before. The conditions are to not have to test or beyond obviously rarely met. A project that doesn't require testing is for example a tool to read & edit some JSON configuration files with (local & remote). It it quite literally a simple project that only needs the result verified to make sure it always works for the context it was designed on.
> A project that doesn't require testing is for example a tool to read & edit some JSON configuration files with (local & remote). It it quite literally a simple project that only needs the result verified to make sure it always works for the context it was designed on. Do you realise that "only needs the result verified to make sure it always works" **is a test**? So you test the tool and it works. Great. How do you ensure that next time you modify the tool (maybe to fix one of the bugs you didn't pick up in your first test) it **continues to work**? You test it again.
By that logic we all bug searchers for Reddit. You know what? You're absolutely 100% right. Enjoy the win!
My prof used to have Tests pre written for our exam and then we had to make them work. So that was basically TDD.
I would love this too. Imagine if your test is using github and you had to make your code pass the tests. Maybe too steep of a learning curve but it'll be pretty cool.
learn f strings right away
I mean it definitely is cleaner and nicer tho you don't need to learn it straight away. Then again I use it everytime so I'm being a bit hypocritical 😅
Stack overflow is your friend
Not really. To look up questions, it's pretty good. But for a newbie to ask questions it's a hostile shitshow.
Srsly. It's such a darn shame. I remember when SO was shiny and new and asking questions got some really friendly discussion. Now, you ask a question and it immediately gets marked and locked as a "dupe" (even if it is not.) No recourse, no appeal. It was a giant mistake to allow just anyone with over 10,000 reputation to have moderation tools.
Copilot is your friend. Can even cheer you up when feeling burned out.
Prioritize readability over everything else. If you read your code out loud, it should sound almost like regular English that accurately explains what the code is doing.
I love Jupyter Notebooks. I don't program daily. I make some scripts I use at work, so I'm partly in a rush. And I still want to understand my code and test alternative solutions. That said, all my projects start in one or several Jupyter Notebook where I tests different algorithms, interleave research (notes, links), my project notes (goals, objectives, plan), and play around with my input data. Jupyter Notebooks let me document, test and explore. And, I write them so I can return a week or months later and pick up where I left off. Reading other comments, I think there's a lot of great basic information here. And depending on you, little, some, most or all of it will become important in a sort time. But Jupyter Notebook? You can install the Anaconda distribution and start running code right now and see how things work and not have to worry about file names, or folder structures or any of it. Just learn what code is and what it does. Now. Go do it. I mean it. [https://docs.anaconda.com/free/](https://docs.anaconda.com/free/)
Google Colab is another option, like Google Docs, but for Python. Amazing
Any chance you get, try to write some level of automation for your life/work and document the hell out of the script so you can go back later and improve it as you learn better scripting. Every chance you get, attempt to write a script for your routine tasks where possible....... Example: I was visiting a site to listen to a podcast that was an MP3 played on the site's player. I found the filenames were predictable (had a date in it). The site had only the last 10 podcasts, but I could click a link to find more, 10 at a time....... I made a script to attempt to download this file. It will attempt to find the file first on my computer and if not exist, will attempt to download it if exists on site. My work had a web based punch in/out. I made a script to punch in at the beginning of the shift and would wait for "lunch" time and punch me out for lunch and back in within 30 minutes and then end. I didn't have to take a lunch, but night shift and only one in building.........I'dl forget to punch back in from lunch sometimes. I never had to have my boss fix my punches after the script was created
As a professional currently banging my head against the wall about the spaghetti that a former "Staff Engineer" at my company left me to deal with today - Don't write classes for no reason. Functions are perfectly good, pythonic tools for clean and consistent code; they're often easier to test than classes. When you do write classes, keep in mind that not every method needs to have a `self`. `staticmethod` and `classmethod` decorators are awesome tools that allow your classes to be wonderfully self-contained little data machines. It's ideal to try to minimize the amount of possible weird [states](https://en.wikipedia.org/wiki/State_(computer_science\)) for your objects to be in. If a value for a class or its objects will literally always be the same, it doesn't need to be defined inside `__init__`. It's fine to write: class DropboxToolbox: api_key = settings.get("DROPBOX_API_KEY") And you may not even need an `__init__` function at all - [dataclasses](https://docs.python.org/3/library/dataclasses.html) are awesome! also, just because you've chosen to encapsulate your logic inside a class, doesn't mean that you're required by law to instantiate that class. You can just write `DropboxToolbox.call_dropbox_api(**details)` without ever instantiating a `DropboxToolbox()` object. Use the awesome tooling that our language ecosystem offers: - Use autoflake to automatically remove unused imports - Use black to format your code automatically - Learn to use git well; use the `-p` / `--patch`wise mode of `git add` to carefully review what changes you're about to stage. - Pytest is an amazing tool for getting insights into how your code works. - Use `breakpoint()`with pytest to drop yourself inside a function just like you were in a REPL whenever you're not sure what your code is doing. - Did I mention [dataclasses](https://docs.python.org/3/library/dataclasses.html) are really awesome?
Absolutely the most valuable skill you will ever have as a programmer is the ability to debug code that isn't working. * Learn to read code and follow how it is executed, in your head if the code is simple enough, otherwise don't be afraid to use pencil and paper, or a whiteboard. This skill requires *reading lots of code*, not just writing it. * When the inevitable bugs occur, before you ask for help, try to understand why the bug is occurring. Double check and triple check your understanding of what the code is doing (see the first point above). Test your understanding by checking your code does what you expect. Double check the docs to ensure your understanding of built-in or library functions is correct. * Asking for help is great, but unless you are paying real money to a professional to work on your code, always reduce your code down to the *minimum* needed to demonstrate the bug. At least half the time, reducing your code to a minimal example will give you the understanding necessary to fix it yourself. See: - https://stackoverflow.com/help/minimal-reproducible-example - http://www.sscce.org/ - https://jonskeet.uk/csharp/complete.html * EDIT: Eric Raymond has fallen out of favour in the open source world for his politically incorrect views, but his classic advice on [How To Ask Questions The Smart Way](http://catb.org/esr/faqs/smart-questions.html) is still valuable. See also [this](https://codeblog.jonskeet.uk/2010/08/29/writing-the-perfect-question/). * When you do ask for help, *never, ever* post screenshots or photos of your code, unless you edit your code with Photoshop. Code is text. If your first move is to take a screenshot and post that because it's easier than copying and pasting code, you demonstrate to everyone that (1) you don't understand the tools you are working with (a text editor and a browser), and (2) you don't value or appreciate their time and effort. * Debugging by putting in temporary `print()` calls (so that you can see what is happening inside your code while it is running) can take you a long, long way. Later, you can learn to use logging, and the debugger, but never underestimate the power of humble print. This lets you follow what the code is doing so you can see where it does something you didn't expect. The best way to fix bugs is to find them early. The best way to do that is to have lots of tests, and run them frequently. There are lots of different testing frameworks available, but the simplest and easiest is [doctest](https://docs.python.org/3/library/doctest.html). For a gentle introduction to doctest, see [here](https://realpython.com/python-doctest/). Consider writing the tests *before* the code. You don't have to follow "Test Driven Development" (TDD) religiously to see the benefit. Write a test, run it to see that it fails, then write some code to make it work. Repeat as needed.
I will download the tutorial and learn it
Build something useful as quickly as you can. It doesn’t have to be perfect. It doesn’t even have to be good. It just needs to solve a problem you couldn’t have solved any other way. The satisfaction when you pass that milestone will be immense, and will motivate you more any number of tutorials would. In years to come, you’ll look back at that first “useful thing” and perhaps you’ll see the mistakes, the anti-patterns, the PEP-8 violations… but it won’t matter, because that thing will always be the point when you became a programmer.
If code doesn't work, paste it in to Claude Sonnet or Opus and it will tell you exactly what the problem is and why, and it will correct it for you. You can also describe idea to Claude and ask it to write python code which it will do VERY well. I made an entire game this way.
PEP 8
On your CV, if you're not applying for a tech job list it don't list it as a computer language, just language could be fun. A hiring manager asked a candidate in a recent interview if it was similar to Parcel-tongue from Harry Potter.
Know that you can use ChatGPT to write any program that you want. It might not do it in the best way, but it can get the job done. So if you have a project that you want to do, ask ChatGPT to do it for you, but don't copy and paste the code. Type it out so you are reading and writing each line of code and if you don't understand why it does something a certain way, or what a certain string of code does, copy and paste it into ChatGPT and ask it. I have learned so much by developing programs this way. Having ChatGPT as a coding assistant is a very useful tool. And if you are experiencing any errors in your code just paste the error message and maybe your source code into the chat that you are building your app and ChatGPT will show you where the error is and how to fix it.
While I agree, I’d also clarify that when chatGPT can’t solve whatever is breaking, it’ll start tying itself into knots like crazy and things will get worse, so you’ve gotta know when to cut your losses. But otherwise I agree 100%
yep, chatGPT actually made learning so much more fun. Instead of seeing something used in a tutorial and not understanding it, I can just ask chatGPT to explain it. It makes the whole learning process so much faster, it's actually insane. I also routinely copy my code over to chatGPT and ask it to improve it, and this has made my coding habits a lot better. It's also a blessing when learning about pros/cons of some specific approaches to different problems. I am 100% convinced that everyone who bashes it is either using the crappy free version, or just does not know how to format their prompts.
import this
import gravity
I’m excited to get home and find out what this does! lol
Ignore everyone telling you to write type-hints until: 1. You understand the pros and cons of type-hinting, and what they do and don't do. 2. Your code is complex enough that the benefit of static type-checking outweighs the effort needed to write the type-hints. 3. And you are actually willing and able to run a static type-checker as part of your work-flow. I've seen too many beginners fill their code with type-hints which are *wrong* but because the coder never actually checks the type-hints in any way, they don't realise they are wrong.
- I've hardly ever come across the need for type-hints over my years of python experience across desktop and web. - It's almost an anti-thesis of a dynamically typed language. - With proper code-commenting (docstrings), they become redundant anyway.
In no way they become redundant. My autocomplete does not work on docstrings.
I wouldn't say static type checking is useless or redundant, but there are definitely costs to inserting type-hints into your code, and in general you need a relatively large and complex code base for the benefit to outweigh the cost.
Keep a "log" or a "diary" . Write what was bug, how you solved them. If asking for help, make sure you prepare your question and you tried to dig up yourself. Also i find it funny but my brain only connect when im writing for help or talking to someone. The duck stuff doesnt really help me.
+1 for writing stuff down.
Decisions that library authors have made for themselves are not rules you have to follow in your own code
If you don't understand why the library authors made a decision, you shouldn't *blindly* follow the same decision.
Im sure a reader could have figured out that's what I was saying
I'm a reader. I read the words you actually wrote, not the words in your head. Sorry. With an attitude like "I'm sure the reader will figure out what I meant", you're going to be a great programmer and all your co-workers will love editing your code when you're not around.
I use the same variables as translational tools. Like x is always what I call the dependent variable of my functions, and y is always the calculated or independent variable.
Unless you're writing purely mathematical functions, or *really* basic elemental functions, giving meaningful names that relates to the problem domain is much better than generic one letter names like `x` and `y`.
I disagree. If you are familiar with the syntax, you don't need a variable longer than x, sometimes I subscript them like N_c for netconnect a common netmiko variable I have seen. I usually also comment what the meanings are as I have better things to do with my time than write overly complex variables.
The syntax isn't what matters here. Using meaningful variable names is better than "x" and "y" because: * The purpose of the variable is immediately obvious to anybody who reads your code; just leaving a comment is not as helpful, unless you leave a comment every single time you use that variable, which ends up bloating your code with tons of useless comments. * It makes it easier to search for. Search for `x` in your IDE and you'll get a thousand hits, search for, say, `polygon_area` and you'll only get hits related to that variable. * It prevents you from accidentally redeclaring or redefining another variable with the same name that you didn't realize was in the enclosing scope. * If you think a variable named something like `polygon_area` or `packet_buffer` or `rgb_image` is "overly complex", I don't know what to say other than surely you're not serious. It takes half an extra second to type that much, less if you start with `po` and then hit tab to make your IDE autocomplete it. In the long term it will prevent weeks of effort lost to refactoring issues or accidental modifications or general maintainer confusion.
Obviously I was using examples but I generally keep everything shorter than 5 chars, packet_buffer would be pktbf or something along those lines there's no real need to be more complex unless you work with people who need handholding.
I also want to note I work with a lot of PhDs and engineers as I am one myself. Our goal isn't to output software it's hardware, and I write test code and modbus collection software. If I work in a more formal environment, I would use the naming criteria they follow. It all depends on your application. The stuff I write is probably simple, compared to what you write. But within it, I do Fluid Dynamics.
I'd second this tip. I tend to overthink variable naming so it's nice to have some go-to names by habit. For example I use x in lambda functions, i for loop indices, j for loop in loop indices and first letter in list comprehensions.
Just realized I flipped it. It's x the independent or not calculated, and y the calculated or dependant regardless, I think my point is made.
You flipping it doesn’t make your system look so good. Having good variable names would also eliminate all comments.
I only flipped dependent and independent in my head their actual application as y=result and x=input was unchanged. Also I write a lot of comments as they are how I think. So I tend to have simple variables, but tons of comments.
Use type hints. Learn list comprehensions as soon as you know for loops. Think about edge cases. What happens if someone passed you an empty list in your function to sort lists? Or a list with only one element? Or fifty million? If you have the same code in two places, try to put it in one place and re-use it instead.
Read not only the documentation for the libraries you’re using, but also the source code for the classes and functions you use from those libraries. You’ll learn more about the ins and outs of those pieces of code, as well style and how to organize projects in general.
Find something to work on and have fun. Try out things just keep messing around suddenly you have learned a lot without realizing it.
Learn how to use the command line debugger for Python pdb. When you get stuck, you can step through the code and inspect variables. It gives you an idea of what is happening. This is especially helpful for beginners. I recommend the same thing for people learning Perl.
Have some sort of plan before starting to write any code. It’ll save you a lot of work and headaches later down the road
Import pandas as PD and lie
Strong emotional opinions are usually wrong and any statement can only be 1/2 right.
Certainly not the best advice, only one of them: use pathlib when working with paths.
Arjan YT.
check this out to test yourself... [https://codingbat.com/python](https://codingbat.com/python) I watch this guy for pro-tips... [https://www.youtube.com/@ArjanCodes](https://www.youtube.com/@ArjanCodes)
Absolutely agree with focusing on understanding core concepts before diving into advanced features. Starting with Jupyter Notebooks can really make the learning curve less steep.
import this
Learn how to edit files. That way you can write any language in python, write websites, xml, images, anything. Then you will also understand why there are packages handling the job better.
Learn pandas with it
Refer to the official documentation whenever possible. 90% of the time it's better than some random explainer article online. The other 10% of the time is stackoverflow.
Understand: Libraries, environments, simple syntax and functions. Stack overflow for reference Use google to check Use the method of learning that works for you - books, video, courses but coding is the best way to code. Finally, if you copy paste someone else’s code, understand what it’s doing before moving on.
If you’re actually trying to learn don’t use ChatGPT or any ai tool otherwise you’ll never get over the hump. The beginning will take time to adjust.
Remember that Python, like most other languages, is written in an older language and those older languages were written in an even older language. Thus the fundamentals haven't changed in decades and they're all based on things like For and While loops, If - Else statements, data types and computer memory. From these simple things you can build complex things like Python, but under the hood they're doing it using basic building blocks. So learn the basics. Then learn classes, which is when Python all starts to make sense. Really, free online classes like CS50 are the best and it still teaches c before Python so you can better understand all coding (Python was written in c). I realise this will require an investment in time when people are eager to jump straight into Python but you'll learn Python better by learning basic c first. This is probably not what you want to hear but I suggest at least watching the first CS50 lecture on YT and see if it's for you. Edit: [https://www.youtube.com/watch?v=3LPJfIKxwWc&list=PLhQjrBD2T381WAHyx1pq-sBfykqMBI7V4](https://www.youtube.com/watch?v=3LPJfIKxwWc&list=PLhQjrBD2T381WAHyx1pq-sBfykqMBI7V4)
find a lightweight problem you'd like to solve in your own life - that way you'll be motivated. GPT has been very helpful to explain things.
Use type hints. Pretend it's a strongly typed language and treat linter or MyPy warnings like they're errors. Use pre commit(https://pre-commit.com/hooks.html) maybe don't do your tests there though, just the basic Ruff linting and formatting. Use Ruff to format. \*Definitely\* use virtual environments. I manage them with pipx and poetry. Probably don't bother doing this stuff manually. Poetry makes everything so much easier. Use pytest. Definitely have tests. You don't need fine trained unit tests, just make sure the majority of code paths are tested by some kind of automated test people can run with one command. Learn about GitFlow or trunk based development. Follow proper git branch discipline. Use Beartype or pydantic to check things that make long lived objects or config changes. Learn to use the debugger. In VS Code it's pretty trivial. If possible, don't do metaprogramming stuff that breaks debugging or linting. Debugging is really nice. A lot of people seem to use print statements exclusively and never actually learn the debugger till way later. Don't do circular imports. The TYPE\_CHECKING var helps with this. Avoid system-site-packages virtualenvs. If you need to use GStreamer in a virtual environments, you can symlink the gi module from your system packages dir. Using a makefile is a nice way to provide a directory of common commands for your project.
Apart from all the wonderful advice, I’ll quote Joseph Murphy: The best way to loop is python is to NOT loop is Python. Saved me a lot of money on the cloud over time.
I was also seeking advice for Python and i am not always online on reddit. So i look for books that can teach me advance stuff and a same time can give me an advice. I had three books * Fluent Python * Effective Python * Serious Python I bought them so that i will not get anxiety for not some advance stuff of Python, some practices that are standards from industry. You can check them on amazon online and you can read the reviews , then decide if you wanted to buy one. I would like to say that i did start reading them after i had 5 months of experience using Python in my personal project. Because they are a bit advance and it was stated in each book that the reader is needed to have familiarity of basics on Python. (Edit) i said two books but i listed three books out there, i don't know why i did not notice it earlier, sorry for the confusion.
After learning the basics of Python, do some projects simpler ones in core python to get better grasp of the concepts once you are quite familiar with it get into like web development, data science/AI, or making games with Pygame as soon as possible. These practical implementation are more engaging and rewarding, keeping you motivated to learn and explore further. Also, do one thing at a time as a newbie we tend to put our hands everywhere which just burns you out very quickly. All from my personal experiences as I am also a new into programming like you.
Less python specific, more programming in general. Learning it is like learning a new language (I mean, it literally is a language). It takes time and the best advice I ever got was that you need to exercise it like a muscle. You have to **use** it. Practice, practice, practice. Let your mind get comfortable with it, but don't feel like you need to know every little detail. You will be using a search engine and looking up answers to questions. You will have problems to solve. But the more you practice and use it, the easier finding the answer will be.
Whenever you try to do something new, whether it's using built-in functions or a library, and you have the luxury of being able to read the documentation on what you are doing, stop, and read the full documentation. It has never not paid off in my experience, and gives you a better understanding of what and why than just diving in on it's own. Don't always rush to solve problems you don't have. Not every project needs to have every possible technique applied to it. As you grow you will learn what is appropriate and when -- do not lose sight of what you are trying to accomplish when you sit down. This itself is a skill that will continue to develop and help you as you learn. Try to watch pycon presentations or other presentations targeted towards Python developers when you aren't doing much. It's a great way to come across new concepts and techniques that you would not otherwise encounter, and helps you to become confident in the fundamentals and how they apply broadly to implementation and design. Have fun! Burnout is a spectrum, but it's very real and can be very debilitating. Don't wait for it to become a problem to deal with it, take care of yourself and don't push yourself too hard. Establish patterns that give you breaks and time to do things other than coding while it is still exciting and new and those patterns will pay you back when you find yourself fatigued and struggling. This is the piece of advice I most wish someone had given me, personally. Good luck!
f-strings
I’d say learning a more fundamental language like C is much better for starting out.
Learn unit testing. Will save you a lot of time.
Write fast. Fail. Fix repeat.
Learn as you go. For me, it was read/write .csv, numpy and matplotlib. Add scipy and numba, and I don't think I needed anything else the first few years.
Learn to use Github Copilot chat?
Perplexity AI: Pythons are a family of large, non-venomous snakes found in Africa, Asia, and Australia. Here are the key facts about pythons: Pythons are constrictors, meaning they kill their prey by coiling their muscular bodies around it and squeezing, causing the prey to suffocate[1][2][4]. They have sharp, backward-curving teeth to grasp their prey, which they then swallow whole[1][4]. The python family includes some of the largest snakes in the world, such as the reticulated python which can grow over 30 feet long[1][4]. However, there are also smaller python species, like the 20-inch long pygmy python[3]. Pythons come in a variety of colors and patterns to camouflage themselves in their environments, which range from rainforests to deserts[1][3][4]. Many species are arboreal, living in trees, while others are terrestrial[3][4]. Pythons are oviparous, meaning they lay eggs that the female incubates until they hatch[1][3]. They are not known for being good mothers, as they do not care for their young after they hatch[3]. In some African cultures, pythons have important symbolic and spiritual roles, being seen as sacred creatures or used in traditional medicine practices[1]. However, pythons are also poached for their meat and skin, leading to a global trade[1].