|
|
Mozy Online Backup: 2GB Free. Automatic. Secure.
Subject: Re: Numeric/numpy - msg#00075
List: python.bio.devel
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?
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
|
|