I've recently did some web design as a hobby with a primary motivation to learn interesting things. It was certainly nice to learn Python, but I found out there has just been a Great Python Rewrite too late, so I had to learn both Python 3 and 2.6 essentially.
I'm a newbie, so I'd like people to share what they think the strengths/weaknesses of Python 3 are from the perspective of those who do end-user programming rather than language designers. My question would be more of what people are actually liking to the point of using, or shunning as being unproductive or unpythonic.
For me, with statement is definite plus, while breaking print operator is definitely minus.
Clarification edit: there are many posts that ask whether one should learn Python 2 or 3 or whether there is any difference. I see my question is different: the feedback from people who for whatever reason made the choice of using Python 3 but might have an opinion about what works better, what not.
Another clarification: It has been pointed in the answers that with is backported to 2.*. Apologies.
I'm not using Python 3 "in production", yet, but in playing around with it I've found that print being a function is a superb idea -- for example, I can easily put it in a lambda now, where in 2.* I have to use sys.stdout.write("%s\n" % foo), a bit crufty. Plus, the syntax for such tweaks as using an output file different from sys.stdout or removing the final \n is so much more readable than Python 2.*'s!
BTW, with is also in recent Python 2.* versions, it's not a Python 3 - exclusive.
Well a strong point is the clarification between bytes and string. How many times in your short Python experience have you been confused with the unclear UnicodeDecodeError and UnicodeEncodeError? If you never had troubles with unicode vs bytestrings, well chances are that you are using an ascii-only language, (English? ;) ) but this is usually the concept which is the hardest to grasp for beginners. (by the way, if you're still confused, this link should help for Python 2.x)
I really think that this distinction between str, and bytes, is one of the strong points of Python3.0. Read PEP358 for the formal description, and the diveintopython class for something more end-user oriented. This new feature forces developers to maintain a clear distinction between unicode objects, and bytes objects which are encoded in a specific encoding. I believe that this change will help newcomers understanding more easily the difference between the two structures, and will help experienced developers using sane programming methods.
But of course this change has its own inconvenients: porting 2.x applications is quite difficult, and these str+unicode to str+bytes change is the most annoying thing to change if you are not already clearly separating Unicode and byte strings in your 2.x code. Annoying, but long-needed.
Those breaking changes look annoying to a lot of users, and... are annoying to implement for important librairies/solutions. The current force of Python2.x is the numerous third-party applications/modules: but because it is sometimes not-trivial to port to Python3, those third-party apps will need some time to be ported (and because 2.x is still alive, those applications will need to maintain two versions: one aimed to 2.x clients, and one to 3.x... costly maintenance!) For the next year, the number of fully-fledged application running Python3 will likely be quite low, because of the low number of Python3-compatible third parties. But again, I strongly support these breaking changes: have you read this Monkey, banana, Python(3) and fire hose tale? ;)
I think everything they did was for the best, in the long run. They removed a lot of the deprecated ways to do things, thus enforcing "There's Only One Way to Do It" and increasing consistency. Also, the with statement is awesome.
The obvious problem with using Python 3 is its lack of support for a lot of [big] libraries out there (such as Django). If none of your libraries break with Python 3, there's no reason not to use it.
I really like dictionary comprehension:
{k: v for k, v in stuff}
And extended iterable unpacking:
(head, *rest) = range(5)
This is really subjective. Python3.x is certainly an improvement over 2.x. It contains long anticipated changes like: Dictionary comprehensions, ordered dictionary, more powerful string formatting...etc Not to mention cleaner library.
Related
I'm starting a new project and don't know which language to use.
My 'must have' requirements are:
Be able to run on Windows/LinuxMacOs natively (native executable) – user should be able to just run the .exe (when on Windows, for example) and see the results.
No runtimes/interpreters (no JVM, CLR etc.) – one file download should be enough to run the application.
Full Unicode support.
Be able to manipulate OS threads (create them, run multiple tasks in parallel on multi-core CPUs, etc.)
Be reasonably fast (Python level performance and better).
To have some kind of standard library that does low-level, mundane tasks.
Not very niche and have some community behind it to be able to ask questions.
My 'nice to have' requirements are:
Language should be functional.
It should have good string manipulation capabilities (not necessarily regex).
Not extremely hard to learn.
I'm thinking about Haskell now, but keeping in mind OCaml as well.
Update:
This application is intended to be a simple language parsing and manipulation utility.
Please advice, if my choice is correct.
Haskell:
1: It runs on Linux, Windows and OS X, in many cases without changes to source code.
2: Native binaries generated. No VM.
3: Full Unicode support. All UTF variants supported.
4: Full threading support, plus if you only want parallelisation then you can use "par" with a 100% guarantee that it only affects the time taken rather than the semantics.
5: As fast as C, although some tweaking can be required, the skills required are currently rather obscure, and apparently minor tweaks can have multiple orders of magnitude impact.
6: Standard library included, and "Hackage" has lots more packages including a range of parser libraries.
7: Friendly community on IRC (#haskell) and here.
Edit: On the "nice to have" points:
1: Haskell is an uncompromisingly pure functional language.
2: It has generally good string manipulation, with regexes if you want them. As someone said in a later comment, beware the efficiency of the built-in "String" type (it represents a string as a linked list of characters), but the ByteString and Text libraries will solve that for you.
3: Is it hard to learn? Its nowhere near as complicated as C++, and probably a lot simpler than Java or even maybe Python. But its pure functional nature means that it is very different to imperative languages. The problem is not so much learning Haskell as unlearning imperative thought patterns.
Haskell sounds like it fits the bill perfectly. GHC produces native code on OS X, linux and windows just fine, and in general has performance that is much better than Python (for many things, not everything).
The only strange request is the need for OS threads. Programs produced by GHC use lightweight threads, which perform much better than OS threads, and much easier to work with than pthreads.
Haskell is also excellent for language parsing, using libraries like Parsec.
We're also quite well known for how string and helpful the community is around Haskell.
To your third nice to have: Have a look at Real World Haskell, it's free and a very good introduction, including an introduction to all the points you need. (Such as parallel computing, string parsing, etc).
Maybe 'nice to have':
yes pure functional and lazy evaluation.
yes (as said before).
depends on you, I think it's hard to learn,
but gives you some great benefits.
What are the current rules for writing python code that will pass cleanly through 2to3 and what are the practices that seem to be best suited to writing code that will not become mired forever in version 2.
I have read from the SciPy/NumPy forums that "100% test coverage" (unit testing) is important for many people, and I am not sure if that would apply to everybody. Certainly having a reasonable set of unit tests to try your code out with after conversion, seems a sane step.
Are there other things? What are skilled Pythonistas doing if they are writing 2.x code that they hope to have come through "cleanly" in the 2to3 process.
I am looking for specific instances of "[don't] do this" as well as some more general "best-practices", but specific instances of "do's and don'ts" are helpful.
Let's assume that frameworks, libraries (Django, SciPy/NumPy), and every other C Extension we need gets ported to Python3 eventually, and I'm asking about how you write and maintain the pure python language code that you write yourself.
Update: It's possible that what I really want is the "style guide" and list of deprecated features that everybody was already staying away from. I cut my teeth on Python 1.5 and moved to 2.0, and then have not really followed much of the 2.5/2.6 era, used them but really my code is more 2.1 era.
I'd say:
Read the "What's new for Python 3.0". Very informative.
In particular, if you care about Unicode or text encodings at all, take the time to understand what has changed for 3.x. That's probably one of the trickier things to change for Python 3.x.
Get Python 2.6 or 2.7, and run your code with the -3 flag. It will tell you about things in your code that will need changing.
Before using 3rd-party packages, check to see if they have a Python 3.x version. If not, check the package web site, mailing lists, version control repositories etc to see how actively the package is being developed and whether there is a roadmap towards Python 3.x support.
Download Python 3.x and try it out! Admittedly, that might not be practical if you care about code that currently depends on packages that don't yet support Python 3.x (e.g. wxPython or Django).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
C++ is my first language, and as such I'm used to whitespace being ignored. However, I've been toying around with Python, and I don't find it too hard to get used to the whitespace rules. It seems, however, that a lot of programmers on the Internet can't get past the whitespace rules. From what I've seen, peoples' C++ programs tend to be formatted very consistently with respect to whitespace (or else it's pretty hard to read), so why do some people have such a problem with whitespace-based languages like Python?
It violates the Principle of Least Astonishment, because we have it ingrained in ourselves (whether for good or bad) that whitespace Does Not Matter in a programming language. Whitespace is one of those issues that has been left up to personal style.
I still have bad memories back from being a student of learning the hard way that 8 spaces is not equivalent to a tab in a Makefile... Ah, the sleep I lost...
The only valid reason I have come across is that refactoring using cut-and-paste (not copy) without refactoring tools (or syntax-aware cut-andpaste), can end up changing semantics if an easy mistake is made.
There are several different types of whitespace (spaces, tabs, weird unicode characters, carriage returns, line breaks, etc.), they aren't necessarily visually distinct, and languages and editors may treat them capriciously. This isn't an argument against well-designed whitespace semantics, but many people are against all forms of it simply because of the possibility of poor design.
People hate it because it violates common sense. Not a single one of the replies I have read here decided that it was ok to simply forgo periods and other punctuations. In fact the grammar has been very good. If the nonsense about indentation actually carrying the meaning were true we would all just forget about using punctuations entirely.
No one learned that newlines terminate a sentence in a horizontal language like English, instead we learned to infer when a sentence ended regardless of whether or not the punctuation was present or not.
The same is true for programming languages, especially for those of us who started out with a programming language that did use explicit block termination. You learn to infer where a block starts and stops over time, it does not mean that the spacing did that for you, the semantics of the language itself did.
Most literate people would have no problem understanding posts without punctuations. Having to rely on what is a representation of the absence of a character is not a good idea. Do any of you count from zero when you make your to-do list?
Alright, this is a very narrow perspective, but I haven't seen it mentioned elsewhere: keeping track of white space is a hassle if you are trying to autogenerate a script.
When I first encountered Python, I don't remember the details, but I had developed a Windows tool with a GUI that allowed novice users to configure several settings, and then press OK. The output of the tool was a script, which the user could copy to a Unix machine, and then execute it there to do something or other that was too complicated or tedious for them to do manually. Since nobody maintained the generated scripts, there was no reason they needed to look nice. So, keeping track of indentation seemed like an unnecessary burden from that perspective.
For most purposes, though, I find that Python is much easier than any other language.
Perhaps your C++ background (and thus who your peers are) is clouding your perception of this (ie selective sampling) but in my experience the reaction to Python's "white space is intent" meme is anywhere from ambivalent to they absolutely love it. The reason a lot of people love it is that it forces people to format their code.
I can't say I've ever met anyone who "hates" it because hating it is much like hating the idea of well-formatted code.
Edit: let me put this in some perspective.
In the Java world there are two main methods of packaging and deploying Web apps: Ant and Maven.
Ant is basically an XML-based Make facility that has tasks for the common things you do. It's a blank slate, which is powerful, but it also means you have to write a lot of common things yourself and every installation is free to do things slightly differently. All of this is well-intentioned but can make it hard to figure out someone's Ant scripts.
Maven is far more fully features. It has archetypes, which are basically project types. Depending on which archetype(s) you use, you won't have to write any tasks to start, stop, clean, build, etc but you will have a mandated directory structure, which is quite deep.
The advantage of that is if you've seen one Maven Web app you've seen them all. You know the commands. You know the structure. That's extremely useful.
But you have people who absolutely hate Maven and I think it comes down to this: they don't like giving up control, even when it's ultimately in their interest to do so. Also, you'll find a certain brand of person who thinks that their use case is a justifiable exception. You see this personality trait a lot. For example, I think an old Joel post mentioned a story where someone wanted to use "enter" to go from the username to password form fields even though the convention was that enter executed the default action (usually "OK") so they had to write a custom dialog class for Windows for this.
Basically some people just don't like being told what to do and others are completely obstinate in their belief that they're right even when all evidence points to the contrary.
This probably explains why some supposedly hate Python's white space: they don't like being told how to format their code. They like the freedom of C/C++.
Because change is scary. And maybe, among certain developers, there are some faint memories of languages with capricious rules about whitespacing that were hard to remember and arbitrary, meant more for compiler convenience than expressiveness.
Most likely, not giving whitespace-significance a fair shake before dismissing it is the real reason. Ask someone to fix a bug in a reasonably complex but well-written Python program, then ask them to go fix a bug in a 20 year old system in C, VB or Cobol and ask them which they prefer.
As for me, I have as much trouble with whitespace in Python or Boo as I have with parentheses in Lisp. Which is to say, none.
They will have to get used to it. Initially I had a problem my self trying to read some examples but after using language for some time I started liking it.
I believe it is a habit that people has to overcome.
Some have developed habits (for example: deeply nested loops, unnecessarily large functions) that they perceive would be hard to support in a whitespace sensitive language.
Some have developed an aesthetic dislike for hanging indents.
Because they are used to languages like C and JavaScript where they can align items as they please.
When it comes to Python, you have to indent code based on its context:
def Print():
ManyArgumentFunction(LongParam1,LongParam2,LongParam3,LongParam4...
In C, you could do:
void Print()
{
ManyArgumentFunction(LongParam1,
LongParam2,
LongParam3,...
}
The only complaints I (also of C++ background) have heard about Python are from people who don't like using the "Replace Tabs with Space" option in their IDE.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anybody have any tips for utilizing multiple languages at the same time? I use objective-c, c, perl, ruby, bash, ksh, rails, and other proprietary languages every day and am finding increasingly difficult to go back and forth between them on a daily basis. As a trivial example when switching between perl and ruby I constantly forget to use semi-colons in perl and find myself using $ for local vars in ruby. Things are even worse going from objective-c to c: I use function calls (instead meesage invocations) in objective-c. Does anybody have any tips on making working in several languages more productive?
For those of you suggesting IDEs as a solution, although I agree in principle with using an IDE to increase productivity. I tend to do all my coding in vi
A couple of tips:
Slow Down! We're used to working at a frenetic pace as developers. Switching between languages requires some more conscious thought and focus.
Use a good IDE - that shows your errors as you type them. This will be a gentle reminder that you are missing that semi-colon or leaving out a '$' (in many cases)
I have the same issue from time-to-time, but these two things help!
In my personal experience it's horrible to do this kind of task and technology switching, it totally messes up your brain, at the end of a day you're more a cabbage than a tired programmer. Don't do it. If your company forces you to do it start searching another job, if you are doing it for yourself, think once more if you really want this.
I use Java, Python, C, C++ and PHP(!) almost daily, and also trying to learn some more like Clojure and Perl. The best thing to do is to use a good, language-aware, syntax-highlighting, autoformatting editor/IDE that reveals trivial syntax mistakes right away. It definitely helps in switching the language mode of the brain.
I don't think that being able to code in multiple languages is much different from being able to move with a bus, car, bike or foot. The details differ, but the main idea is approximately the same.
Human memory is very context sensitive. Instead of going for one IDE/editor that covers all languages and helps you with error detection and syntax highlighting, you might want to consider going for one editor per language. I know this sounds like overkill and it probably is, so an alternative might be different themes for the editor that you switch when you switch languages. As a drastic example consider yourself using a red background when writing bash scripts and a blue background for your Python programming. With visual clues like that it should be much easier to distinguish what you are currently doing and after a little while this might work without any conscious effort.
Bullet point summary of things I've tried that have helped me:
Whenever reasonable & possible, take a break when you're switching languages
Use languages which are synergistic
Use consistent coding styles across languages
More detail from personal experience:
Switching like this can be very difficult. I've been in similar circumstances - earlier this year I was developing a web app at work with PHP, IDL (Interactive Data Language), JavaScript and some Bash and then doing some projects at home with Python. I found myself making lots of mistakes with syntax when switching from one to another.
The mistakes happened most commonly at work: E.g. when I'd been doing IDL for a while and then would switch to the PHP, I would forget to put dollar signs on the front of variables and semi-colons at the end of the lines. I didn't seem to have as many problems at home; I believe that was at least partly because it was always a few hours between getting home and starting my Python work, so the break probably helped my brain re-set from the languages I was using at work.
One thing that can help is finding languages with certain synergies: I've found that I can switch relatively easily between Python and Java ... yeah, I am still more likely to forget semi-colons at the end of my Java lines if I've been doing Python, but the two languages "sync" well in my brain, so switching isn't as difficult as going from Python to Perl, for example. I've also found it relatively easy to switch between Perl & PHP. YMMV, of course, and I expect different people will find synergies between different sets of languages.
Also, as much as you can, it may help to maintain a consistent coding style between languages. An example: for years I put an opening brace on the line after an if, for, etc. in Java, C, Perl, etc. However, after using Python as my main language for a few years, I've found that I no longer like that style, and have switched to putting opening braces at the end of lines. For me, this has helped create a more consistent appearance across languages, which I find helps ease the switching. Again YMMV.
While it gets better in time, the ability to do this kind of switching between a lot of languages on a daily basis is not for everyone. You should try "clustering" your work in such a way that you finish what you have to do in one language before taking a short break and moving on to the next. This would prevent you going back and forth and impose a schedule that will be easier to follow if you stick to it.
To issue a less abstract suggestion:
There are lots of plugins for Eclipse, and you can make it do most programming languages known to mankind (and probably a few not). However, many of those plugins are less than perfectly integrated. One is annoyingly full of advertisement for its creating company, another one is a memory hog...
For those who haven't heard about it: IntelliJ IDEA has gone (partially) Open Source, and in my experience it's very good at multi-language. I saw a demo a year ago where one of their developers built a program in 6 different languages. A toy, yes, but the IDE did a fine job on language-aware syntax highlighting, refactoring and so forth.
It won't do all your detail work for you, but it can help with some of it - and with good quality.
My recommendation is to give yourself a 15 minute break between switching languages. If you can't do that since you flip between client / server apps, then I would recommend dual screens. Separate client on left and server on right. As someone has already stated, the human mind is context sensitive. Therefore, the way you think and analyze things has a lot to do with it. Any way you can seperate the different contexes would help in making minor oops on a regular basis.
Frequently in my current job I will use different languages, the key for me to making this easier is to get the right tooling. There are some very good general purpose editors out there, which already have a long list of Syntax highlighters, checkers and even autocompletion. Most of which can be further customised. If you set these up to recognised the file extensions then a lot of the pain can be removed.
I generally use these in addition to IDEs, as most IDEs won't support ksh or other scripting, and are harder to customise so having another tool setup makes it easy to flick across. Ideally get one that runs both on Windows and the nixes
I've been using these for some time now
jedit
nedit
emacs
textpad
So, I got this idea that I'd try to prototype an experimental user interface using OpenGL and some physics. I know little about either of the topics, but am pretty experienced with programming languages such as C++, Java and C#. After some initial research, I decided on using Python (with Eclipse/PyDev) and Qt, both new to me, and now have four different topics to learn more or less simultaneously.
I've gotten quite far with both OpenGL and Python, but while Python and its ecosystem initially seemed perfect for the task, I've now discovered some serious drawbacks. Bad API documentation and lacking code completion (due to dynamic typing), having to import every module I use in every other module gets tedious when having one class per module, having to select the correct module to run the program, and having to wait 30 seconds for the program to start and obscure the IDE before being notified of many obvious typos and other mistakes. It gets really annoying really fast. Quite frankly, i don't get what all the fuzz is about. Lambda functions, list comprehensions etc. are nice and all, but there's certainly more important things.
So, unless anyone can resolve at least some of these annoyances, Python is out. C++ is out as well, for obvious reasons, and C# is out, mainly for lack of portability. This leaves Java and JOGL as an attractive option, but I'm also curious about Ruby and Groovy. I'd like your opinion on these and others though, to keep my from making the same mistake again.
The requirements are:
Keeping the hell out of my way.
Good code completion. Complete method signatures, including data types and parameter names.
Good OpenGL support.
Qt support is preferable.
Object Oriented
Suitable for RAD, prototyping
Cross-platform
Preferably Open-Source, but at least free.
It seems you aren't mainly having a problem with Python itself, but instead with the IDE.
"Bad API documentation"
To what API? Python itself, Qt or some other library you are using?
"lacking code completion (due to dynamic typing)"
As long as you are not doing anything magic, I find that PyDev is pretty darn good at figuring these things out. If it gets lost, you can always typehint by doing:
assert isinstance(myObj, MyClass)
Then, PyDev will provide you with code completion even if myObj comes from a dynamic context.
"having to import every module I use in every other module gets tedious when having one class per module"
Install PyDev Extensions, it has auto-import on the fly. Or collect all your imports in a separate module and do:
from mymodulewithallimports import *
"having to select the correct module to run the program"
In Eclipse, you can set up a default startup file, or just check "use last run configuration". Then you never have to select it again.
"before being notified of many obvious typos and other mistakes"
Install PyDev Extensions, it has more advanced syntax checking and will happily notify you about unused imports/variables, uninitialized variables etc.
Looking just at your list I'd recommend C++; especially because Code Completion is so important to you.
About Python: Although I have few experience with OpenGL programming with Python (used C++ for that), the Python community offers a number of interesting modules for OpenGL development: pyopengl, pyglew, pygpu; just to name a few.
BTW, your import issue can be resolved easily by importing the modules in the __init__.py files of the directory the modules are contained in and then just importing the "parent" module. This is not recommended but nonetheless possible.
I don't understand why nobody has heard of the D programing language?
THIS IS THE PERFECT SOLUTION!!!!
The only real alternative if you desire all those things is to use Java, but honestly you're being a bit picky about features. Is code completion really that important a trait? Everything else you've listed is traditionally very well regarded with Python, so I don't see the issue.
The text editor (not even an IDE) which I use lets you import API function definitions. Code completion is not a language feature, especially with OpenGL. Just type gl[Ctrl+I] and you'd get the options.
I tried using Java3D and java once. I realized Java3D is a typical Java API... lots of objects to do simple things, and because it's Java, that translates to a lot of code. I then moved to Jython in Eclipse to which cleaned up the code, leaving me with only the complexity of Java3D.
So in the end, I went in the opposite direction. One advantage this has over pure python is I can use Java with all of Eclipse's benefits like autocomplete and move it over to python when parts get unwieldy in Java.
It seems like Pydev can offer code completion for you in Eclipse.
I started off doing OpenGL programming with GL4Java, which got migrated to JOGL and you should definately give it (JOGL) a try. Java offers most of the features you require (plus Eclipse gives you the code completion) and especially for JOGL there are a lot of tutorials out there to get you started.
Consider Boo -- it has many of Python's advantages while adopting features from elsewhere as well, and its compile-time type inference (when variables are neither explicitly given a specific type or explicitly duck typed) allows the kind of autocompletion support you're asking about.
The Tao.OpenGL library exposes OpenGL to .NET apps (such as those Boo compiles), with explicit support for Mono.
(Personally, I'm mostly a Python developer when not doing C or Java, but couldn't care less about autocompletion... but hey, it's your question; also, the one-class-per-module convention seems like a ridiculous amount of pain you're putting yourself through needlessly).