osdir.com
mailing list archive
Mozy Online Backup: 2GB Free. Automatic. Secure.

Subject: Re: Numeric/numpy - msg#00075

List: python.bio.devel

Date: Prev Next Index Thread: Prev Next Index
Michiel wrote:
>Peter wrote:
>> I was assuming dual support for both numpy or Numeric for the next
>> release based on code like this:
>>
>> try:
>> from Numeric import x, y, z
>> except ImportError:
>> from numpy.oldnumeric import x, y, z
>
> This is the easy part. Keep in mind though that the "from numpy.oldnumeric
> import x, y, z" approach is only a temporary solution; at some point, the
> oldnumeric wrapper will disappear from numpy.

Yes, if/when the oldnumeric wrapper goes away we'll have more work to
do. Something to worry about later.

>> where I assumed the C code would have been decided at
>> compile time.
>
> This is the complicated part; it's not just replacing one #include with
> another. We'd have to use a bunch of #ifdefs to separate the old code from
> the new code.
>
> Anyway I was planning to go through the Numerical Python - dependent code to
> see if any other
> changes are needed. If anybody wants to be able to use the old Numerical
> Python, please let
> yourself be heard; otherwise I suggest we go directly to NumPy.
>
> --Michiel

That suits me - how about we post something like this on the main
discussion list then?:

Dear all,

As you probably are well aware, Biopython releases to date have used
the now obsolete Numeric python library. This is no longer being
maintained and has been superseded by the numpy library. See
http://www.scipy.org/History_of_SciPy for more about details on the
history of numerical python. Biopython 1.48 should be the last
Numeric only release of Biopython - we have already started moving to
numpy in CVS.

Supporting both Numeric and numpy ought to be fairly straight forward
for the pure python modules in Biopython. However, we also have C code
which must interact with Numeric/numpy, and trying to support both
would be harder.

Would anyone be inconvenienced if the next release of Biopython
supported numpy ONLY (dropping support for Numeric)? If so please
speak up now - either here or on the development mailing list.
Otherwise, a simple switch from Numeric to numpy will probably be the
most straightforward migration plan.

Thank you,

...


Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

Re: Numeric/numpy - Bio/Affy/CelFile.py

> try: > from Numeric import x, y, z > except ImportError: > from numpy.oldnumeric import x, y, z This is the easy part. Keep in mind though that the "from numpy.oldnumeric import x, y, z" approach is only a temporary solution; at some point, the oldnumeric wrapper will disappear from numpy. > where I assumed the C code would have been decided at > compile time. This is the complicated part; it's not just replacing one #include with another. We'd have to use a bunch of #ifdefs to separate the old code from the new code. Anyway I was planning to go through the Numerical Python - dependent code to see if any other changes are needed. If anybody wants to be able to use the old Numerical Python, please let yourself be heard; otherwise I suggest we go directly to NumPy. --Michiel --- On Fri, 9/19/08, Peter Cock <p.j.a.cock@xxxxxxxxxxxxxx> wrote: > From: Peter Cock <p.j.a.cock@xxxxxxxxxxxxxx> > Subject: Re: [Biopython-dev] Numeric/numpy - Bio/Affy/CelFile.py > To: mjldehoon@xxxxxxxxx > Cc: "BioPython-Dev Mailing List" <biopython-dev@xxxxxxxxxxxxxxxxxx> > Date: Friday, September 19, 2008, 9:57 AM > On Fri, Sep 19, 2008 at 2:05 PM, Michiel de Hoon > <mjldehoon@xxxxxxxxx> wrote: > > Actually, I was under the impression that the latest > consensus was to go to NumPy directly. It's quite > complicated to support both NumPy and Numerical Python, at > least at the C level. > > I was assuming dual support for both numpy or Numeric for > the next > release based on code like this: > > try: > from Numeric import x, y, z > except ImportError: > from numpy.oldnumeric import x, y, z > > where I assumed the C code would have been decided at > compile time. > > If a simple switch from Numeric to numpy is what you and > Brad had in > mind, that's OK with me but in the python code we > should just use > simple imports from numpy only. > > Peter

Next Message by Date: click to view message preview

[Bug 2591] New: GenBank files misparsed for long organism names

http://bugzilla.open-bio.org/show_bug.cgi?id=2591 Summary: GenBank files misparsed for long organism names Product: Biopython Version: 1.47 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Main Distribution AssignedTo: biopython-dev@xxxxxxxxxxxxx ReportedBy: joelb@xxxxxxxx I've noticed a problem with BioPython 1.47 mis-parsing the organism and lineage in GenBank files from certain bacteria. All of the problem organisms have names longer than 61 characters, and a line wrap is introduced into the SOURCE and ORGANISM records, which causes the mis-parsing. My reading of the GenBank file docs says that lines should be of variable length rather than being split, so it appears this bug is GenBank's problem rather than BioPython's. I have sent e-mail to info@xxxxxxxxxxxxxxxx about the issue just now. GenBank doesn't seem to have a bug tracker, though, so I'm writing the issue here to document it for other people. The issue exists for a number of organisms (more than 6, though I haven't done the exact count). One example may be found at ftp://ftp.ncbi.nlm.nih.gov/genomes/Bacteria/Salmonella_enterica_serovar_Paratyphi_A_AKU_12601/NC_011147.gbk or http://tinyurl.com/47yg5g When parsing this file, the taxonomy list returned begins with ["AKU_12601 Bacteria","Proteobacteria"... Some of the other examples have made it onto web sites which have included the mis-parsed data, e.g. Superfam http://supfam.mrc-lmb.cam.ac.uk/SUPERFAMILY/cgi-bin/gen_list.cgi?genome=x6 which shows the error for Salmonella enterica subsp. enterica serovar Choleraesuis str. SC-B67. I'll append the response from GenBank to this bug if and when I get one. If I don't get one, then I'll try to come up with a workaround. -- Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Previous Message by Thread: click to view message preview

[Bug 2251] [PATCH] NumPy support for BioPython

http://bugzilla.open-bio.org/show_bug.cgi?id=2251 ------- Comment #15 from biopython-bugzilla@xxxxxxxxxxxxxxxxxxxxx 2008-09-18 18:52 EST ------- For those not following the dev-mailing list, Numeric to numpy changes have begun to be checked into CVS. Brad said he had used Ed's patch for a lot of this - so thanks Ed! -- Configure bugmail: http://bugzilla.open-bio.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

Next Message by Thread: click to view message preview

Re: Numeric/numpy

Peter; Michiel covered most everything here. My initial check-ins are basically the try/except you describe and it looks like Michiel has gone further and worked on real NumPy transitions. My opinion is to post that message to the main list and move forward with converting to MumPy exclusively as people are able to tackle the task for different module. Once something has been converted in a real way, and not just using oldnumeric imports, then the try/except can go away. I suspect not too many people will still be stuck on Numerical, and should be excited to get up to date with that library. Brad > Michiel wrote: > >Peter wrote: > >> I was assuming dual support for both numpy or Numeric for the next > >> release based on code like this: > >> > >> try: > >> from Numeric import x, y, z > >> except ImportError: > >> from numpy.oldnumeric import x, y, z > > > > This is the easy part. Keep in mind though that the "from numpy.oldnumeric > > import x, y, z" approach is only a temporary solution; at some point, the > > oldnumeric wrapper will disappear from numpy. > > Yes, if/when the oldnumeric wrapper goes away we'll have more work to > do. Something to worry about later. > > >> where I assumed the C code would have been decided at > >> compile time. > > > > This is the complicated part; it's not just replacing one #include with > > another. We'd have to use a bunch of #ifdefs to separate the old code from > > the new code. > > > > Anyway I was planning to go through the Numerical Python - dependent code > > to see if any other > > changes are needed. If anybody wants to be able to use the old Numerical > > Python, please let > > yourself be heard; otherwise I suggest we go directly to NumPy. > > > > --Michiel > > That suits me - how about we post something like this on the main > discussion list then?: > > Dear all, > > As you probably are well aware, Biopython releases to date have used > the now obsolete Numeric python library. This is no longer being > maintained and has been superseded by the numpy library. See > http://www.scipy.org/History_of_SciPy for more about details on the > history of numerical python. Biopython 1.48 should be the last > Numeric only release of Biopython - we have already started moving to > numpy in CVS. > > Supporting both Numeric and numpy ought to be fairly straight forward > for the pure python modules in Biopython. However, we also have C code > which must interact with Numeric/numpy, and trying to support both > would be harder. > > Would anyone be inconvenienced if the next release of Biopython > supported numpy ONLY (dropping support for Numeric)? If so please > speak up now - either here or on the development mailing list. > Otherwise, a simple switch from Numeric to numpy will probably be the > most straightforward migration plan. > > Thank you, > > ... > _______________________________________________ > Biopython-dev mailing list > Biopython-dev@xxxxxxxxxxxxxxxxxx > http://lists.open-bio.org/mailman/listinfo/biopython-dev -- Brad Chapman Codon Devices http://www.codondevices.com
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by