Starting first year university Comp Sci. python language advice.

[igotsnomoney]

There are only two months from now and my first year at U of T. From what I heard, first year students use the python for the CS courses. I have heard of it before but never actually tried it. Any advice for learning the language.

 

I took high school programming courses for two years now and I have a decent concept of OOP, Hierarchy, and recursion All done on java (I know a little bit of  C# too but its basically the same thing as java). What are some of the major differences from Java to python?

 

 

[Guest]

Heyo! I just finished first year CS at UofT. 

 

Yes, we do use Python. We used this in CSC108: http://interactivepython.org/courselib/static/thinkcspy/index.html

 

Python is easier than Java/C# in my opinion. (I did C# in high school.) Python is a bit more free, allowing you to define variables without stating what types they are, and the OOP in Python is sort of shady, in the sense that there's no proper way to state if classes are public/private. That, and you don't need semicolons!

 

Here's the UofT CS forums, by the way: https://csc.cdf.toronto.edu/mybb/

 

 

EDIT: If you're comfortable enough with Python, you can actually jump straight to CSC148. They offer a ramp up session before classes start to rapidly teach Python to people who aren't that familiar with it too. Of course, you could just take CSC108 as a bird course to boost your GPA like I did.

[laxer]

To give you another opinion...

 

I just finished the second year of my CS major with the majority of the programming done in C/C++.(some cShell via *nix but it's all the same)

 

Like Arkon stated above, I find Python a more user friendly language than java and the C variants. With that said it does have it's caveats with things like more complex data structures.

 

At the end of the day I think you will have an easier time understanding Python than the previous languages you've learned.

 

If you want to get a jump start the link Arkon gave you above seems very well structured. 

[wolfsinner]

You shouldn't expect a very deep OOP support. Python is lacking (and, in my opinion, is its only flaw) in good OOP support.

 

Other than that, Python is great. Like others have said, Python is a much more forgiving language than Java. This forgiveness comes in the form of:

• Coercion (variable types are dynamically changed on the fly, when an expression is evaluated);
• A lot of data structures (lists, tuples, etc) are already implemented within the language core (making your life easier);
• Memory is managed by the interpreter;

Also, it allows static linking and passing functions as a parameter (and makes it a piece of cake), it forces you to use indentation, it is a scripting language and thus allows scriptception, it has very versatile constructors, etc.

 

All in all, I think you'll love Python. Just heed my advice: don't slack, use semicolons.

[Guest]

All in all, I think you'll love Python. Just heed my advice: don't slack, use semicolons.

 

While this works fine in Python, you'll lose marks for doing this since it's not allowed in the PEP8 style guidelines.

[wolfsinner]

While this works fine in Python, you'll lose marks for doing this since it's not allowed in the PEP8 style guidelines.

 

This isn't true. PEP8 makes no mention of semicolons being illegal or "not allowed". Semicolons are absolutely legal in Python, and anyone that penalizes someone for writing code with semicolons is an idiot. As simple as that.

 

The reason why I always recommend people to write semicolons is because most languages require them. So, if someone writes Python code for a long time without them, they might get used to not writing a semicolon and later have a painful time debugging their semicolonless code. Actually, even with languages like JavaScript that have "optional" semicolons, not using them leads to erroneous and ambiguous interpretations (this is not the case with Python).

[Guest]

This isn't true. PEP8 makes no mention of semicolons being illegal or "not allowed". Semicolons are absolutely legal in Python, and anyone that penalizes someone for writing code with semicolons is an idiot. As simple as that.

 

The reason why I always recommend people to write semicolons is because most languages require them. So, if someone writes Python code for a long time without them, they might get used to not writing a semicolon and later have a painful time debugging their semicolonless code. Actually, even with languages like JavaScript that have "optional" semicolons, not using them leads to erroneous and ambiguous interpretations (this is not the case with Python).

 

Nope.

 

[wolfsinner]

Nope.

 

Clearly that is bad parsing. This error is for single-line compound statements. The reason why that error is shown is probably because the parser's grammar assumes that whenever you're using a semicolon, you're going to have single-line compound statements.

This, to me, is no evidence.

Please reference official documentation, where it is stated that semicolons are discouraged, and then I'll accept your argument. I've read it before, and I can tell you with almost 100% certainty that no such "limitation" or "discouragement" exists. They simply assume that you won't be using semicolons.

[NeoZeon]

TBH, python's biggest flaw isn't its lack of OOP support, which it actually does quite well despite what computer science professors will tell you. It's related issue, is that it is terrible for HPC applications. It takes more Calculations to get from Point A to Point B than say C++ does. 

[Darkfeign]

TBH, python's biggest flaw isn't its lack of OOP support, which it actually does quite well despite what computer science professors will tell you. It's related issue, is that it is terrible for HPC applications. It takes more Calculations to get from Point A to Point B than say C++ does. 

 

This is true of practically any dynamic language, though. C++ is compiled, so it will inevitably produce high performance for HPC applications. Python can be used with a JIT to speed it up, but Python provides speed of writing for projects that C++ hinders. They all have different benefits/drawbacks.

[wolfsinner]

TBH, python's biggest flaw isn't its lack of OOP support, which it actually does quite well despite what computer science professors will tell you. It's related issue, is that it is terrible for HPC applications.

 

Actually, I never even had Python while taking Computer Science. The reason why I think it has poor OOP support, is because I've written enough Python code to think so.

 

Python has poor OOP support. It is enough to get by, but it is still quite poor.

[Guest]

Actually, I never even had Python while taking Computer Science. The reason why I think it has poor OOP support, is because I've written enough Python code to think so.

 

Python has poor OOP support. It is enough to get by, but it is still quite poor.

 

It's not too bad. You can actually make variables/classes private by putting double underscores before them. (eg: __a = 1 inside class Foo wouldn't be accessible outside, although it would just give some generic error that isn't very helpful)

[wolfsinner]

It's not too bad. You can actually make variables/classes private by putting double underscores before them. (eg: __a = 1 inside class Foo wouldn't be accessible outside, although it would just give some generic error that isn't very helpful)

 

Encapsulation is only one of the problems of OOP in Python. Your workaround uses name mangling, which purpose isn't really encapsulation, but rather to control overriding by sub-classes.

Python doesn't have any true encapsulation, it is all convention.

Run this example:

class Foo:    __a = 1 obj = Foo()obj._Foo__a = 2print obj._Foo__a

But a significant lack of features in Python's OOP is mainly what I mean.

 

(By the way, I did reply to your original "Nope." post, in case you didn't notice. :P)

[Guest]

Encapsulation is only one of the problems of OOP in Python. Your workaround uses name mangling, which purpose isn't really encapsulation, but rather to control overriding by sub-classes.

Python doesn't have any true encapsulation, it is all convention.

Run this example:

class Foo:    __a = 1 obj = Foo()obj._Foo__a = 2print obj._Foo__a

But a significant lack of features in Python's OOP is mainly what I mean.

 

(By the way, I did reply to your original "Nope." post, in case you didn't notice. :P)

 

Heh yeah. They sort of just trust that you won't do this, but oh well.

 

Hrm yeah. I guess it's also convention that you don't use semicolons on single lines. Our classes use the PEP8 file provided though, so we end up losing marks because of the way it checks the code. Ah well, just a warning to the OP.

[wolfsinner]

Heh yeah. They sort of just trust that you won't do this, but oh well.

 

Hrm yeah. I guess it's also convention that you don't use semicolons on single lines. Our classes use the PEP8 file provided though, so we end up losing marks because of the way it checks the code. Ah well, just a warning to the OP.

 

Well, if it's based on trust, then essentially it's no different than a public attribute. :P

 

And about the losing marks part, I really don't think it is correct at all to blindly cut marks based on whether or not that parser throws an error. That information isn't correct, ie, the problem isn't the semicolon but rather the parser saying that you have a single-line compound statement when you don't. So I hope teachers at UoT look at the error messages and actually understand what they mean.

There is also no convention on not using semicolons. They assume you won't use them because most programmers are lazy, but there is no real convention on it (there is convention with "private" attributes).

[Guest]

Well, if it's based on trust, then essentially it's no different than a public attribute. :P

 

And about the losing marks part, I really don't think it is correct at all to blindly cut marks based on whether or not that parser throws an error. That information isn't correct, ie, the problem isn't the semicolon but rather the parser saying that you have a single-line compound statement when you don't. So I hope teachers at UoT look at the error messages and actually understand what they mean.

There is also no convention on not using semicolons. They assume you won't use them because most programmers are lazy, but there is no real convention on it (there is convention with "private" attributes).

 

Most of the exercises/assignments are marked by running testing programs, so they're automatically docked. Students do have an option of appealing for the marks though, so I guess you could argue about the semicolon thing with the profs.