Q:

Where should I place the constant?

The following bit of code requires a string.maketrans table that is only used inside a single function.
I have written three versions of the program that place the table at different locations in the code. The differing placement of the table results in quite varying performance in the creation of DNA instances and calls to the to_rna method.
So, which one of these variants is preferable? Or is there even a different, better solution?
Version 1:
from string import maketrans

DNA_RNA_TRANSLATION_TABLE = maketrans('GCTA', 'CGAU')

class DNA(object):
    """Represent a strand of DNA."""

    def __init__(self, dna_string):
        self.dna_string = dna_string

    def to_rna(self):
        """Return the RNA complement of the DNA strand."""
        return self.dna_string.translate(DNA_RNA_TRANSLATION_TABLE)

Version 2:
from string import maketrans

class DNA(object):
    """Represent a strand of DNA."""

    __rna_translation_table = maketrans('GCTA', 'CGAU')

    def __init__(self, dna_string):
        self.dna_string = dna_string

    def to_rna(self):
        """Return the RNA complement of the DNA strand."""
        return self.dna_string.translate(self.__rna_translation_table)

Version 3:
from string import maketrans

class DNA(object):
    """Represent a strand of DNA."""

    def __init__(self, dna_string):
        self.dna_string = dna_string

    def to_rna(self):
        """Return the RNA complement of the DNA strand."""
        translation_table = maketrans('GCTA', 'CGAU')
        return self.dna_string.translate(translation_table)

A:

I will answer your question in an unexpected way : the better solution is, as far as I can tell, much more straightforward than what you are doing.
Indeed, you don't need a class : your class has an __init__ and a single method to_rna, it might as well be a single function.
from string import maketrans

def dna_to_rna(dna_string):
    """Return the RNA complement of the DNA strand."""
    return dna_string.translate(maketrans('GCTA', 'CGAU'))

I think see this the neatest solution. Then if on only want to create the table only once for performance reason, you can put it a variable outside the function but it's probably not needed.

A:

Make the table local
See Michael Urman's comment on Josay's answer. For both optimisation and readability it is beneficial to make translation_table local to the to_rna object method. In your version 1 it is a global variable, in your version 2 it is a class attribute, and in your version 3 it is a local variable but it is created from scratch each time the function is called. Global variables take longer to look up than class attributes, which take longer to look up than local variables. In this particular case I would expect the speed up due to using a local variable to be small since considerably more time will be taken up using the table than initially looking up the variable that holds it (except for very short DNA strands...).
What will make a big difference is not having to recreate the table every time you call the method. For this reason I expect you are currently seeing approaches 1 and 2 running faster than approach 3. However, approach 3 keeps the definition of the table within the method, so it can easily be seen by anyone looking at that method, and doesn't need to be looked at by anyone not focussed on that method. This makes it more readable for everyone involved.
In this case it can be both readable and fast. You can keep the table definition within the method and ensure it is only created once (when the method is first defined) by making it an extra parameter with a default value, as Michael suggests.
Since the table is intended to be set up once and never changed, you may also want to call it TRANSLATION_TABLE in all upper case, which is the convention for constants in Python.
Example object method
def to_rna(self, TRANSLATION_TABLE=maketrans('GCTA', 'CGAU')):
    """Return the RNA complement of the DNA strand."""
    return self.dna_string.translate(TRANSLATION_TABLE)

In general this also makes it customisable (you can feed in a different table if you ever want to use the same method for a different type of translation). Even if the DNA to RNA translation is all you are likely to use this method for, this approach is still worthwhile for the combination of readability and speed. In this case the upper case table name makes it clear to other programmers that you do not expect the function to be customised in practice.
This approach will work equally well whether you take Josay's advice of not using a class, or end up adding extra features and needing a class after all.
Example function without a class
def dna_to_rna(dna_string, TRANSLATION_TABLE=maketrans('GCTA', 'CGAU')):
    """Return the RNA complement of the DNA strand."""
    return dna_string.translate(TRANSLATION_TABLE)

EDIT: The numbers: comparing timings
As Gareth Rees comments below, this explanation isn't reliable without measurement. So I ran the 4 versions and the timings were not quite what I expected...
Note that I'm using Python 3, so instead of from string import maketrans I'm just using str.maketrans. These timings should be measured again if you are using Python 2.
First I ran each of the 4 versions (1 to 3 from the question, plus my version), creating an object of the class and calling to_rna 100,000,000 times. I used a null string to create the object as it is only the lookup of the table constant I was interested in measuring. As expected, with the default local parameter giving minimum lookup overhead, version 4 is the fastest for calling once the object is created.

File        to_rna  cumulative  total running time
Version1    69.741  84.363      154.089
Version2    78.881  159.077     159.077
Version3    136.938 262.078     366.644
Version4    64.813  79.246      153.369

The table shows results for the following code added to each class definition file:
def lots_of_calls():
    test = DNA('')
    for i in range(100000000):
        unused = test.to_rna()

if __name__ == '__main__':
    lots_of_calls()

Timings were measured from the command line:
python -m cProfile version1.py

All times are in seconds.
Contrary to my expectations, the global constant in version 1 was significantly faster than the class attribute in version 2. I don't have a reason for this, which just goes to show how important it is to measure rather than guess...
Where I expected versions 1 and 2 to be the fastest was when creating a new object each time the translation is required, since the global constant and class attribute only need to be created once, and simply added by reference to each new object.  Both versions 3 and 4 require constructing the table from scratch for each new object (or so I had presumed), so I expected them to be considerably slower in this case.
I ran each of the 4 versions again, creating an object and calling to_rna, and repeating to create a new object 100,000,000 times, calling its to_rna method each time. To my surprise the time taken to run  __init__ was similar for all 4 versions, which meant that with its faster to_rna call, version 4 was still significantly faster than the others - the opposite of what I had expected.

File        init class  to_rna  cumulative to_rna   total running time
Version1    58.671      81.608  98.953              390.794
Version2    60.628      87.671  104.809             394.145
Version3    60.452      147.612 284.876             616.561
Version4    59.039      74.342  91.624              383.731

The table shows results for the following code:
def lots_of_calls():
    for i in range(100000000):
        test = DNA('')
        unused = test.to_rna()

if __name__ == '__main__':
    lots_of_calls()

So in both cases, version 1 is the fastest of the original 3 versions. However, version 4 is the fastest overall even when creating an object just for a single call.
I don't know the reason for this.  My best guess would be that the table for the default parameter is created once when the class is defined, and then just added as a reference in each new object that is created (rather than a new default table being created for each new object).
If this is the case, it doesn't cause any conflict between objects. I created an object, overrode its table by calling to_rna with a table instead of zero arguments, and then called it again with zero arguments. The default table was used, so any override applies only to that particular call and that particular object instance.

