Re: [pypy-dev] Global executable naming policy
Gentoo's CPython package gives python, python2, python3, python2.x, and python3.x. Gentoo's PyPy package allows parallel PyPy versions by appending a version number. The names I listed would bring PyPy up to the level of CPython. -Aaron DeVore > On a related note, can we see situations where people only want to > specify the language level, only want to specify the pypy version, or > only want to specify the backend? Of course it is easy to specify /a > specific installation/, and I suppose people want to be able to > specify 'the default pypy' too. There is also the question of how > much of this should be provided, and how much should be left to > package maintainers or custom configuration; for Windows, 'pypy' and > 'pypy3' are probably sufficient. > > -- > William Leslie ___ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
[pypy-dev] Global executable naming policy
There currently isn't an official naming scheme for the PyPy executable for system installations. Of the 3 setups I've seen, the official build uses pypy, Arch Linux uses pypy, and Gentoo Linux uses pypy-c. I brought up the similar issue of how to differentiate between Python 2 and 3 a while ago, but the conversation sputtered out. One possible naming scheme includes these executables using Python 2.7, Python 3.3, and PyPy 1.9 as an example: pypy pypy-1.9 pypy2 pypy2-1.9 pypy3 pypy3-1.9 pypy2.7 pypy2.7-1.9 pypy3.3 pypy3.3-1.9 -Aaron DeVore ___ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
Re: [pypy-dev] Policy on Python 3 and Python 2 executable names
On Wed, Aug 31, 2011 at 12:13 AM, Armin Rigo wrote: > > I suppose that we need to *have* a pypy3 first, before any > conversation like that really makes sense. Last March this wasn't > even being considered. Now it is maybe in some very draftish early > planning stage. The idea is to be proactive in policy making instead of allowing the problem to be acute like with CPython. -Aaron DeVore ___ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
[pypy-dev] Policy on Python 3 and Python 2 executable names
>From what I can tell, PyPy doesn't have a policy on how package maintainers should differentiate between Python 2 and Python 3 executables. I brought up adding "pypy2" on #pypy in March, but the conversation quickly died. CPython ran into the no-policy problem when Arch Linux decided to switch /usr/bin/python to be Python 3. There wasn't a naming policy for /usr/bin/python at that point. The PEP that represents the relevant python-dev mailing list thread is PEP 394[1]. PEP 394 isn't finished yet, but should be soon. Possible solution [who uses it for CPython]: 1) pypy arbitrary, pypy2 for Python 2, pypy3 for Python 3 [PEP 394, Gentoo] 2) pypy for Python 2, pypy3 for Python 3, no pypy2 [Debian family] 3) pypy for Python 2, pypy2 for Python 2, pypy3 for Python 3 [Red Hat family] 4) pypy for Python 3, pypy2 for Python 2, pypy3 for Python 3 [Arch Linux] I prefer #1 because it sticks with PEP 394 and is future-proof. #2 and #3 take away future flexibility. #4 is a horrible, horrible idea at present. -Aaron DeVore [1] http://www.python.org/dev/peps/pep-0394/ ___ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
Re: [pypy-dev] pypy1.6 slow on string-heavy ops
Python 2.4 introduced a change that helps improve performance of
string concatenation, according to its release notes. I don't know
anything beyond that.
-Aaron DeVore
On Thu, Aug 18, 2011 at 3:31 PM, Justin Peel wrote:
> Yes, Vincent's way is the better way to go. To elaborate more on the
> problem, string appending is O(N^2) while appending to a list and then
> joining is an O(N) operation. Why CPython is faster than Pypy at doing
> the less efficient way is something that I'm not fully sure about, but
> I believe that it might have to do with the differing memory
> management strategies.
>
> On Thu, Aug 18, 2011 at 4:24 PM, Vincent Legoll
> wrote:
>> Hello,
>>
>> Try this:
>>
>> import sys
>>
>> fasta_file = sys.argv[1] # should be *.fa
>> print 'loading dna from', fasta_file
>> chroms = {}
>> dna = []
>> for l in open(fasta_file):
>> if l.startswith('>'): # new chromosome
>> if len(dna) > 0:
>> chroms[chrom] = ''.join(dna)
>> chrom = l.strip().replace('>', '')
>> dna = []
>> else:
>> dna.append(l.rstrip())
>> if len(dna) > 0:
>> chroms[chrom] = ''.join(dna)
>>
>> --
>> Vincent Legoll
>> ___
>> pypy-dev mailing list
>> pypy-dev@python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
>>
> ___
> pypy-dev mailing list
> pypy-dev@python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
