We Keep Coding

Python: How to deprecate a function alias

As the title states, what I want to achieve is the following:
I have a python code base for which I want to rename all the functions from camelCasing to underscore_naming. In order to maintain backwards compatibility, I have renamed all the functions, but have created function aliases for all the old names. So far, so good.
Now what I want to do is add deprecation warnings to the function aliases, preferably in a fashion like this:
def do_something():
...
#deprecated(deprecated_in='2.0',
details='All functions have been adapted to fit the PEP8 standard. Please use "do_something" instead')
doSomething = do_something
So that if somebody uses the old API call, they will get a deprecation warning. I've taken a look at deprecation and Deprecated, but neither of them seem to work on aliases.
I realise that I can create a function definition for every deprecated name and decorate that, but that loses the elegance of the function alias, and makes for more mucky code. Does anybody have a good suggestion to achieve what I want?

I actually ended up going for a different solution, similar to what's suggested in Method and property aliases with custom docstring in Python.
I modified my code to
#alias('doSomething', deprecated=True)
def do_something():
...
and added a deprecation warning to the alias decorator.

Should 3.4 enums use UPPER_CASE_WITH_UNDERSCORES?

As the documentation says, an enumeration is a set of symbolic names (members) bound to unique, constant values. The PEP8 says that constants are usually named as UPPER_CASE, should I use this notation in Python 3.4 enums? If yes, why the examples in the docs are using lower_case?

Update
The BDFL (Benevolent Dictator For Life) has spoken, and the Enum documentation has changed to reflect all upper-case member names.
The examples in the [previous] docs are lower-case primarily because one of the preexisting modules that Enum was based on used lower-case (or at least its author did ;).
My usage of enum has usually been something along the lines of:
class SomeEnum(Enum):
... = 1
... = 2
... = 3
globals().update(SomeEnum.__members__)
which effectively puts all the members in the module namespace.
So I would say whichever style feels more comfortable to you -- but pick a style and be consistent.

I think they're not UPPER_CASE because, well, it just looks weird when it is. Since you can only access the enumerations through the class (e.g. my_enum.VALUE) it looks weird if the members are capitalized. In C the members of the enumeration go into the module namespace, so it doesn't look weird (to me) when the members are capitalized, in usage:
typedef enum {OFF, ON} lightswitch;
lightswitch bathroomLight = ON;
But in Python you access them through the enumeration class that you create, and it looks weird to go from ClassStyle names to ALL_CAPS.
class Lightswitch(Enum):
OFF = 0
ON = 1
# isn't that weird?
my_light = Lightswitch.OFF
Bottom line, I think it's just aesthetic. I've been wrong before, though, and I realize that this is just my opinion.

When in doubt about style, I usually defer to the style used in standard library code and examples from the official documentation. It keeps me from wasting time on arbitrary decisions.
So in this case, I recommend lower case, like variable names.

Pylint best practices

Pylint looks like a good tool for running analysis of Python code.
However, our main objective is to catch any potential bugs and not coding conventions. Enabling all Pylint checks seems to generate a lot of noise. What is the set of Pylint features you use and is effective?

You can block any warnings/errors you don't like, via:
pylint --disable=error1,error2
I've blocked the following (description from http://www.logilab.org/card/pylintfeatures):
W0511: Used when a warning note as FIXME or XXX is detected
W0142: Used * or * magic*. Used when a function or method is called using *args or **kwargs to dispatch arguments. This doesn't improve readability and should be used with care.
W0141: Used builtin function %r. Used when a black listed builtin function is used (see the bad-function option). Usual black listed functions are the ones like map, or filter, where Python offers now some cleaner alternative like list comprehension.
R0912: Too many branches (%s/%s). Used when a function or method has too many branches, making it hard to follow.
R0913: Too many arguments (%s/%s). Used when a function or method takes too many arguments.
R0914: Too many local variables (%s/%s). Used when a function or method has too many local variables.
R0903: Too few public methods (%s/%s). Used when class has too few public methods, so be sure it's really worth it.
W0212: Access to a protected member %s of a client class. Used when a protected member (i.e. class member with a name beginning with an underscore) is access outside the class or a descendant of the class where it's defined.
W0312: Found indentation with %ss instead of %ss. Used when there are some mixed tabs and spaces in a module.
C0111: Missing docstring. Used when a module, function, class or method has no docstring. Some special methods like __init__ don't necessarily require a docstring.
C0103: Invalid name "%s" (should match %s). Used when the name doesn't match the regular expression associated to its type (constant, variable, class...).

To persistently disable warnings and conventions:
Create a ~/.pylintrc file by running pylint --generate-rcfile > ~/.pylintrc
Edit ~/.pylintrc
Uncomment disable= and change that line to disable=W,C

Pyflakes should serve your purpose well.

-E will only flag what Pylint thinks is an error (i.e., no warnings, no conventions, etc.)

Using grep like:
pylint my_file.py | grep -v "^C"
Edit :
As mentionned in the question, to remove the conventions advices from pylint output, you remove the lines that start with an uppercase C.
From the doc of pylint, the output consists in lines that fit the format
MESSAGE_TYPE: LINE_NUM:[OBJECT:] MESSAGE
and the message type can be:
[R]efactor for a “good practice” metric violation
[C]onvention for coding standard violation
[W]arning for stylistic problems, or minor programming issues
[E]rror for important programming issues (i.e. most probably bug)
[F]atal for errors which prevented further processing
Only the first letter is displayed, so you can play with grep to select/remove the level of message type you want.
I didn't use Pylint recently, but I would probably use a parameter inside Pylint to do so.

What to use for Python string.find?

The documentation for Python 2.7 lists string.find as a deprecated function but does not (unlike atoi and atol) provide an alternative.
I'm coding in 2.7 at the moment so I'm happy to use it but I would like to know:
what is it going to be replaced with?
is that usable in 2.7 (if so, I'll use it now so as to avoid recoding later)?

Almost the entire string module has been moved to the str type as method functions.
Why are you using the string module, when almost everything you need is already part of the string type?
http://docs.python.org/library/stdtypes.html#str.find
The string type -- and it's methods -- is not deprecated. Indeed, it will me morphed to include Unicode in Python 3.

A lot of methods in string have been replaced by the str class. Here is str.find.

Ruby equivalent to Python's help()?

When working in interactive Python, I tend to rely on the built-in help() function to tell me what something expects and/or returns, and print out any documentation that might help me. Is there a Ruby equivalent to this function?
I'm looking for something I could use in irb. For example, in interactive Python I could type:
>>> help(1)
which would then print
Help on int object:
class int(object) | int(x[, base])
-> integer | |
Convert a string or number to an integer, if possible. A ...

It's now late 2014 and here's the two ways to get the Python help() *similarity, as long as you have the Ruby Docs installed:
From inside irb, You can call the help method with a string describing what you're looking for.
Example 1: help 'Array' for the Array class
Example 2: help 'Array#each' for the Array class each method.
From the command line, outside of irb, you can use the ri program:
Example 1: ri 'Array' for the Array class
Example 2: ri 'Array#each' for the Array class each method.
* Not quite as good as Python's, but still better than nothing

It's definitely a poor cousin to iPython's help, and one of the main features I miss after moving to Ruby, but you can also use ri from within irb. I'd recommend the wirble gem as an easy way to set this up.

Try using ri from the command line.
It takes a class name, method, or module as an argument, and gives you appropriate documentation. Many popular gems come with this form of documentation, as well, so it should typically work even beyond the scope of core Ruby modules.

There's supposed to be irb_help. But like mentioned in that post, it's broken in my ruby install as well.

For quick shell access to ruby documentation, just type ri followed by the method you're wanting to learn more about (from your shell).
For example:
ri puts
This must be fired up in your shell, not your irb (interactive ruby environment)
If you're in your irb environment, then another way, is to simply type help followed by the method you want to learn more about as follows:
help puts
However, this assumes that you have configured your Ruby environment correctly for that (help) to work properly within irb. I usually just have another shell open, and just use the ri directly for quick access when I'm in doubt about a certain method or arguments to a method.