Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm working on a large-ish project. I currently have some functional tests hacked together in shell scripts. They work, but I'd like to make them a little bit more complicated. I think it will be painful to do in bash, but easy in a full-blown scripting language. The target language of the project is not appropriate for implementing the tests.
I'm the only person who will be working on my branch for the foreseeable future, so it isn't a huge deal if my tests don't work for others. But I'd like to avoid committing code that's going to be useless to people working on this project in the future.
In terms of test harness "just working" for the largest number of current and future contributors to this project as possible, am I better off porting my shell scripts to Python or Perl?
I suspect Perl, since I know that the default version of Python installed (if any) varies widely across OSes, but I'm not sure if that's just because I'm less familiar with Perl.
Every modern Linux or Unixlike system comes with both installed; which you choose is a matter of taste. Just pick one.
I would say that whatever you choose, you should try to write easily-readable code in it, even if you're the only one who will be reading that code. Now, Pythonists will tell you that writing readable code is easier in Python, which may be true, but it's certainly doable in Perl as well.
This is more personal, but I always used python and will use it till something shows me it's better to use other. Its simple, very expansible, strong and fast and supported by a lot of users.
The version of python doesn't matter much since you can update it and most OSes have python 2.5 with expands the compatibility a lot. Perl is also included in Linux and Mac OS, though.
I think that Python will be good, but if you like perl and have always worked with it, just use perl and don't complicate your life.
Related
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 4 years ago.
Improve this question
I recently switched jobs and have the oportunity to create a clean programming working environment, cleaner and better than I used to have before. In my previous work I had some problems with running different versions of python next to eachother (or different versions of package) so I thought it would be a good idea to use Conda as a python install/package manager.
As an IDE I used to use idle because I find spyder a little cluttered, but I do however miss some functionality of a proper IDE and was thinking about switching to PyCharm for personal use and iPython (that is the same as python notebook isn't it?) for courses on python I will be giving.
What is the best way to do a very clean install? Do I install miniconda first and then python3.6 (and/or python2.7), pycharm, iPython? Or can I do this in a better way without getting to much clutter?
I would definitely suggest to go for miniconda or anaconda, as you already said yourself, since it allows you to keep different Python versions separated in different environments.
I cannot really give you advice on the editor to use, since I always use Spyder. It takes some time to get used to, but it very versatile and extremely useful when dealing with large and many Python scripts.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am planning on creating a software that will be used to analyse biological data, some of us biologists would not have much programming skills yet we do alot of repetitive tasks and are required to write more scripts or programs that we always use using.
i have decided to narrow it down to only one very important task, its a searching script, i.e to query a database of genes-(data), there is already a program that does that called ncbi-blast, usually one needs to be familiar with command line and also requires ubuntu or windows, but its a hassle if you have to analyse the huge quantities of results generated.
so i have want to package some of my python scripts into a software so that others can find it convenient to analyse their work
Open vs. Closed Source (Licensing)
i intend to make some of the functionalities freely available to the user in the software, although at a later stage, i intend to incorpaorate pipelines that would require an affordable license
testing
so with this one function, it makes testing alot simpler-i dont know yet, and i would not mind starting with linux-ubuntu and windows as the platforms.
I appreciate your advice on choosing just one language, and i will go with python, how ever i would like tyhe software to atleast support other free programs created in other languages like R, as in plugins that a client installs when they need them.
I hope this shades more light to my already complex situation
Thank you
Sounds like you're at the beginning of an adventure and some new learning curves. I will applaud your willingness to create. Here are some things to consider as you get started on your journey.
fyi: "software" is typically a single word, no space.
Based on the context of "a soft ware" it seems like you mean "application".
I mention "software" and "application" not to give you a hard time about it, but because I think 1) it will help you in future searches when you look for ways to get something done (e.g. you'll get more useful hits on "python application installer" than "python soft ware installer", and 2) you can more clearly explain to people what you are attempting.
So. Your application(s) will need a user interface for your collection of scripts. Do you want a graphical user interface (GUI)? Or a command line interface (CLI)?
GUI: more complex than CLI:
For a GUI it will be more complex to get something that runs on both Windows & Linux.
So far as I know there isn't a trivial way to create a single GUI that runs on both Windows & Linux without adding another tool. Maybe python has easy GUI user-interface stuff in it and you could use that.
For perl I will point you here: "Perl GUI programming on Windows" Perl GUI programming on Windows
This lists some Perl approaches to consider, you will have to research them and see which ones are also able to run on Linux. Be careful about including additional libraries you'll need to package (or document how to install) with you application.
CLI: more simple than a GUI:
Since they are just scripts today, I would suggest starting with a CLI which probably means cleaning up your argument handling ( #ARGV in Perl, I can't comment on Python).
Read through your code and find literals that you change when you run a script for something new, those things will become your arguments. And if it starts to seem like you are creating too many arguments maybe you want to look into a configuration file (properties file of some kind).
It will be easier for you to get started with a CLI and you can always come back and add a GUI option in a future release. I find that designing a well thought out CLI makes it easier to focus on what is important for a GUI so it should help your eventual GUI be even better.
Packaging
Packaging your application is going to be a challenge.
Do your scripts need any libraries that aren't part of default with python & perl installs? If so you need to work out a way to supply those (e.g. include them with your distribution or include documentation that your users can follow to download and install the libs).
I can't comment on pyinstaller.
For Perl I will point you to this question on distributing a Perl Application : Distributing a Perl Application
User Skill
How much skill do you expect your users to have?
Will they be ok with installing a python and perl interpreters if necessary? Not every user has that technical skill.
Do you want to make sure your scripts verify the minimum versions of python & perl they need?
Documentation
See User Skill, above. You will need to make documentation available.
This will be driven by who is going to use your scripts. What is your target user like? Can you write a "5 line" summary that would make me want to download them and try them? That will be a helpful exercise to help you focus on how you want to present the scripts.
Open vs. Closed Source (Licensing)
This also ties into licensing. Are you aiming for a commercial product? Giving the world another gift of open source? Those are both fine things to do, but you'll want to choose a suitable license for your application. You also have some work to do if you want to avoid distributing your script's source code (I'm not suggesting you pursue one approach or the other, just that you make the decision before you put it on the internet at large).
Testing
Testing your application is going to be a challenge.
If you don't have automated tests for your scripts you will go crazy trying to verify it runs everywhere you want it to run.
Do you have unit tests & test suites for your scripts so you can verify they run correctly on different versions of Windows and various Linux distributions?
If your scripts are pretty simple maybe it doesn't matter if they're running on 32 bit vs. 64 bit operating systems.
Maybe it doesn't matter if they run on Windows 10, Windows 8.x, Windows 7.x, maybe various versions of Windows Server (2012, 2008, ...).
Maybe it doesn't matter if they run on RedHat, Suse, Ubuntu, Mint, ...
You probably want some sanity checks to verify that your install program worked correctly and the environment is suitable.
Without knowing what your scripts do it is kind of hard to say how much testing they benefit from.
Free Advice: choose just one scripting language and run with that
I will end with some completely free advice (worth what you're paying for it :-) )
Think really hard about just choosing one scripting language and writing everything in that.
You are going to have a LOT of additional complexity from supporting two scripting systems, if I were doing something like you describe I would Seriously Consider consolidating into a single language and just to Python or just do Perl. The time and energy it takes you to rewrite your Python scripts as Perl (or the other way around) may very well be easier compared to learning about creating installation guides and packaging your application using two different languages.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
What's the ideal Python version for a beginner to start learning Python? I need to recommend some newbies a programming language to learn and I chose Python. I'm still not sure which version.
It depends what you're going to do with it.
Unicode handling has vastly improved in Python 3. So if you intend to use this for building web pages or some such, Python 3 might be the obvious choice.
On the other hand, many libraries and frameworks still only support Python 2. For example, the numerical processing library numpy, and the web framework Django both only work on Python 2. So if you intend to use any of those, stick with Python 2.
Either way, the differences aren't huge to begin with. I'd say Python 3 is a little easier to pick up (due to its string handling), but that is a good reason to learn Python 2 first. That way, if you run into a piece of Python 2 code (and you will), you'll know what is going on.
Adoption of Python3 has been held up by a few critical 3rd party packages. numpy is a good example of a package that has just barely started working on Python3. Quite a few other packages depend on numpy, so they will hopefully be supporting Python3 very shortly too.
Most of the time it's possible to write code that is compatible with 2.6/2.7/3.1 by using __future__ imports. So learning one does not mean you are not learning the other.
My vote is for 3.1
My reasoning is simple and selfish. The more new python programmers that only use 3.1 there are, the more likely it is that one of them is going to decide that they need some library from 2.6 and port it to 3.1 (learning 2.6 in the process I might add).
After this happens, I can start using 3.1: it looks really cool.
I would suggest Python 2.6; I know it's old, but it's not only the current standard, and there is way more documentation and libraries available for it.
I'll throw my experience into the works:
Right now you should be using 2.6. Switch to 2.7 when 2.7.1 comes out. Switch to 3.1/2 when all the libraries you want are fully supported and stable there.
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 5 years ago.
Improve this question
I write tons of python scripts, and I find myself reusing lots code that I've written for other projects. My solution has been to make sure the code is separated into logical modules/packages (this one's a given). I then make them setuptools-aware and publish them on PyPI. This allows my other scripts to always have the most up-to-date code, I get a warm fuzzy feeling because I'm not repeating myself, and my development, in general, is made less complicated. I also feel good that there MAY be someone out there that finds my code handy for something they're working on, but it's mainly for selfish reasons :)
To all the pythonistas, how do you handle this? Do you use PyPI or setuptools (easy_install)? or something else?
I have been doing the same thing. Extract common functionality, pretty the code up with extra documentation and unit tests/ doctests, create an easy_install setup.py, and then release on PyPi. Recently, I created a single Google Code site where I manage the source and keep the wiki up to date.
What kind of modules are we talking about here? If you're planning on distributing your projects to other python developers, setuptools is great. But it's usually not a very good way to distribute apps to end users. Your best bet in the latter case is to tailor your packaging to the platforms you're distributing it for. Sure, it's a pain, but it makes life for end users far easier.
For example, in my Debian system, I usually don't use easy_install because it is a little bit more difficult to get eggs to work well with the package manager. In OS X and windows, you'd probably want to package everything up using py2app and py2exe respectively. This makes life for the end user better. After all, they shouldn't know or care what language your scripts are written in. They just need them to install.
I store it all offline in a logical directory structure, with commonly used modules grouped as utilities. This means it's easier to control which versions I publish, and manage. I also automate the build process to interpret the logical directory structure.
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 2 years ago.
Improve this question
I've seen a number of postgresql modules for python like pygresql, pypgsql, psyco. Most of them are Python DB API 2.0 compliant, some are not being actively developed anymore.
Which module do you recommend? Why?
psycopg2 seems to be the most popular. I've never had any trouble with it. There's actually a pure Python interface for PostgreSQL too, called bpgsql. I wouldn't recommend it over psycopg2, but it's recently become capable enough to support Django and is useful if you can't compile C modules.
I suggest Psycopg over Psycopg2 since the first one seems a bit more sable. At least in my experience. I have an application running 24/7 and sometimes I was getting random memory crashes (double free or corruption errors) from Psycopg2. Nothing I could have debug fast or easily since it's not a Python error but a C error. I just switched over to Pyscopg and I did not get any crashes after that.
Also, as said in an other post, bpgsql seems a very good alternative. It's stable and easy to use since you don't need to compile it. The only bad side is that library is not threadsafe.
Pygresql seems nice, there's a more direct way to query the database with this library. But I don't know how stable this one is though.
I've used pg8000 without any problems in the past 3 years. It's uptodate and available on pypi and works on both python2 and python3. You can use "pip install pg8000" to quickly get it (don't forget to use --proxy=yourproxy:yourport if you're behind a firewall).
If you're worried about thread safety, it also provides a score for thread safety (see: http://pybrary.net/pg8000/dbapi.html and https://www.python.org/dev/peps/pep-0249/ for definitions of the different levels of thread safety) (although I have no yet used threads with psql).
In my experience, psycopg2 is the most used library for this. Like you said, it's DB API 2.0 compliant, wich gives a solid interface to work with.
For those who find the standard API to be a little too verbose and hard to work with, I made a small library that might help:
https://github.com/hugollm/rebel
Psycopg1 is known for better performance in heavilyy threaded environments (like web applications) than Psycopg2, although not maintained. Both are well written and rock solid, I'd choose one of these two depending on use case.
I uses only psycopg2 and had no problems with that.