|
Drunk Badger posted:Things I don't know if I really need because I'm new to this and have no formal training? You don't need them at all. In fact, pep8 explicitly says to not use them.
|
# ? Feb 14, 2013 18:05 |
|
|
# ? May 9, 2024 05:14 |
|
Good to know, thanks
|
# ? Feb 14, 2013 18:15 |
|
pep8 being the official Python style guide: http://www.python.org/dev/peps/pep-0008/
|
# ? Feb 14, 2013 18:17 |
|
I need to get better at remembering PEP8. That code I posted above is a pretty fair approximation of how I stylistically code, for whatever that's worth.
|
# ? Feb 14, 2013 18:58 |
|
JetsGuy posted:I need to get better at remembering PEP8. I code similarly. I think it's just carry over from Matlab warping my brain.
|
# ? Feb 14, 2013 19:25 |
|
There are packages to turn on PEP8 warning for Emacs and Vim, and probably most other editors. It does help a bit to have your editor nagging you not to code like a mook.
|
# ? Feb 14, 2013 19:30 |
|
PyCharm does PEP8 evaluations as well. Speaking of PyCharm, I bought it when they were doing that $25 sale a couple months ago. I've been using it exclusively since then. My review: it's pretty great! Definitely my favorite Python IDE.
|
# ? Feb 14, 2013 19:32 |
|
Drunk Badger posted:Things I don't know if I really need because I'm new to this and have no formal training? Python uses the newline as a terminator, so you only need to use semi-colons if you're banging poo poo into one line (don't do this) They're harmless, so don't worry about it too much. If anything they just demonstrate you're new to python (and that's ok!)
|
# ? Feb 14, 2013 19:45 |
|
Drunk Badger posted:Here's an example from a routing simulator I'm building. As was said above, you get same values each time because they are evaluated when you add them to the list not in the loop. This does what you want: Python code:
You can also randomize initial nodes with something like that: Python code:
evilentity fucked around with this message at 19:51 on Feb 14, 2013 |
# ? Feb 14, 2013 19:48 |
|
JetsGuy posted:I need to get better at remembering PEP8. I usually just run this before committing code and fix the flaws it points out: https://github.com/jcrocholl/pep8 Maybe it's time to hook up some Vim scripts do that while editing though.
|
# ? Feb 14, 2013 21:07 |
|
evilentity posted:Amazing words That looks like it will work, thanks! For the most part Python is making sense, I'm taking a (unrelated) cryptography course that requires coding so I'm using that as a way to force myself into finally learning it. I'm at the point where I want to move from just writing code that doesn't produce errors or start computers on fire to writing more efficient error-resistant and fireproof code, so I figured there was a better way than giant for clusters to do what I wanted.
|
# ? Feb 14, 2013 21:28 |
|
Does anyone else have random issues with emacs deciding to indent too far, too little or whatever? Sometimes I'll start a block like: if whatever > this: and emacs will decide to give it a two tab indent instead of a one tab indent It seems completely random as to when it happens! Another thing that really hacks me off is sometimes when I comment out a line of code and emacs randomly decides that it should be indenting that too. Also, definitely using the pep8 package, but every instruction I've been looking at to integrate it into emacs is awfully written, so I guess I'll just use it in the terminal. EDIT Christ on a cracker, PEP8 likes to bitch about "mixing tabs with spaces" on lines where I'm continuing a previous one. I suppose the "acceptable" route is to go just spaces here? JetsGuy fucked around with this message at 21:53 on Feb 14, 2013 |
# ? Feb 14, 2013 21:45 |
|
Configure your editor to output four spaces when you hit tab.
|
# ? Feb 14, 2013 21:52 |
|
BeefofAges posted:Configure your editor to output four spaces when you hit tab. EDIT: confusing tabs with indention settings
|
# ? Feb 14, 2013 21:55 |
|
BeefofAges posted:Configure your editor to output four spaces when you hit tab. My only problem with using spaces like that is that a depressing number of editors can't be configured to delete back to a tab stop, even when they have an option to insert spaces when you hit tab. Having to remove a single keystroke with four just annoys the poo poo out of me (because I'm a big whiny baby, obviously, but that's not going to change).
|
# ? Feb 14, 2013 22:00 |
|
So I've tracked down why emacs decides to randomly indent commented lines of code. It happens when I comment out a block that follow a loop. So for example: code:
code:
Munkeymon posted:My only problem with using spaces like that is that a depressing number of editors can't be configured to delete back to a tab stop, even when they have an option to insert spaces when you hit tab. Having to remove a single keystroke with four just annoys the poo poo out of me (because I'm a big whiny baby, obviously, but that's not going to change). Maybe I'm misunderstanding, but my emacs seems to do "insert x space" fine, and once it understands what kind of code you're writing, it'll let you delete back to the last tab stop (instead of deletex4) if you want to get out of a nested loop or something. (I use aquamacs emacs if that makes a difference)
|
# ? Feb 14, 2013 22:11 |
|
Munkeymon posted:My only problem with using spaces like that is that a depressing number of editors can't be configured to delete back to a tab stop, even when they have an option to insert spaces when you hit tab. Having to remove a single keystroke with four just annoys the poo poo out of me (because I'm a big whiny baby, obviously, but that's not going to change).
|
# ? Feb 14, 2013 23:52 |
|
Sailor_Spoon posted:pep8 being the official Python style guide: http://www.python.org/dev/peps/pep-0008/ I've never liked PEP8, there's some good stuff in there but also a lot of crap ("When writing English, Strunk and White apply.")
|
# ? Feb 15, 2013 01:43 |
|
fritz posted:I've never liked PEP8, there's some good stuff in there but also a lot of crap ("When writing English, Strunk and White apply.") Strunk and White being a rule is probably the best argument in favor of PEP8 possible.
|
# ? Feb 15, 2013 01:56 |
|
Emacs Headroom posted:Strunk and White being a rule is probably the best argument in favor of PEP8 possible. Actually, S&W had no formal training in grammar. That book has an undeserved reputation, and those guys were hardly the masters of English that most people think they were.
|
# ? Feb 15, 2013 02:08 |
|
What really matters is that PEP8 helps consistency. I'd rather have consistently styled code than code that matches every programmers personal desires.
|
# ? Feb 15, 2013 02:10 |
|
FoiledAgain posted:Actually, S&W had no formal training in grammar. Neither did Shakespeare. That book is genius (along with Orwell's essay "Politics and the English Language"), I don't care what anyone says.
|
# ? Feb 15, 2013 02:12 |
|
The notion of having an "official style guide" is awful. The idea that you're not free to adopt your own set of formatting conventions for your project, no matter that they're consistent and work well for you, because some busybodies decided to codify what they think everyone else's code should look like.
|
# ? Feb 15, 2013 02:13 |
|
Hammerite posted:The notion of having an "official style guide" is awful. The idea that you're not free to adopt your own set of formatting conventions for your project, no matter that they're consistent and work well for you, because some busybodies decided to codify what they think everyone else's code should look like. I agree if you're not doing open source work.
|
# ? Feb 15, 2013 02:14 |
|
Thermopyle posted:I agree if you're not doing open source work. Why on Earth would that make a difference to anything? I think if I were to have read PEP 8 and discovered that quite by coincidence my preferred formatting conventions matched its prescriptions to a tee, I should have chosen to alter key elements so that they no longer matched, purely out of principle.
|
# ? Feb 15, 2013 02:19 |
|
Emacs Headroom posted:Neither did Shakespeare. Shakespeare wasn't offering grammatical advice. Elements of Style is full of mistakes you don't care about English grammar if you think that's a good book. But now I'm in angry linguist rant mode in the wrong thread. I promise to stop the derail now.
|
# ? Feb 15, 2013 02:29 |
|
FoiledAgain posted:Elements of Style is [so] full of mistakes [that] you don't care about English grammar if you think that's a good book. Yeah that's probably right. edit: not trying to be snarky, legitimately agreeing
|
# ? Feb 15, 2013 02:30 |
|
Strunk and White is basically Poe's Law applied to prescriptive linguistics.
|
# ? Feb 15, 2013 02:32 |
|
Hammerite posted:Why on Earth would that make a difference to anything? Lots of languages have them, both official and unofficial. Do you have something against a starting point for good code formatting? There's no one forcing PEP8 compliance on things you write; the interpreter won't throw it back at you. PEP8 just gives Python a default style guide to follow when contributing code rather than "whatever the other code is like, except where it's different".
|
# ? Feb 15, 2013 02:33 |
|
Hammerite posted:The notion of having an "official style guide" is awful. The idea that you're not free to adopt your own set of formatting conventions for your project, no matter that they're consistent and work well for you, because some busybodies decided to codify what they think everyone else's code should look like. Use a language with braces if you want to have your snowflake whitespace formatting
|
# ? Feb 15, 2013 02:38 |
|
Hammerite posted:The notion of having an "official style guide" is awful. The idea that you're not free to adopt your own set of formatting conventions for your project, no matter that they're consistent and work well for you, because some busybodies decided to codify what they think everyone else's code should look like. You're free to completely ignore PEP8 for whatever reasons you want. The code will still work.
|
# ? Feb 15, 2013 02:40 |
|
There is no "best style convention". An official style guide is useful because it makes everyone's code look the same, so that you can forget about style and just think about logic.Munkeymon posted:My only problem with using spaces like that is that a depressing number of editors can't be configured to delete back to a tab stop, even when they have an option to insert spaces when you hit tab. Having to remove a single keystroke with four just annoys the poo poo out of me (because I'm a big whiny baby, obviously, but that's not going to change). Most editors support hitting shift-tab to delete a tab.
|
# ? Feb 15, 2013 04:00 |
|
Suspicious Dish posted:You're free to completely ignore PEP8 for whatever reasons you want. The code will still work. Yeah, I really don't see how having an optional yet official style guide for a language is anything but a good thing for a language's growth. New people get a baseline style to use for their coding, and adoption in Open Source projects make it easier for contributors to get involved. If you start on a new language, either you use existing code as examples and guess proper style based on your own preconceptions, or you find a document that spells it out for you. I would've thought the latter is more appropriate.
|
# ? Feb 15, 2013 04:19 |
|
Hammerite posted:Why on Earth would that make a difference to anything? What is wrong with you? PEP 8 posted:A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important. Yes, this definitely means that you're not free to decide on your own style for your project PEP 8 is a guide. If you're new to programming and don't really have a coding style, or you're new to Python and are tempted to carry over style habits that don't really apply to Python's syntax, PEP 8 is a good place to start. PEP 8 pretty much says says "do whatever you want; these are recommendations from people who write a lot of Python code".
|
# ? Feb 15, 2013 04:26 |
|
Lysidas posted:What is wrong with you? A lot of the responses to what I posted (or comments that may have been partially prompted by what I wrote) have been along the lines of "look guy, you aren't obliged to follow the suggestions in PEP 8. They're a default for people to start out with". Or similar. If that's all it was then I wouldn't have a problem with it. But that's not all it is, because as soon as you endorse a default style you get people saying snarky things like xtal posted:Special cases aren't special enough to break the rules. My problem isn't with anyone who really does just see it as a suggestion. My problem is that people think it's a set of rules and that it's wrong to "break" those rules (as opposed to them merely being guidelines that you can disregard if you like). If you're not one of those people then great. Maybe my post was immature, but I guess I have a streak of bloody-mindedness that prompts me to resent being told I have to format my code in a certain way when I like another way better!
|
# ? Feb 15, 2013 05:12 |
|
Can someone explain to me the way that Python variables behave in closure like situations?code:
|
# ? Feb 15, 2013 06:16 |
|
Innocent Bystander posted:Can someone explain to me the way that Python variables behave in closure like situations? It looks like the functions stored in myLat evaluate their return values when called, not when defined. Since the variable "a" referenced in each function is still needed, a reference to that variable sticks around, and of course it has the last value it was given, which is 2. It looks like there is an accepted way to get Python to accept the value of "a" that was in place at the time the function was defined. You declare it as an argument with a default value. The default value is evaluated at function definition time. So your function would become code:
code:
|
# ? Feb 15, 2013 06:29 |
|
Hammerite posted:
No, it's: code:
|
# ? Feb 15, 2013 06:57 |
|
Innocent Bystander posted:Can someone explain to me the way that Python variables behave in closure like situations? I hope so, but I may have gone into a little too much detail. Hopefully this is correct, but I could be confused too. quote:I consider my understanding of when Python uses pointer-like variable and when it doesn't my weak suit. Anyone care to explain? Python always uses pointer like variables. Essentially, python has names, and objects. Names store a value, which is the address of an object stored in memory. List and Dict objects can contain values, but these values are always the addresses of python objects in memory. Python doesn't have value types, it only has reference types. Unlike java, c# it has no primitives (and like ruby), just objects. code:
Thing is, if python used primitives, instead of pointers and an object, the code above would look the same and act the same, but only because the objects we're using are immutable. Objects like Strings, numbers, tuples, and others in python are immutable—you cannot change them after you have created them. Lists, dicts, on the other hand, can be mutated to point to different objects after they are created. To demonstrate the difference between changing a name, and changing an object- code:
To recap: python has names and objects. names store the addresses of objects in memory. calling a function copies the addresses passed to it, returning an address. some objects are mutable, some are immutable. changing what address a name stores doesn't change the objects underneath. Now we understand names and objects, next is to understand how names are resolved in python. Python uses a series of nested environments, which store names and the objects they point to, a bit like a dictionary in python. By default, names live in the top level environment, or the global scope. When you define a function, you create a new inner environment, a local scope for resolving names, that falls back to the outer environments when the name doesn't exist. When you use the same name inside and outside a function, python uses a few rules to decide if the name is going to be local to the function, or use the existing name outside, working back up to the top-level environment. code:
If you try and update an outer name and look it up, you'll run into problems. code:
code:
Now we understand names, objects, and environments, we can see how they work for closures, or functions inside functions. code:
Let's look at some similar code to your example, now with our knowledge of environments, names and objects, and how they fit together. code:
To share different objects, we need to create a different environment for g and h, rather than them both sharing f's. We can create a different environment, by wrapping g and h in another function. code:
code:
code:
If we used immutable objects instead of mutable objects, we would't have to worry about sharing them, but we are faced with a different problem—How do you rebind a name in closure, and keep this change between calls? We might try using default variables, but changing a name doesn't last between calls code:
code:
For python 3 users, we can use the 'nonlocal' keyword. code:
(http://docs.python.org/2/reference/executionmodel.html should answer any further questions) tef fucked around with this message at 11:10 on Feb 15, 2013 |
# ? Feb 15, 2013 09:37 |
|
|
# ? May 9, 2024 05:14 |
|
drat that was a good writeup, A++ for effort and clarity
|
# ? Feb 15, 2013 10:11 |