Re: [Python-ideas] Fwd: grouping / dict of lists
On Sun, Jul 1, 2018 at 7:12 PM, David Mertz wrote:
> Michael changed from set to list at my urging. A list is more general. A
> groupby in Pandas or SQL does not enforce uniqueness, but DOES preserve
> order.
>
It really is better to construct the collection using lists—in the fully
general manner—and then only throw away the generality when that
appropriate.
well, yes -- if there were only one option, then list is pretty obvious.
but whether converting to sets after the fact is just as good or not -- I
don't think so.
It's only just as good if you think of it as a one-time operation --
process a bunch of data all at once, and get back a dict with the results.
But I'm thinking of it in a different way:
Create a custom class derived from dict that you can add stuff to at any
time --much more like the current examples in the collections module.
If you simply want a groupby function that returns a regular dict, then you
need a utility function (or a few), not a new class.
If you are making a class that enforces the the values to be a collection
of items, then list is the obvious default, but of someone wants a set --
they want it built in to the class, not converted after the fact.
I've extended my prototype to do just that:
class Grouping(dict):
...
def __init__(self, iterable=(), *, collection=list):
"collection" is a class that's either a Mutable Sequence (has .append and
.extend methods) or Set (has .add and .update methods).
Once you create a Grouping instance, the collection class you pass in is
used everywhere.
I've put the prototype up on gitHub if anyone wants to take a look, try it
out, suggest changes, etc:
https://github.com/PythonCHB/grouper
(and enclosed here)
Note that I am NOT proposing this particular implementation or names, or
anything. I welcome feedback on the implementation, API and naming scheme,
but it would be great if we could all be clear on whether the critique is
of the idea or of the implementation.
This particular implementation uses pretty hack meta-class magic (or the
type constructor anyway) -- if something set-like is passed in, it creates
a subclass that adds .append and .extend methods, so that the rest of the
code doesn't have to special case. Not sure if that's a good idea, it feels
pretty kludgy -- but kinda fun to write.
It also needs more test cases and example use cases for sure.
And before we go much farther with this discussion, it would be great to
see some more real-world use cases, if anyone has some in mind.
-CHB
---
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
from collections.abc import Mapping
import heapq
# extra methods to tack on to set to make it "act" like a list.
extra_methods = {"append": lambda self, value: self.add(value),
"extend": lambda self, sequence: self.update(set(sequence))}
class Grouping(dict):
"""
Dict subclass for grouping elements of a sequence.
The values in the dict are a list of all items that have
corresponded to a given key
essentially, adding an new item is the same as:
dict.setdefault(key, []).append(value)
In other words, for each item added:
grouper['key'] = 'value'
If they key is already there, the value is added to the corresponding list.
If the key is not already there, a new entry is added, with the key as the
key, and the value is a new list with the single entry of the value in it.
The __init__ (and update) can take either a mapping of keys to lists,
or an iterable of (key, value) tuples.
If the initial data is not in exactly the form desired, an generator
expression can be used to "transform" the input.
For example:
>>> Grouping(((c.casefold(), c) for c in 'AbBa'))
Grouping({'a': ['A', 'a'], 'b': ['b', 'B']})
"""
def __init__(self, iterable=(), *, collection=list):
"""
Create a new Grouping object.
:param iterable: an iterable or mapping with initial data.
"""
if hasattr(collection, "append") and hasattr(collection, "extend"):
self.collection = list
elif hasattr(collection, "add") and hasattr(collection, "update"):
# this is very kludgy -- adding append and extend methods to a
# set or set-like object
self.collection = type("appendset", (set,), extra_methods)
else:
raise TypeError("collection has to be a MutableSequence or set-like object")
super().__init__()
self.update(iterable)
# Override a few dict methods
def __setitem__(self, key, value):
self.setdefault(key, self.collection()).append(value)
def __repr__(self):
return f"Grouping({super().__repr__()})"
@classmethod
def fromkeys(cls, iterable,
Re: [Python-ideas] Fwd: grouping / dict of lists
On Sun, Jul 1, 2018 at 7:28 PM, David Mertz wrote:
> But it's pretty simple. Whether my idea of collections.Grouping is adapted
> or whether a function/classmethod grouping() produces a plain dictionary,
>
or my custom class...
> the casting would be the same:
>
> {k:set(v) for k,v in deps.items()}
>
> {k:Counter(v) for k,v in deps.items()}
>
hmm, makes we wonder if it would make sense to update my implementation to
allow mapping types as well for the collection --now we'd be getting really
magic
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Fwd: grouping / dict of lists
Oh, it looks like he has modified the PEP and taken out the examples of
conversion. That's too bad, hopefully they'll be added back.
But it's pretty simple. Whether my idea of collections.Grouping is adapted
or whether a function/classmethod grouping() produces a plain dictionary,
the casting would be the same:
{k:set(v) for k,v in deps.items()}
{k:Counter(v) for k,v in deps.items()}
On Sun, Jul 1, 2018, 10:12 PM David Mertz wrote:
> Michael changed from set to list at my urging. A list is more general. A
> groupby in Pandas or SQL does not enforce uniqueness, but DOES preserve
> order. I think the PEP is not fully updated, but it's a list everywhere in
> the proposal itself, just not in the "old techniques."
>
> Moreover, Michael gives example of "casting" the Grouping to a dictionary
> with either sets or Counters as values. Both are useful, and both can be
> derived from list. But you cannot go backwards from either to the list. The
> transformation is simple and obvious, and can be included in eventual
> documentation.
>
> It really is better to construct the collection using lists—in the fully
> general manner—and then only throw away the generality when that
> appropriate.
>
> On Sun, Jul 1, 2018, 8:47 PM Chris Barker via Python-ideas <
> python-ideas@python.org> wrote:
>
>>
>>
>> Ivan,
>>
>> Did you mean this to go to the list? I hope so, as I've cc-d it this time
>> :-)
>>
>> On Sun, Jul 1, 2018 at 1:20 AM, Ivan Levkivskyi
>> wrote:
>>
>>> On 1 July 2018 at 06:18, Chris Barker via Python-ideas <
>>> python-ideas@python.org> wrote:
>>>
I'm really warming to the:
Alternate: collections.Grouping
version -- I really like this as a kind of custom mapping, rather than
"just a function" (or alternate constructor) --
>>>
>> I wanted the group to be represented as a set, not a list. I however
>>> understand that list may be more common. Can we design an API that
>>> would make this configurable? Something like:
>>>
>>> from collections import Grouping
>>>
>>> deps = Grouping(set) # list can be the default
>>> deps.update(other_deps) # uses set.update or list.extend for every
>>> key
>>> deps.add(trigger, target) # uses set.add or list.append
>>>
>>
>> yeah, I thought about that too -- Michael was using set() in some of his
>> examples.
>>
>> But the question is -- do we have a single switchable version or just too
>> classes?
>>
>>
>>> Probably allowing an arbitrary collection for values is to general/hard.
>>>
>>
>> maybe not -- if we had the criteria that you pass in any collection you
>> wanted, as long as it had either an .append() or .add()method, it would
>> be pretty easy to do with duck typing magic.
>>
>> Sure -- a user could make a mess easily enough by passing in a weird
>> custom class, but so what? Using something other than a set or list would
>> be a "at your own risk" thing anyway.
>>
>>
>>> Maybe we can just add a flag `unique=True` to the constructor, that will
>>> cause using sets instead of lists for groups?
>>>
>>
>> That's another, more robust, but less flexible option.
>>
>> Stay tuned for a prototype, if I can get it done fast
>>
>> -CHB
>>
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR(206) 526-6959 voice
>> 7600 Sand Point Way NE (206) 526-6329 fax
>> Seattle, WA 98115 (206) 526-6317 main reception
>>
>> chris.bar...@noaa.gov
>>
>>
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR(206) 526-6959 voice
>> 7600 Sand Point Way NE (206) 526-6329 fax
>> Seattle, WA 98115 (206) 526-6317 main reception
>>
>> chris.bar...@noaa.gov
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Fwd: grouping / dict of lists
Michael changed from set to list at my urging. A list is more general. A groupby in Pandas or SQL does not enforce uniqueness, but DOES preserve order. I think the PEP is not fully updated, but it's a list everywhere in the proposal itself, just not in the "old techniques." Moreover, Michael gives example of "casting" the Grouping to a dictionary with either sets or Counters as values. Both are useful, and both can be derived from list. But you cannot go backwards from either to the list. The transformation is simple and obvious, and can be included in eventual documentation. It really is better to construct the collection using lists—in the fully general manner—and then only throw away the generality when that appropriate. On Sun, Jul 1, 2018, 8:47 PM Chris Barker via Python-ideas < python-ideas@python.org> wrote: > > > Ivan, > > Did you mean this to go to the list? I hope so, as I've cc-d it this time > :-) > > On Sun, Jul 1, 2018 at 1:20 AM, Ivan Levkivskyi > wrote: > >> On 1 July 2018 at 06:18, Chris Barker via Python-ideas < >> python-ideas@python.org> wrote: >> >>> I'm really warming to the: >>> >>> Alternate: collections.Grouping >>> >>> version -- I really like this as a kind of custom mapping, rather than >>> "just a function" (or alternate constructor) -- >>> >> > I wanted the group to be represented as a set, not a list. I however >> understand that list may be more common. Can we design an API that >> would make this configurable? Something like: >> >> from collections import Grouping >> >> deps = Grouping(set) # list can be the default >> deps.update(other_deps) # uses set.update or list.extend for every >> key >> deps.add(trigger, target) # uses set.add or list.append >> > > yeah, I thought about that too -- Michael was using set() in some of his > examples. > > But the question is -- do we have a single switchable version or just too > classes? > > >> Probably allowing an arbitrary collection for values is to general/hard. >> > > maybe not -- if we had the criteria that you pass in any collection you > wanted, as long as it had either an .append() or .add()method, it would > be pretty easy to do with duck typing magic. > > Sure -- a user could make a mess easily enough by passing in a weird > custom class, but so what? Using something other than a set or list would > be a "at your own risk" thing anyway. > > >> Maybe we can just add a flag `unique=True` to the constructor, that will >> cause using sets instead of lists for groups? >> > > That's another, more robust, but less flexible option. > > Stay tuned for a prototype, if I can get it done fast > > -CHB > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Fwd: grouping / dict of lists
Ivan, Did you mean this to go to the list? I hope so, as I've cc-d it this time :-) On Sun, Jul 1, 2018 at 1:20 AM, Ivan Levkivskyi wrote: > On 1 July 2018 at 06:18, Chris Barker via Python-ideas < > python-ideas@python.org> wrote: > >> I'm really warming to the: >> >> Alternate: collections.Grouping >> >> version -- I really like this as a kind of custom mapping, rather than >> "just a function" (or alternate constructor) -- >> > I wanted the group to be represented as a set, not a list. I however > understand that list may be more common. Can we design an API that > would make this configurable? Something like: > > from collections import Grouping > > deps = Grouping(set) # list can be the default > deps.update(other_deps) # uses set.update or list.extend for every key > deps.add(trigger, target) # uses set.add or list.append > yeah, I thought about that too -- Michael was using set() in some of his examples. But the question is -- do we have a single switchable version or just too classes? > Probably allowing an arbitrary collection for values is to general/hard. > maybe not -- if we had the criteria that you pass in any collection you wanted, as long as it had either an .append() or .add()method, it would be pretty easy to do with duck typing magic. Sure -- a user could make a mess easily enough by passing in a weird custom class, but so what? Using something other than a set or list would be a "at your own risk" thing anyway. > Maybe we can just add a flag `unique=True` to the constructor, that will > cause using sets instead of lists for groups? > That's another, more robust, but less flexible option. Stay tuned for a prototype, if I can get it done fast -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Should nested classes in an Enum be Enum members?
On 1 July 2018 at 20:47, Ethan Furman wrote: > On 07/01/2018 06:03 AM, Ivan Levkivskyi wrote:> On 27 June 2018 at 15:46, > Ethan Furman wrote: > > [...] >>> So I'm asking the community: What real-world examples can you offer for >>> either behavior? Cases where nested >>> classes should be enum members, and cases where nested classes should >>> not be members. >>> >> >> I wanted few times to make an enum of enums. For example: >> >> class Method(Enum): >> Powell = 1 >> Newton_CG = 2 >> >> class Trust(Enum): >> Constr = 3 >> Exact = 4 >> >> >> So that one can write: >> >> minimize(..., method=Method.Powell) >> minimize(..., method=Method.Trust.Exact) # this currently fails >> > > In such a case, would you want/expect for > > --> list(Method) > > to return > > [, , ..., ] > > ? > I am fine with what `list(Method)` does currently: [, , >] I think it is intuitive that the nested enums are _not_ automatically flattened. Also it is easy to write a helper that manually flattens nested enums, but it would be tedious to group them back if they are already flattened. The only thing that I find a bit unintuitive is that one needs to write `Method.Trust.value.Exact` instead of just `Method.Trust.Exact`. Maybe his can be allowed by adding a `__getattr__` to `Method` (by the metaclass) that will check if a value is an enum and delegate the attribute access. -- Ivan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add a __cite__ method for scientific packages
> -Original Message-
> From: Python-ideas list=sdamon@python.org> On Behalf Of Nick Timkovich
> Sent: Sunday, July 1, 2018 12:02 PM
> To: Matt Arcidy
> Cc: python-ideas
> Subject: Re: [Python-ideas] Add a __cite__ method for scientific packages
>
> From an abstract level, however, citing code requires that it's published in
> some form, which is very strongly related to packaging, so I think such
> discussions would best revolve around there. Maybe rolling something into
> pkg_resources that could pull out a short citation string from some package
> metadata (a hypothetical `pkg_resources.get_distribution("numpy").citation`
> that could be wrapped by some helper function if desired)? The actual
> mechanism to convert metadata into something in the repo (a dunder cite
> string in the root module, a separate metadata file, etc.) into the package
> metadata isn't as important as rolling said metadata into something part of
> the distribution package like the version or long_description fields. Once the
> schema of the citation data is defined, you could add it to the metadata spec
> (outgrowth of PEP-566) https://packaging.python.org/specifications/core-
> metadata/
Putting citation information into pyproject.toml makes a lot more sense than
putting it in the modules themselves, where they would have to be introspected
to be extracted.
* It puts zero burden on the core developers
* It puts near zero burden on the distutils special interest group
* It doesn't consume names from the package namespace
* It's just a TOML file - you can add sections to it willy-nilly
* It's just a TOML file - there's libraries in almost all ecosystems to handle
it.
Nothing has to go into the core metadata specification unless part of your
suggestion is that Pypi show the citations. I don't think that is a good idea
for the scope of Pypi and the workload of the warehouse developers. I don't
think it's too much to ask for the scientific community to figure out the
solution that works for most people before bringing it back here. I also don't
think its out of scope to suggest taking this to SciPy - yes, not everything
depends on SciPy, but you don't need everything, you just momentum.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Should nested classes in an Enum be Enum members?
On 07/01/2018 06:03 AM, Ivan Levkivskyi wrote:> On 27 June 2018 at 15:46, Ethan Furman wrote: [...] So I'm asking the community: What real-world examples can you offer for either behavior? Cases where nested classes should be enum members, and cases where nested classes should not be members. I wanted few times to make an enum of enums. For example: class Method(Enum): Powell = 1 Newton_CG = 2 class Trust(Enum): Constr = 3 Exact = 4 So that one can write: minimize(..., method=Method.Powell) minimize(..., method=Method.Trust.Exact) # this currently fails In such a case, would you want/expect for --> list(Method) to return [, , ..., ] ? -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add a __cite__ method for scientific packages
On Fri, Jun 29, 2018 at 8:58 PM, Matt Arcidy wrote:
> It seems like the very small percentage of academic users whose careers
> depend on this cannot resolve the political issue of forming a standards
> body.
>
> I don't see how externalizing the standard development will help. Kudos
> for shortcutting the process in a practical way to just get it done, but
> this just puts core devs in the middle of silly academic spats. A language
> endorsed citation method isn't a 'correct' method, and without the broad
> consensus that currently doesn't exist, this becomes _your_ method, a
> picked winner but ultimately a lightning rod for bored tenured professors
> with personal axes to grind. If this were about implementing an existing
> correct method I'm sure a grad student would be tasked with it for an
> afternoon.
>
>
[...] Just create a jstor style git server where obeying the citation
> protocol is mandatory.
>
I don't know if it constitutes a standards body, but there are a couple
journals out there that are meant to serve as mechanisms for turning a repo
into a published/citable thing, they might be good to look at for prior art
as well as to what metadata should be included:
* https://joss.theoj.org/about (sponsored by NumFOCUS)
* https://www.journals.elsevier.com/softwarex/
>From an abstract level, however, citing code requires that it's published
in some form, which is very strongly related to packaging, so I think such
discussions would best revolve around there. Maybe rolling something into
pkg_resources that could pull out a short citation string from some package
metadata (a hypothetical `pkg_resources.get_distribution("numpy").citation`
that could be wrapped by some helper function if desired)? The actual
mechanism to convert metadata into something in the repo (a dunder cite
string in the root module, a separate metadata file, etc.) into the package
metadata isn't as important as rolling said metadata into something part of
the distribution package like the version or long_description fields. Once
the schema of the citation data is defined, you could add it to the
metadata spec (outgrowth of PEP-566)
https://packaging.python.org/specifications/core-metadata/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add a __cite__ method for scientific packages
I think a __citation__ *method* is a bad idea. This yells out "attribute" to me. A function or two that parses those attributes in some manner is a better idea... And there's no reason that function or two need to be dunders. There's also no reason they need to be in the standard library... There might be many citation/writing applications that process the data to their own needs. But assuming there is an attribute, WHAT goes inside it? Is it a string? And if so, in what markup format? Is it a dictionary? A list? A custom class? Does some wrapper function deal with different formats. Does the wrapper also scan for __author__, __copyright__, and friends? We also need to decide what __citation__ is an attribute OF. Only modules? Classes? Methods? Functions? All of the above? If multiple, how are the attributes at different places synthesized or processed? Can one object have multiple citations (e.g. what if a class or method implements multiple algorithms depending on a switch... Or depending on the shape of the data being processed? The different algorithms might need different citations). These are all questions that could have good answers. But I don't know what the answers are. I've worked in scientific computing for a good while, but not as an academic. And when I was an academic it wasn't in scientific computing. This list is not mostly composed of the relevant experts. Those are the authors and users of SciPy and statsmodels, and scikit-learn, and xarray, and Tensorflow, and astropy, and so on. There's absolutely nothing in the idea that requires a change in Python, and Python developers or users are not, as such, the relevant experts. In the future, AFTER there is widespread acceptance of what goes on a __citation__ attribute, it would be easy and obvious to add minimal support in Python itself for displaying citation content. But this is the wrong group to mandate what the actual academic needs are here. On Sun, Jul 1, 2018, 9:07 AM Ivan Levkivskyi wrote: > On 28 June 2018 at 01:19, Nathaniel Smith wrote: > >> On Wed, Jun 27, 2018 at 2:20 PM, Andrei Kucharavy >> wrote: >> > To remediate to that situation, I suggest a __citation__ method >> associated >> > to each package installation and import. Called from the __main__, >> > __citation__() would scan __citation__ of all imported packages and >> return >> > the list of all relevant top-level citations associated to the packages. >> > > I actually think the opposite. If this is not fixed in a PEP it will stay > in the current state. > Writing a PEP (and officially accepting it) for this purpose will give a > signal that it is a standard practice > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Should nested classes in an Enum be Enum members?
Replying to the list this time. On 27 June 2018 at 15:46, Ethan Furman wrote: > [...] > So I'm asking the community: What real-world examples can you offer for > either behavior? Cases where nested classes should be enum members, and > cases where nested classes should not be members. > I wanted few times to make an enum of enums. For example: class Method(Enum): Powell = 1 Newton_CG = 2 class Trust(Enum): Constr = 3 Exact = 4 So that one can write: minimize(..., method=Method.Powell) minimize(..., method=Method.Trust.Exact) # this currently fails -- Ivan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add a __cite__ method for scientific packages
On 28 June 2018 at 01:19, Nathaniel Smith wrote: > On Wed, Jun 27, 2018 at 2:20 PM, Andrei Kucharavy > wrote: > > To remediate to that situation, I suggest a __citation__ method > associated > > to each package installation and import. Called from the __main__, > > __citation__() would scan __citation__ of all imported packages and > return > > the list of all relevant top-level citations associated to the packages. > > > > As a scientific package developer working in academia, the problem is > quite > > serious, and the solution seems relatively straightforward. > > > > What does Python core team think about addition and long-term > maintenance of > > such a feature to the import and setup mechanisms? What do other users > and > > scientific package developers think of such a mechanism for citations > > retrieval? > > This is indeed a serious problem. I suspect python-ideas isn't the > best venue for addressing it though – there's nothing here that needs > changes to the Python interpreter itself (I think), and the people who > understand this problem the best and who are most affected by it, > mostly aren't here. > I actually think the opposite. If this is not fixed in a PEP it will stay in the current state. Writing a PEP (and officially accepting it) for this purpose will give a signal that it is a standard practice ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] grouping / dict of lists
On 1 July 2018 at 15:18, Chris Barker via Python-ideas
wrote:
> On Fri, Jun 29, 2018 at 10:53 AM, Michael Selik wrote:
>>
>> I've drafted a PEP for an easier way to construct groups of elements from
>> a sequence. https://github.com/selik/peps/blob/master/pep-.rst
>>
> I'm really warming to the:
>
> Alternate: collections.Grouping
>
> version -- I really like this as a kind of custom mapping, rather than "just
> a function" (or alternate constructor) -- and I like your point that it can
> have a bit of functionality built in other than on construction.
>
> But I think it should be more like the other collection classes -- i.e. a
> general purpose class that can be used for grouping, but also used more
> general-purpose-y as well. That way people can do their "custom" stuff (key
> function, etc.) with comprehensions.
>
> The big differences are a custom __setitem__:
>
> def __setitem__(self, key, value):
> self.setdefault(key, []).append(value)
>
> And the __init__ and update would take an iterable of (key, value) pairs,
> rather than a single sequence.
>
> This would get away from the itertools.groupby approach, which I find kinda
> awkward:
>
> * How often do you have your data in a single sequence?
>
> * Do you need your keys (and values!) to be sortable???)
>
> * Do we really want folks to have to be writing custom key functions and/or
> lambdas for really simple stuff?
>
> * and you may need to "transform" both your keys and values
>
> I've enclosed an example implementation, borrowing heavily from Michael's
> code.
>
> The test code has a couple examples of use, but I'll put them here for the
> sake of discussion.
>
> Michael had:
>
> Grouping('AbBa', key=c.casefold))
>
> with my code, that would be:
>
> Grouping(((c.casefold(), c) for c in 'AbBa'))
>
> Note that the key function is applied outside the Grouping object, it
> doesn't need to know anything about it -- and then users can use an
> expression in a comprehension rather than a key function.
>
> This looks a tad clumsier with my approach, but this is a pretty contrived
> example -- in the more common case [*], you'd be writing a bunch of lambdas,
> etc, and I'm not sure there is a way to get the values customized as well,
> if you want that. (without applying a map later on)
>
> Here is the example that the OP posted that kicked off this thread:
>
> In [37]: student_school_list = [('Fred', 'SchoolA'),
> ...:('Bob', 'SchoolB'),
> ...:('Mary', 'SchoolA'),
> ...:('Jane', 'SchoolB'),
> ...:('Nancy', 'SchoolC'),
> ...:]
>
> In [38]: Grouping(((item[1], item[0]) for item in student_school_list))
> Out[38]: Grouping({'SchoolA': ['Fred', 'Mary'],
>'SchoolB': ['Bob', 'Jane'],
>'SchoolC': ['Nancy']})
Unpacking and repacking the tuple would also work:
Grouping(((school, student) for student, school in student_school_list))
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
