[Bioc-devel] as.list of a GRanges

Bernat Gel bgel at igtp.cat
Mon Feb 19 11:10:00 CET 2018


Hi Hervé,

I completely agree with the goal of having the semantics of list-like 
operations standardised and documented to avoid surprises, and if to do 
so, the current use of as.list must be changed I'm pefectly ok with 
that. I had not seen the strange behaviour with IRanges, so I was not 
aware of the problem.

In any case, thanks for fixing (and simplifying) karyoploteR. In 
retrospective I don't know why I didn't use simple vectorization! So, thanks


Bernat

*Bernat Gel Moreno*
Bioinformatician

Hereditary Cancer Program
Program of Predictive and Personalized Medicine of Cancer (PMPPC)
Germans Trias i Pujol Research Institute (IGTP)

Campus Can Ruti
Carretera de Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona, Spain

Tel: (+34) 93 554 3068
Fax: (+34) 93 497 8654
08916 Badalona, Barcelona, Spain
bgel at igtp.cat <mailto:bgel at igtp.cat>
www.germanstrias.org <http://www.germanstrias.org/>

<http://www.germanstrias.org/>







El 02/17/2018 a las 04:19 AM, Hervé Pagès escribió:
> Hi Bernat,
>
> On 02/15/2018 11:57 PM, Bernat Gel wrote:
>> Hi Hervé and others,
>>
>> Thanks for the responses.
>>
>> I woudn't call as.list() of a GRanges an "obscure behaviour" but more 
>> a "works as expected, even if not clearly documented" behaviour.
>
> Most users/developers will probably agree that as.list() worked
> as expected on a GRanges object. But then they'll be surprised
> and confused when they use it on an IRanges object and discover
> that it does something completely different. The current effort
> is to bring more consistency between GRanges and IRanges objects
> and to have their list-like semantics aligned and documented so
> there will be no more such surprise.
>
>>
>> In any case I can change the code to as(gr, "GRangesList") as suggested.
>
> I went ahead and fixed karyoploteR. This is karyoploteR 1.5.2. Make
> sure to resync your GitHub repo by following the instructions here:
>
>
> https://bioconductor.org/developers/how-to/git/sync-existing-repositories/ 
>
>
> Note that the loop on the GRanges object (via the call to Map())
> was not needed and could be replaced with a solution that uses
> proper vectorization.
>
> Best,
> H.
>
>>
>> Thanks again for the responses and discussion :)
>>
>> Bernat
>>
>>
>> *Bernat Gel Moreno*
>> Bioinformatician
>>
>> Hereditary Cancer Program
>> Program of Predictive and Personalized Medicine of Cancer (PMPPC)
>> Germans Trias i Pujol Research Institute (IGTP)
>>
>> Campus Can Ruti
>> Carretera de Can Ruti, Camí de les Escoles s/n
>> 08916 Badalona, Barcelona, Spain
>>
>> Tel: (+34) 93 554 3068
>> Fax: (+34) 93 497 8654
>> 08916 Badalona, Barcelona, Spain
>> bgel at igtp.cat <mailto:bgel at igtp.cat>
>> www.germanstrias.org 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org_&d=DwMDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Wwl42dL5uGJa8PR0aAcNnIN0t-uut5R2xLKBhl0ynV8&s=z45_PX78N6zLu1Bcn-mYQcyRortvXjNyQcWASriwsr0&e=> 
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.germanstrias.org_&d=DwMDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Wwl42dL5uGJa8PR0aAcNnIN0t-uut5R2xLKBhl0ynV8&s=z45_PX78N6zLu1Bcn-mYQcyRortvXjNyQcWASriwsr0&e=> 
>>
>>
>>
>>
>>
>>
>>
>>
>> El 02/15/2018 a las 11:19 PM, Hervé Pagès escribió:
>>> On 02/15/2018 01:57 PM, Michael Lawrence wrote:
>>>>
>>>>
>>>> On Thu, Feb 15, 2018 at 1:45 PM, Hervé Pagès <hpages at fredhutch.org 
>>>> <mailto:hpages at fredhutch.org>> wrote:
>>>>
>>>>     On 02/15/2018 11:53 AM, Cook, Malcolm wrote:
>>>>
>>>>         Hi,
>>>>
>>>>         Can I ask, is this change under discussion in current 
>>>> release or
>>>>         so far in Bioconductor devel only (my assumption)?
>>>>
>>>>
>>>>     Bioconductor devel only.
>>>>
>>>>
>>>>            > On 02/15/2018 08:37 AM, Michael Lawrence wrote:
>>>>            > > So is as.list() no longer supported for GRanges 
>>>> objects?
>>>>         I have found it
>>>>            > > useful in places.
>>>>            >
>>>>            > Very few places. I found a dozen of them in the entire
>>>>         software repo.
>>>>
>>>>         However there are probably more in the wild...
>>>>
>>>>
>>>>     What as.list() was doing on a GRanges object was not 
>>>> documented. Relying
>>>>     on some kind of obscure undocumented feature is never a good idea.
>>>>
>>>>
>>>> There's just too much that is documented implicitly through 
>>>> inherited behaviors, or where we say things like "this data 
>>>> structure behaves as one would expect given base R". It's not fair 
>>>> to claim that those features are undocumented. Our documentation is 
>>>> not complete enough to use it as an excuse.
>>>
>>> It's not fair to suggest that this is a widely used feature either.
>>>
>>> I've identified all the places in the 1500 software packages where
>>> this was used, and, as I said, there were very few places. BTW I
>>> fixed most of them but my plan is to fix all of them. Some of the
>>> code that is outside the Bioc package corpus might be affected but
>>> it's fair to assume that this will be a very rare occurence. This can
>>> be mitigated by temporary restoring as.list() on GRanges, with a
>>> deprecation message, and wait 1 more devel cycle to replace it with
>>> the new behavior. I chose to disable it for now, on purpose, so I can
>>> identify packages that break (the build report is a great tool for
>>> that) and fix them.
>>>
>>> I'm not using the fact that as.list() on a GRanges is not documented
>>> as an excuse for anything. Only to help those with concerns to
>>> relativize and relax.
>>>
>>> H.
>>>
>>>>
>>>>
>>>>            > Now you should use as.list(as(gr, "GRangesList")) 
>>>> instead.
>>>>            > as.list() was behaving inconsistently on IRanges and
>>>>         GRanges objects,
>>>>            > which is blocking new developments. It will come back 
>>>> with
>>>>         a consistent
>>>>            > behavior. More generally speaking IRanges and GRanges 
>>>> will
>>>>         behave
>>>>            > consistently as far as their "list interpretation" is
>>>>         concerned.
>>>>
>>>>         Can we please be assured to be reminded of this prominently in
>>>>         release notes?
>>>>
>>>>
>>>>     The changes will be announced and described on this list and in 
>>>> the
>>>>     NEWS files of the IRanges and GenomicRanges packages.
>>>>
>>>>     H.
>>>>
>>>>
>>>>         Thanks!
>>>>
>>>>         ~malcolm
>>>>
>>>>
>>>>     --     Hervé Pagès
>>>>
>>>>     Program in Computational Biology
>>>>     Division of Public Health Sciences
>>>>     Fred Hutchinson Cancer Research Center
>>>>     1100 Fairview Ave. N, M1-B514
>>>>     P.O. Box 19024
>>>>     Seattle, WA 98109-1024
>>>>
>>>>     E-mail: hpages at fredhutch.org <mailto:hpages at fredhutch.org>
>>>>     Phone: (206) 667-5791 <tel:%28206%29%20667-5791>
>>>>     Fax: (206) 667-1319 <tel:%28206%29%20667-1319>
>>>>
>>>>
>>>
>>
>



More information about the Bioc-devel mailing list