Re: [Python-ideas] Fwd: collections.Counter should implement fromkeys

[Abe Dillon]

[Steven D'Aprano]

> In the case where all the inital counts are zero, the obvious API is to
> call the dict fromkeys method:
> Counter(dict.fromkeys(['a', 'b', 'ab'], 0))


Yes, I've discussed this, but since my replies have been miss addressed, it
may have gotten lost.
I'll quote it below:

[Abe Dillon]

> Counter(dict.fromkeys(keys, value)) works just fine, but it feels wrong.
> I'm using the copy-constructor because I know Counter is a subclass of
> dict.
> I'm using fromkeys because I know how that class method works.
> So why does the subclass lack functionality that the superclass has?
> Because programmers wouldn't be able to wrap their heads around it?
> I don't buy it. This feels like nanny-design trumping SOLID design
> .


[Steven D'Aprano]

> So what you're really asking for is a convenience method to bypass the
> need to create a temporary dict first


I'm not asking for anything all that new. Just that the existing .fromkeys
inherited from dict not be disabled.

[Steven D'Aprano]

> Presumably the initial value will default to 0 rather than None, and
> take any integer value.


Yes. I think that would make the most sense. 0 or 1. As long as it's
documented it doesn't matter to me.

[Steven D'Aprano]

> Tim's point about duplicate keys is valid. Should it raise an exception,
> silently swallow duplicates, or
> count them?


It should do exactly what dict.fromkeys does (except with a numeric
default): ignore duplicates

[Steven D'Aprano]

> The dict constructors, both the standard dict() and dict.fromkeys(),
> silently swallow duplicates. As they should. But Counter() does not,
> and should not.


That's fine. I don't think that's confusing.

[Steven D'Aprano]

> How about a fourth constructor? A fifth? A fiftith? How many
> constructors is too many before the class becomes unwieldy?


I think this is a little overboard on the slippery-slope, no? I'm asking
for a constructor that already exists, but was deliberately disabled.
As far as I can tell, the only people pointing out that others will
complain are playing devil's advocate.
I can't tell if there are any people that actually believe that
Counter.fromkeys should have a multiplier effect.
I wouldn't expect the campaign for the third type of constructor to get
very far. Especially if Counter multiplication gets accepted.

[Tim]

> I think the missing bit here is that there weren't any "constructor wars"
> for Counter...

15 years later you're jumping up & down about Counter.fromkeys() not being
> there, and that's why nobody much cares ;-)


I haven't been part of the conversation for 15 years, but most of the
argument against the idea (yours especially) seem to focus on the prospect
of a constructor war and imply that was the original motivation behind
actively disabling the fromkeys method in Counters. I don't mean to give
the impression that I'm fanatical about this. It really is a minor
inconvenience. It doesn't irk me nearly as much as other minor things, like
that the fact that all the functions in the heapq package begin with the
redundant word 'heap'.

[Tim]

> Raymond may have a different judgment about that, though.  I don't believe
> he reads python-ideas anymore


He actually did reply a few comments back!
I think I'm having more fun chatting with people that I deeply respect than
"jumping up and down". I'm sorry if I'm coming off as an asshole. We can
kill this thread if everyone thinks I'm wasting their time. It doesn't look
like anyone else shares my minor annoyance. Thanks for indulging me!

On Fri, Jun 29, 2018 at 9:37 PM, Steven D'Aprano 
wrote:

> On Fri, Jun 29, 2018 at 05:32:54PM -0700, Abe Dillon wrote:
>
> > Sure, but in Hettinger's own words
> >  "whenever you
> have a
> > constructor war, everyone should get their wish". People that want a
> > counting constructor have that,
> > people that want the ability to initialize values don't have that.
>
> *scratches head*
>
> I can initalise a Counter just fine.
>
> py> Counter({'a': 0, 'b': 0, 'ab': 2})
> Counter({'ab': 2, 'a': 0, 'b': 0})
>
> The supported API for setting initial values of a counter is to either
> count the supplied keys:
>
> Counter(['a', 'b', 'ab'])
>
> or supply initial counts in a dict:
>
> Counter({'a': 0, 'b': 0, 'ab': 2})
>
> In the case where all the inital counts are zero, the obvious API is to
> call the dict fromkeys method:
>
> Counter(dict.fromkeys(['a', 'b', 'ab'], 0))
>
>
> So what you're really asking for is a convenience method to bypass the
> need to create a temporary dict first:
>
> Counter.fromkeys(['a', 'b', 'ab'], 0)
>
> Presumably the initial value will default to 0 rather than None, and
> take any integer value.
>
> I'm sympathetic to the idea of this as a convenience, but I don't think
> its an obvious feature to have. Tim's point about duplicate keys is
> valid. Should it raise an exception, silently swallow duplicates, 

Re: [Python-ideas] Fwd: collections.Counter should implement fromkeys

[Raymond Hettinger]

On Jun 29, 2018, at 5:32 PM, Abe Dillon  wrote:
> 
> Sure, but in Hettinger's own words "whenever you have a constructor war, 
> everyone should get their wish". People that want a counting constructor have 
> that,
> people that want the ability to initialize values don't have that.

Sorry Abe, but you're twisting my words and pushing very hard for a proposal 
that doesn't make sense and isn't necessary.

* Counts initialized to zero:   This isn't necessary.  The whole point of 
counters is that counts default to zero without pre-initialization.

* Counts initialized to one:  This is already done by the regular constructor.  
Use "Counter(keys)" if the keys are known to be unique and "Counter(set(keys)" 
to ignore duplicates.

>>> Counter('abc')
Counter({'a': 1, 'b': 1, 'c': 1})
>>> Counter(set('abbacac'))
Counter({'a': 1, 'b': 1, 'c': 1})

* Counts initialized to some other value:  That would be an unusual thing to do 
but would be easy with the current API.

>>> Counter(dict.fromkeys('abc', 21))
Counter({'a': 21, 'b': 21, 'c': 21})

* Note, the reason that fromkeys() is disabled is that it has nonsensical or 
surprising interpretations:

>>> Counter.fromkeys('aaabbc', 2)  # What should this do that 
doesn't surprise at least some users?

* That reason is already shown in the source code.

@classmethod
def fromkeys(cls, iterable, v=None):
# There is no equivalent method for counters because setting v=1
# means that no element can have a count greater than one.
raise NotImplementedError(
'Counter.fromkeys() is undefined.  Use Counter(iterable) 
instead.')

> Obviously, Python breaks SOLID principals successfully all over the place for 
> pragmatic reasons.
> I don't think this is one of those cases.


No amount of citing generic design principles will justify adding an API that 
doesn't make sense.  

Besides, any possible use cases already have reasonable solutions using the 
existing API.  That is likely why no one has ever requested this behavior 
before.

Based on what I've read in this thread, I see nothing that would change the 
long-standing decision not to have a fromkeys() method for collections.Counter. 
 The original reasoning still holds.


Raymond
  
___
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: collections.Counter should implement fromkeys

[Tim Peters]

[
Note to repliers to Abe (and others recently):  replies to Google Groups
posts are broken for now on this list, so be sure to replace

python-id...@googlegroups.com

with

python-ideas@python.org

in your reply.  Else the mailing list (neither Google Groups nor the
python.org archive) won't get it.
]

[Tim]
>> So, e.g., someone will be unpleasantly surprised no matter what

[Abe Dillon]
> Sure, but in Hettinger's own words
 "whenever you have a
constructor war,
> everyone should get their wish". People that want a counting constructor
> have that,people that want the ability to initialize values don't have
that.

I think the missing bit here is that there weren't any "constructor wars"
for Counter.  In all this time, I don't believe I've heard anyone say they
wanted a Counter.fromkeys() before.  For that matter, I'd bet a dollar that
most Python programmers don't know that dict.fromkeys() exists, despite
that it was added in Python 2.3.

As I recall, the primary motivation for adding dict.fromkeys() was to make
using dicts to mimic sets a little easier, by providing a constructor that
threw away duplicates and didn't really care about the values (so no value
was required, and nobody cared that it defaulted to the _seemingly_ insane
`None` - using `None` values for sets-implemented-as-dicts was a de facto
informal standard at the time).

But one release later (2.4) a set type was added too, so the primary
motivation for fromkeys() went away.

15 years later you're jumping up & down about Counter.fromkeys() not being
there, and that's why nobody much cares ;-)


> ...
> I'm tempted to indulge in the meta argument which you're obviously
> striving to avoid,

And succeeding!  I can't be sucked into it :-)  FWIW, fine by me if
Counter.fromkeys() is added, doing exactly what you want.  Raymond may have
a different judgment about that, though.  I don't believe he reads
python-ideas anymore, so opening an enhancement request on bugs.python.org
is the way to get his attention.
___
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: collections.Counter should implement fromkeys

[Steven D'Aprano]

On Fri, Jun 29, 2018 at 05:32:54PM -0700, Abe Dillon wrote:

> Sure, but in Hettinger's own words 
>  "whenever you have a 
> constructor war, everyone should get their wish". People that want a 
> counting constructor have that,
> people that want the ability to initialize values don't have that.

*scratches head*

I can initalise a Counter just fine.

py> Counter({'a': 0, 'b': 0, 'ab': 2})
Counter({'ab': 2, 'a': 0, 'b': 0})

The supported API for setting initial values of a counter is to either 
count the supplied keys:

Counter(['a', 'b', 'ab'])

or supply initial counts in a dict:

Counter({'a': 0, 'b': 0, 'ab': 2})

In the case where all the inital counts are zero, the obvious API is to 
call the dict fromkeys method:

Counter(dict.fromkeys(['a', 'b', 'ab'], 0))


So what you're really asking for is a convenience method to bypass the 
need to create a temporary dict first:

Counter.fromkeys(['a', 'b', 'ab'], 0)

Presumably the initial value will default to 0 rather than None, and 
take any integer value.

I'm sympathetic to the idea of this as a convenience, but I don't think 
its an obvious feature to have. Tim's point about duplicate keys is 
valid. Should it raise an exception, silently swallow duplicates, or 
count them?

The dict constructors, both the standard dict() and dict.fromkeys(), 
silently swallow duplicates. As they should. But Counter() does not, 
and should not.

There's a discrepency if Counter() doesn't and Counter.fromkeys() does, 
and it requires a value judgement to decide whether that discrepency is 
sufficiently unimportant.


[...]
> Technically, there is no constructor for counting by X, but if enough 
> people really wanted that, I suppose a third constructor would be in order.

How about a fourth constructor? A fifth? A fiftith? How many 
constructors is too many before the class becomes unwieldy?

Not every way you might count with a counter needs to be a constructor 
method. You can always just count:

c = Counter()
for key in keys:
c[key] += X

I think you make a *reasonable* case for Counter.fromkeys to silently 
ignore duplicates, as a convenience method for 

Counter(dict.fromkeys(keys, 0)

but its not (in my opinion) a *compelling* argument. I think it comes 
down to the taste of the designer.

You can always subclass it. Or even monkey-patch it.

py> def fromkeys(cls, seq, value=0):
... c = cls()
... for key in seq:
... c[key] = value
... return c
...
py> from collections import Counter
py> Counter.fromkeys = classmethod(fromkeys)
py> Counter.fromkeys(['a', 'b', 'ab', 'a', 'b', 'c'])
Counter({'a': 0, 'ab': 0, 'b': 0, 'c': 0})

(Subclassing is safer :-)



-- 
Steve
___
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

[Matt Arcidy]

On Fri, Jun 29, 2018, 17:14 Andrei Kucharavy 
wrote:

> One more thing. There's precedent for this: when you start an interactive
>> Python interpreter it tells you how to get help, but also how to get
>> copyright, credits and license information:
>>
>> $ python3
>> Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 26 2018, 19:50:54)
>> [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> credits
>> Thanks to CWI, CNRI, BeOpen.com, Zope Corporation and a cast of
>> thousands
>> for supporting Python development.  See www.python.org for more
>> information.
>> >>>
>>
>
This is thin justification to add something to core.

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.

This is insanely easy to implement in docstrings, or a standard import, or
mandatory include, or decorator, or anywhere else, it's just a parsing
protocol.  I believe 3.7 now exposes docstrings in the AST, meaning a
simple static analyzer can handle all of PyPi, giving you crazy granularity
if citations existed.  Don't you want to cite the exact algorithm used in
an imported method, not just lump them all into one call?  Heck, I bet you
could use type annotations.

This really feels like you've got an amazing multi-tool but you want to
turn the world, not the screw. This isn't a tool the majority of people
will use, even if the citations exist.

Don't get me wrong, I love designing standards and protocols, but this is
pretty niche.

I assume it won't be mandatory so I'm tilting at windmills,  but then if
it's not mandatory, what's the point of putting it in core?  Just create a
jstor style git server where obeying the citation protocol is mandatory.
Of course, enforcing a missing citation is impossible, but it does mean
citations can be generated by parsing imports.  This is how it will evolve
over time, by employing core devs on that server framework.




>> It makes total sense to add citations/references to this list (and those
>> should probably print a reference for Python followed by instructions on
>> how to get references for other packages and how to properly add a
>> reference to your own code).
>>
>>
> If that's possible, that would be great!
>
>
>> I think that an approach similar to help/quit/exit is warranted. The
>> cite()/citation() function need not be *literally* built into the
>> language, it could be an external function written in Python and added
>> to builtins by the site.py module.
>
>
> I was not aware this was a possibility - it does seem like a good option!
>
> If I were you, I'd try organizing a birds-of-a-feather at the next
>> SciPy conference, or start getting in touch with others working on
>> this (duecredit devs, the folks listed on that citationPEP thing,
>> etc.), and go from there. (Feel free to CC me if you do start up some
>> effort like this.)
>
>
> Not all packages are within the numpy/scipy universe - Pandas and Seaborn
> are notable examples.
>
> I bought this thread to the attention of some major scientific package
> maintainers as well as the main citationPEP author. I am not entirely sure
> where this conversations could be moved outside python-ideas given we are
> talking about something universal across packages, but would gladly take
> any suggestions.
>
> There isn't actually any formal method for registering special names
>> like __version__, and they aren't treated specially by the language.
>> They're just variables that happen to have a funny name. You shouldn't
>> start using them willy-nilly, but you don't actually have to ask
>> permission or anything. And it's not very likely that someone else
>> will come along and propose using the name __citation__ for something
>> that *isn't* a citation :-).
>
>
> Thanks for the explanation - Python development and maintenance do seem to
> be a complex process from the outside and this kind of subtleties are not
> always easy to distinguish :).
>
> The way to do this is to first get your solution implemented as a
>> third-party library and adopted by the scientific packages, and then
>> start thinking about whether it would make sense to move the library
>> into the standard library. It's relatively easy to move things into
>> the standard library. The hard part is making 

Re: [Python-ideas] Add a __cite__ method for scientific packages

[David Mertz]

On Fri, Jun 29, 2018, 8:14 PM Andrei Kucharavy 
wrote:
> Not all packages are within the numpy/scipy universe - Pandas and Seaborn
are notable examples.

Huh?! Pandas is a thin wrapper around NumPy. To be fair, it is a wrapper
that adds a huge number of wrapping methods and classes. Seaborn in turn
has at least a soft dependency on Pandas (some of the charts really need a
DataFrame to work from).

I like the idea of standardizing curation information. But it has little to
do with Python itself. Getting the authors of scientific packages to agree
on conventions is what needed, and doing that requires accurately
determining their needs, not some mandate from Python itself. Nothing in
the language needs to change to agree on some certain collection of names
(perhaps dunders, perhaps not), and some certain formats for the data that
might live inside them.

Down the road, if there gets to be widespread acceptance of these
conventions, Python standard library might include a function or two to
work with them. But the horse should go before the cart.
___
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] collections.Counter should implement fromkeys

[Abe Dillon]

[Michael Selik] 

> You might be pursuing a local optimum of obviousness. If you step back 
> from the idea of "initialize the counts with all interesting keys" and 
> looping over them, you might find a better overall solution.
>

That's a distinct possibility, but this is far from the first time I've 
wanted for a better way to initialize a Counter. It's just a simple example 
for which there are many many alternative approaches.

If' you're interested, I have a more complete implementation of the game of 
life here .

[Michael Selik] 

> That happens more frequently than my OOP professor seemed to think. I end 
> up with platypi (platypuses?) all too often.


Yes, I always try to caution my own students against strict adherence to 
any ideology, methodology, or cult.
"Always do this" and "Never do that" rules are useful crutches for novices 
trying to navigate the complex world of coding for the first time,
but pros are the ones who are experienced enough to know when it's OK to 
break the rules. When GoTo isn't harmful. When to break the rule of thirds 
.

Obviously, Python breaks SOLID principals successfully all over the place 
for pragmatic reasons.
I don't think this is one of those cases.
___
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: collections.Counter should implement fromkeys

[Abe Dillon]

[Tim Peters] 

> a fundamental use case for Counters is to tally the _number_ of times 
> duplicate keys appear.
>
 
Yes, that's why the default constructor already does just that. 

[Tim Peters] 

> So, e.g., someone will be unpleasantly surprised no matter what

 
Sure, but in Hettinger's own words 
 "whenever you have a 
constructor war, everyone should get their wish". People that want a 
counting constructor have that,
people that want the ability to initialize values don't have that.

[Tim Peters] 

> Counter.fromkeys("a", 2)
>
> returned.  "It should set key 'a' to 2!  that's what I said it should 
> do!"  "No!  It should set key 'a' to 10!  that's what a Counter _always_ 
> does - sums the values associated with duplicate keys!"
>

I'm tempted to indulge in the meta argument which you're obviously striving 
to avoid, but I will say this:
"that's what a Counter _always_ does" makes no sense. It's *almost* 
tantamount to saying that all constructors have to do exactly the same 
thing, which makes multiple constructors useless.

Technically, there is no constructor for counting by X, but if enough 
people really wanted that, I suppose a third constructor would be in order.
___
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

[Andrei Kucharavy]

>
> One more thing. There's precedent for this: when you start an interactive
> Python interpreter it tells you how to get help, but also how to get
> copyright, credits and license information:
>
> $ python3
> Python 3.6.6 (v3.6.6:4cf1f54eb7, Jun 26 2018, 19:50:54)
> [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> credits
> Thanks to CWI, CNRI, BeOpen.com, Zope Corporation and a cast of
> thousands
> for supporting Python development.  See www.python.org for more
> information.
> >>>
>
> It makes total sense to add citations/references to this list (and those
> should probably print a reference for Python followed by instructions on
> how to get references for other packages and how to properly add a
> reference to your own code).
>
>
If that's possible, that would be great!


> I think that an approach similar to help/quit/exit is warranted. The
> cite()/citation() function need not be *literally* built into the
> language, it could be an external function written in Python and added
> to builtins by the site.py module.


I was not aware this was a possibility - it does seem like a good option!

If I were you, I'd try organizing a birds-of-a-feather at the next
> SciPy conference, or start getting in touch with others working on
> this (duecredit devs, the folks listed on that citationPEP thing,
> etc.), and go from there. (Feel free to CC me if you do start up some
> effort like this.)


Not all packages are within the numpy/scipy universe - Pandas and Seaborn
are notable examples.

I bought this thread to the attention of some major scientific package
maintainers as well as the main citationPEP author. I am not entirely sure
where this conversations could be moved outside python-ideas given we are
talking about something universal across packages, but would gladly take
any suggestions.

There isn't actually any formal method for registering special names
> like __version__, and they aren't treated specially by the language.
> They're just variables that happen to have a funny name. You shouldn't
> start using them willy-nilly, but you don't actually have to ask
> permission or anything. And it's not very likely that someone else
> will come along and propose using the name __citation__ for something
> that *isn't* a citation :-).


Thanks for the explanation - Python development and maintenance do seem to
be a complex process from the outside and this kind of subtleties are not
always easy to distinguish :).

The way to do this is to first get your solution implemented as a
> third-party library and adopted by the scientific packages, and then
> start thinking about whether it would make sense to move the library
> into the standard library. It's relatively easy to move things into
> the standard library. The hard part is making sure that you
> implemented the right thing in the first place, and that's MUCH more
> likely if you start out as a third-party package.


Got it.

I think you misunderstand how these lists work :-). (Which is fine --
> it's actually pretty opaque and confusing if you don't already know!)
> Generally, distutils-sig operates totally independently from
> python-{ideas,dev} -- if you have a packaging proposal, it goes there
> and not here; if you have a language proposal, it goes here and not
> there. *If* what you want to do is add some static metadata to python
> packages through setup.py, then python-ideas is irrelevant and
> distutils-sig is who you'll have to convince. (But they'll also want
> to see that your proposal has buy-in from established packages,
> because they don't understand the intricacies of software citation and
> will want people they trust to tell them whether the proposal makes
> sense.)
>

Got it as well - that does indeed seem a reasonable way of doing things,
although I believe there have been precedents where GVM implemented a
feature from scratch after studying existing libraries (I am thinking
notably about asyncio, which is orders of magnitude more complex and
involved than anything we are talking here).

And often the custom scripts are a mix of R and Python, and maybe some
> Fortran, ... Plus, if it works for multiple languages, it means you
> get to share part of the work with other ecosystems, instead of
> everyone reinventing the wheel.
>
> Also, if you want to go down the dynamic route (which is the only way
> to get accurate fine-grained citations), then it's just as easy to
> solve the problem in a language independent way.
>

In my experience, people tend to go with either one or other or use Julia.
I am not very familiar with Fortran ecosystem - as far as I've seen, those
are extremely efficient libraries that get wrapped and used in most modern
scientific computing languages, but very rarely directly.

In addition to that, while I see how granular citations could be
implemented in Python, I have a bit more trouble understanding how 

[Python-ideas] Fwd: collections.Counter should implement fromkeys

[Tim Peters]

Reposting because the original got bounced from Google Groups.

-- Forwarded message -
From: Tim Peters 
Date: Fri, Jun 29, 2018 at 5:54 PM
Subject: Re: [Python-ideas] collections.Counter should implement fromkeys
To: 
Cc: python-ideas 


[Abe Dillon ]
> ...
> I'm using the copy-constructor because I know Counter is a subclass of
dict.
> I'm using fromkeys because I know how that class method works.
> So why does the subclass lack functionality that the superclass has?
> Because programmers wouldn't be able to wrap their heads around it?
> I don't buy it. This feels like nanny-design trumping SOLID design
.

More because Counter.fromkeys() could be incoherent.  From the
implementation (in your Lib/collections/__init__.py):

@classmethod
def fromkeys(cls, iterable, v=None):
# There is no equivalent method for counters because setting v=1
# means that no element can have a count greater than one.
raise NotImplementedError(
'Counter.fromkeys() is undefined.  Use Counter(iterable)
instead.')

For a dict, a value appearing multiple times in the iterable doesn't
matter.  But a fundamental use case for Counters is to tally the _number_
of times duplicate keys appear.  So, e.g., someone will be unpleasantly
surprised no matter what:

Counter.fromkeys("a", 2)

returned.  "It should set key 'a' to 2!  that's what I said it should do!"
"No!  It should set key 'a' to 10!  that's what a Counter _always_ does -
sums the values associated with duplicate keys!" "You're both right - and
wrong!  It should raise an exception if there's a duplicate key, because
there's no compelling answer to what it should do!"

I expect Raymond called it NotImplementedError instead so he could release
the code instead of waiting 3 years for that debate to end ;-)
___
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] collections.Counter should implement fromkeys

[Abe Dillon]

[Michael Selik] 

> You need an iterable of the keys you're interested in to pass to the 
> hypothetical ``fromkeys`` method. Why not iterate over that same iterable 
> paired with zeros instead of passing it into ``fromkeys``? 
>

Because, as in my original example code; the values could be zero or they 
could be more, I just want to make sure the keys are in the counter when I 
iterate.
I'm not having any trouble finding a work around. I'm having trouble 
understanding why I need to find a work around when Counter already 
inherits from dict, dict.fromkeys is perfectly well defined, and there's 
not really any other *obvious* best way to initialize the value for a set 
of keys.

Counter(dict.fromkeys(keys, value)) works just fine, but it feels wrong.

I'm using the copy-constructor because I know Counter is a subclass of dict.
I'm using fromkeys because I know how that class method works.
So why does the subclass lack functionality that the superclass has?
Because programmers wouldn't be able to wrap their heads around it?
I don't buy it. This feels like nanny-design trumping SOLID design 
.
___
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

[Michael Selik]

On Fri, Jun 29, 2018 at 2:43 PM Guido van Rossum  wrote:

> On a quick skim I see nothing particularly objectionable or controversial
> in your PEP, except I'm unclear why it needs to be a class method on `dict`.
>

Since it constructs a basic dict, I thought it belongs best as a dict
constructor like dict.fromkeys. It seemed to match other classmethods like
datetime.now.


> Adding something to a builtin like this is rather heavy-handed.
>

I included an alternate solution of a new class, collections.Grouping,
which has some advantages. In addition to having less of that
"heavy-handed" feel to it, the class can have a few utility methods that
help handle more use cases.


> Is there a really good reason why it can't be a function in `itertools`?
> (I don't think that it's relevant that it doesn't return an iterator -- it
> takes in an iterator.)
>

I considered placing it in the itertools module, but decided against
because it doesn't return an iterator. I'm open to that if that's the
consensus.


> Also, your pure-Python implementation appears to be O(N log N) if key is
> None but O(N) otherwise; and the version for key is None uses an extra
> temporary array of size N. Is that intentional?
>

Unintentional. I've been drafting pieces of this over the last year and
wasn't careful enough with proofreading. I'll fix that momentarily...


> Finally, the first example under "Group and Aggregate" is described as a
> dict of sets but it actually returns a dict of (sorted) lists.
>

Doctest complained at the set ordering, so I sorted for printing. You're
not the only one to make that point, so I'll use sets for the example and
ignore doctest.

Thanks for reading!
-- Michael

PS. I just pushed an update to the GitHub repo, as per these comments.



> On Fri, Jun 29, 2018 at 10:54 AM Michael Selik  wrote:
>
>> Hello,
>>
>> 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
>>
>> As a teacher, I've found that grouping is one of the most awkward tasks
>> for beginners to learn in Python. While this proposal requires
>> understanding a key-function, in my experience that's easier to teach than
>> the nuances of setdefault or defaultdict. Defaultdict requires passing a
>> factory function or class, similar to a key-function. Setdefault is
>> awkwardly named and requires a discussion of references and mutability.
>> Those topics are important and should be covered, but I'd like to let them
>> sink in gradually. Grouping often comes up as a question on the first or
>> second day, especially for folks transitioning from Excel.
>>
>> I've tested this proposal on actual students (no students were harmed
>> during experimentation) and found that the majority appreciate it. Some are
>> even able to guess what it does (would do) without any priming.
>>
>> Thanks for your time,
>> -- Michael
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 28, 2018 at 8:38 AM Michael Selik  wrote:
>>
>>> On Thu, Jun 28, 2018 at 8:25 AM Nicolas Rolin 
>>> wrote:
>>>
 I use list and dict comprehension a lot, and a problem I often have is
 to do the equivalent of a group_by operation (to use sql terminology).

 For example if I have a list of tuples (student, school) and I want to
 have the list of students by school the only option I'm left with is to
 write

 student_by_school = defaultdict(list)
 for student, school in student_school_list:
 student_by_school[school].append(student)

>>>
>>> Thank you for bringing this up. I've been drafting a proposal for a
>>> better grouping / group-by operation for a little while. I'm not quite
>>> ready to share it, as I'm still researching use cases.
>>>
>>> I'm +1 that this task needs improvement, but -1 on this particular
>>> solution.
>>>
>>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
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

[Guido van Rossum]

On a quick skim I see nothing particularly objectionable or controversial
in your PEP, except I'm unclear why it needs to be a class method on
`dict`. Adding something to a builtin like this is rather heavy-handed. Is
there a really good reason why it can't be a function in `itertools`? (I
don't think that it's relevant that it doesn't return an iterator -- it
takes in an iterator.)

Also, your pure-Python implementation appears to be O(N log N) if key is
None but O(N) otherwise; and the version for key is None uses an extra
temporary array of size N. Is that intentional?

Finally, the first example under "Group and Aggregate" is described as a
dict of sets but it actually returns a dict of (sorted) lists.

On Fri, Jun 29, 2018 at 10:54 AM Michael Selik  wrote:

> Hello,
>
> 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
>
> As a teacher, I've found that grouping is one of the most awkward tasks
> for beginners to learn in Python. While this proposal requires
> understanding a key-function, in my experience that's easier to teach than
> the nuances of setdefault or defaultdict. Defaultdict requires passing a
> factory function or class, similar to a key-function. Setdefault is
> awkwardly named and requires a discussion of references and mutability.
> Those topics are important and should be covered, but I'd like to let them
> sink in gradually. Grouping often comes up as a question on the first or
> second day, especially for folks transitioning from Excel.
>
> I've tested this proposal on actual students (no students were harmed
> during experimentation) and found that the majority appreciate it. Some are
> even able to guess what it does (would do) without any priming.
>
> Thanks for your time,
> -- Michael
>
>
>
>
>
>
> On Thu, Jun 28, 2018 at 8:38 AM Michael Selik  wrote:
>
>> On Thu, Jun 28, 2018 at 8:25 AM Nicolas Rolin 
>> wrote:
>>
>>> I use list and dict comprehension a lot, and a problem I often have is
>>> to do the equivalent of a group_by operation (to use sql terminology).
>>>
>>> For example if I have a list of tuples (student, school) and I want to
>>> have the list of students by school the only option I'm left with is to
>>> write
>>>
>>> student_by_school = defaultdict(list)
>>> for student, school in student_school_list:
>>> student_by_school[school].append(student)
>>>
>>
>> Thank you for bringing this up. I've been drafting a proposal for a
>> better grouping / group-by operation for a little while. I'm not quite
>> ready to share it, as I'm still researching use cases.
>>
>> I'm +1 that this task needs improvement, but -1 on this particular
>> solution.
>>
>> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
___
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: Allow a group by operation for dict comprehension

[Michael Selik]

I created a separate thread to continue this discussion: "grouping / dict
of lists"

https://github.com/selik/peps/blob/master/pep-.rst

In my proposal, the update offers a key-function in case the new elements
don't follow the same pattern as the existing ones. I can understand the
view that the class should retain the key-function from initialization.

The issue of the group type -- list, set, Counter, etc. -- is handled by
offering a Grouping.aggregate method. The Grouping class creates lists,
which are passed to the aggregate function. I included examples of
constructing sets and Counters.


On Fri, Jun 29, 2018 at 10:04 AM MRAB  wrote:

> On 2018-06-29 05:14, David Mertz wrote:
> >
> > Mike Selik asked for my opinion on a draft PEP along these lines. I
> > proposed a slight modification to his idea that is now reflected in his
> > latest edits. With some details fleshed out, I think this is a promising
> > idea. I like the a collections class better, of course, but a dict
> > classmethod is still a lot smaller change than new syntax change in
> > comprehension.
> >
> > On Thu, Jun 28, 2018, 8:15 PM David Mertz  > > wrote:
> >
> [snip]
> > For example (this typed without testing, forgive any typos or
> thinkos):
> >
> > >>> from collections import Grouper # i.e. in Python 3.8+
> > >>> grouped = Grouper(range(7), key=mod_2)
> > >>> grouped
> > Grouper({0: [0, 2, 4, 6], 1: [1, 3, 5]})
> > >>> grouped.update([2, 10, 12, 13], key=mod_2)
>  > >>> grouped
>  > Grouper({0: [0, 2, 4, 6, 2, 10, 12], 1: [1, 3, 5, 13]})
>  > >>> # Updating with no key function groups by identity
>  > >>> # ... is there a better idea for the default key function?
>  > >>> grouped.update([0, 1, 2])
>  > >>> grouped
>  > Grouper({0: [0, 2, 4, 6, 2, 10, 12, 0], 1: [1, 3, 5, 13, 1], 2:
> [2]})
>
> I think that if a Grouper instance is created with a key function, then
> that key function should be used by the .update method.
>
> You _could_ possibly override that key function by providing a new one
> when updating, but, OTOH, why would you want to? You'd be mixing
> different kinds of groupings! So -1 on that.
>
> > >>> # Maybe do a different style of update if passed a dict subclass
> > >>> #  - Does a key function make sense here?
> > >>> grouped.update({0: 88, 1: 77})
> > >>> grouped
> > Grouper({0: [0, 2, 4, 6, 2, 10, 12, 0, 88],
> > 1: [1, 3, 5, 13, 1, 77],
> > 2: [2]})
> > >>> # Avoiding duplicates might sometimes be useful
> > >>> grouped.make_unique()   # better name?  .no_dup()?
> > >>> grouped
> > Grouper({0: [0, 2, 4, 6, 10, 12, 88],
> > 1: [1, 3, 5, 13, 77],
> > 2: [2]})
> >
> If you want to avoid duplicates, maybe the grouper should be created
> with 'set' as the default factory (see 'defaultdict'). However, there's
> the problem that 'list' has .append but 'set' has .add...
> > I think that most of the methods of Counter make sense to include
> > here in appropriately adjusted versions. Converting to a plain
> > dictionary should probably just be `dict(grouped)`, but it's
> > possible we'd want `grouped.as_dict()` or something.
> >
> > One thing that *might* be useful is a way to keep using the same key
> > function across updates. Even with no explicit provision, we *could*
> > spell it like this:
> >
> > >>> grouped.key_func = mod_2
> > >>> grouped.update([55, 44, 22, 111], key=grouped.key_func)
> >
> > Perhaps some more official API for doing that would be useful though.
> >
> [snip]
> ___
> 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] grouping / dict of lists

[Michael Selik]

Hello,

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

As a teacher, I've found that grouping is one of the most awkward tasks for
beginners to learn in Python. While this proposal requires understanding a
key-function, in my experience that's easier to teach than the nuances of
setdefault or defaultdict. Defaultdict requires passing a factory function
or class, similar to a key-function. Setdefault is awkwardly named and
requires a discussion of references and mutability. Those topics are
important and should be covered, but I'd like to let them sink in
gradually. Grouping often comes up as a question on the first or second
day, especially for folks transitioning from Excel.

I've tested this proposal on actual students (no students were harmed
during experimentation) and found that the majority appreciate it. Some are
even able to guess what it does (would do) without any priming.

Thanks for your time,
-- Michael






On Thu, Jun 28, 2018 at 8:38 AM Michael Selik  wrote:

> On Thu, Jun 28, 2018 at 8:25 AM Nicolas Rolin 
> wrote:
>
>> I use list and dict comprehension a lot, and a problem I often have is to
>> do the equivalent of a group_by operation (to use sql terminology).
>>
>> For example if I have a list of tuples (student, school) and I want to
>> have the list of students by school the only option I'm left with is to
>> write
>>
>> student_by_school = defaultdict(list)
>> for student, school in student_school_list:
>> student_by_school[school].append(student)
>>
>
> Thank you for bringing this up. I've been drafting a proposal for a better
> grouping / group-by operation for a little while. I'm not quite ready to
> share it, as I'm still researching use cases.
>
> I'm +1 that this task needs improvement, but -1 on this particular
> solution.
>
>
___
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: Allow a group by operation for dict comprehension

[MRAB]

On 2018-06-29 05:14, David Mertz wrote:


Mike Selik asked for my opinion on a draft PEP along these lines. I 
proposed a slight modification to his idea that is now reflected in his 
latest edits. With some details fleshed out, I think this is a promising 
idea. I like the a collections class better, of course, but a dict 
classmethod is still a lot smaller change than new syntax change in 
comprehension.


On Thu, Jun 28, 2018, 8:15 PM David Mertz > wrote:



[snip]

For example (this typed without testing, forgive any typos or thinkos):

>>> from collections import Grouper # i.e. in Python 3.8+
>>> grouped = Grouper(range(7), key=mod_2)
>>> grouped
Grouper({0: [0, 2, 4, 6], 1: [1, 3, 5]})
>>> grouped.update([2, 10, 12, 13], key=mod_2)

> >>> grouped
> Grouper({0: [0, 2, 4, 6, 2, 10, 12], 1: [1, 3, 5, 13]})
> >>> # Updating with no key function groups by identity
> >>> # ... is there a better idea for the default key function?
> >>> grouped.update([0, 1, 2])
> >>> grouped
> Grouper({0: [0, 2, 4, 6, 2, 10, 12, 0], 1: [1, 3, 5, 13, 1], 2: [2]})

I think that if a Grouper instance is created with a key function, then 
that key function should be used by the .update method.


You _could_ possibly override that key function by providing a new one 
when updating, but, OTOH, why would you want to? You'd be mixing 
different kinds of groupings! So -1 on that.



>>> # Maybe do a different style of update if passed a dict subclass
>>> #  - Does a key function make sense here?
>>> grouped.update({0: 88, 1: 77})
>>> grouped
Grouper({0: [0, 2, 4, 6, 2, 10, 12, 0, 88],
1: [1, 3, 5, 13, 1, 77],
2: [2]})
>>> # Avoiding duplicates might sometimes be useful
>>> grouped.make_unique()   # better name?  .no_dup()?
>>> grouped
Grouper({0: [0, 2, 4, 6, 10, 12, 88],
1: [1, 3, 5, 13, 77],
2: [2]})

If you want to avoid duplicates, maybe the grouper should be created 
with 'set' as the default factory (see 'defaultdict'). However, there's 
the problem that 'list' has .append but 'set' has .add...

I think that most of the methods of Counter make sense to include
here in appropriately adjusted versions. Converting to a plain
dictionary should probably just be `dict(grouped)`, but it's
possible we'd want `grouped.as_dict()` or something.

One thing that *might* be useful is a way to keep using the same key
function across updates. Even with no explicit provision, we *could*
spell it like this:

>>> grouped.key_func = mod_2
>>> grouped.update([55, 44, 22, 111], key=grouped.key_func)

Perhaps some more official API for doing that would be useful though.


[snip]
___
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

[Nathan Goldbaum]

On Thu, Jun 28, 2018 at 11:26 PM, Alex Walters 
wrote:

> But don't all the users who care about citing modules already use the
> scientific python packages, with scipy itself at it's center?  Wouldn't
> those engaging in science or in academia be better stewards of this than
> systems programmers?  Since you're not asking for anything that can't be
> done in a third party module, and there is a third party module that most
> of the target audience of this standard would already have, there is zero
> reason to take up four names in the python runtime to serve those users.
>


Not all scientific software in Python depends on scipy or even numpy.
However, it does all depend on Python.

Although perhaps that argues for a cross-language solution :)

I still think it would be very nice to have an official standard for
citation information in Python packages as codified in a PEP. That would
reduce ambiguity and make it much easier for tool-writers who want to parse
citation information.

> -Original Message-
> > From: Adrian Price-Whelan 
> > Sent: Friday, June 29, 2018 12:16 AM
> > To: Alex Walters 
> > Cc: Steven D'Aprano ; python-ideas@python.org
> > Subject: Re: [Python-ideas] Add a __cite__ method for scientific packages
> >
> > For me, it's about setting a standard that is endorsed by the
> > language, and setting expectations for users. There currently is no
> > standard, which is why packages use __citation__, __cite__,
> > __bibtex__, etc., and as a user I don't immediately know where to look
> > for citation information (without going to the source). My feeling is
> > that adopting __citation__ or some dunder name could be implemented on
> > classes, functions, etc. with less of a chance of naming conflicts,
> > but am open to discussion.
> >
> > I have some notes here about various ideas for more advanced
> > functionality that would support automatically keeping track of
> > citation information for imported packages, classes, functions:
> > https://github.com/adrn/CitationPEP/blob/master/NOTES.md
> >
> > On Thu, Jun 28, 2018 at 10:57 PM, Alex Walters 
> > wrote:
> > > Why not scipy.cite() or scipy.citation()?  I don't see any reason for
> these
> > > functions to ship with standard python at all.
> > >
> > >> -Original Message-
> > >> From: Python-ideas  > >> list=sdamon@python.org> On Behalf Of Steven D'Aprano
> > >> Sent: Thursday, June 28, 2018 8:17 PM
> > >> To: python-ideas@python.org
> > >> Subject: Re: [Python-ideas] Add a __cite__ method for scientific
> packages
> > >>
> > >> On Thu, Jun 28, 2018 at 05:25:00PM -0400, Andrei Kucharavy wrote:
> > >>
> > >> > As for the list, reserving a __citation__/__cite__ for packages at
> the
> > > same
> > >> > level as __version__ is now reserved and adding a citation()/cite()
> > >> > function to the standard library seemed large enough modifications
> to
> > >> > warrant searching a buy-in from the maintainers and the community at
> > >> large.
> > >>
> > >> I think that an approach similar to help/quit/exit is warranted. The
> > >> cite()/citation() function need not be *literally* built into the
> > >> language, it could be an external function written in Python and added
> > >> to builtins by the site.py module.
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Steve
> > >> ___
> > >> 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/
> >
> >
> >
> > --
> > Adrian M. Price-Whelan
> > Lyman Spitzer, Jr. Postdoctoral Fellow
> > Princeton University
> > http://adrn.github.io
>
> ___
> 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] list configuration

[Brett Cannon]

And I've taken owners off because I don't know how to solve this short of
removing Google Groups somehow or getting off of email and switching to
Zulip or Discourse. If someone has a solution that doesn't require dropping
email then let me know.

On Fri, Jun 29, 2018, 04:17 Stephen J. Turnbull, <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> I've cc'd python-ideas-owner, the folks who can actually do something
> about it.
>
> Chris Barker via Python-ideas writes:
>
>  > I've been replying to messages lately, and getting a bounce back:
> [...]
>  > And it's not quite clar to me if the message actually got through.
>
> In my experience it does, because when this happens to me it's due to
> my reply-all inserting both python.org and googlegroups addresses in
> the To and Cc fields.
>
>  > IIUC, this is a Mailman list -- so it must be getting mirrored
>  > through google groups, and at least with some people's posts, the
>  > reply-to header is getting messed up.
>  >
>  > Anyone know what's going on?
>
> I'm not sure about the process in your case.  What I've experienced is
> that there are a couple of people who use googlegroups to read, and
> when they post for some reason both the python.org and the
> googlegroups addresses end up as addressees.  This might be Google
> trying to monopolize mailing lists by putting the googlegroups address
> in Reply-To, or it might be a poster error of using reply-all and not
> cleaning out the googlegroups address (which doesn't bother them
> because they're subscribed at googlegroups and googlegroups
> deduplicates).
>
> For historical reasons I use reply-all, so both addresses end up in
> the addressees, and it bounces from googlegroups if I don't clean it
> up.
>
>  > It would be nice to fix this...
>
> My personal approach would be to blackhole posts containing
> googlegroups addresses in any header field, but that probably won't
> fly. ;-)
>
> I think it's probably not that hard to add some code to some handler
> in Mailman's pipeline to strip out googlegroups addresses from the
> list of addressees in outgoing posts, and if that makes googlegroups
> unreliable, so be it.  It shouldn't, though, because the googlegroup
> is subscribed to the list at python.org.
>
> I don't see why this shouldn't be done globally for all lists at
> python.org, for all googlegroups addresses.  AFAIK there are no
> non-list mailboxes at googlegroups that would want to receive mail
> there.
>
> Steve
>
> ___
> 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] Allow a group by operation for dict comprehension

[Nicolas Rolin]

A syntax that would work (which atm is a syntax error, and requires no new
keyword) would be

student_by_school = {school: [student] for school, student in
student_school_list, grouped=True}

with grouped=True being a modifier on the dict comprehension so that at
each iteration loop

current_dict[key] = value if key not in current_dict else current_dict[key]
+ value

This is an extremely borderline syntax (as it is perfectly legal to put
**{'grouped': True} in a dict comprehension), but it works.
It even keeps the extremely important "should look like a template of the
final object" property.

But it doesn't requires me to defines 2 lambda functions just to do the job
of a comprehension.

-- 
Nicolas Rolin


2018-06-29 4:57 GMT+02:00 Michael Selik :

> On Thu, Jun 28, 2018, 6:46 PM Nicolas Rolin 
> wrote:
>
>> The questions I should have asked In my original post was :
>> - Is splitting lists into sublists (by grouping elements) a high level
>> enough construction to be worthy of a nice integration in the comprehension
>> syntax ?
>>
>
> My intuition is no, it's not important enough to alter the syntax, despite
> being an important task.
>
> - In which case, is there a way to find a simple syntax that is not too
>> confusing ?
>>
>
> If you'd like to give it a shot, try to find something which is currently
> invalid syntax, but does not break compatibility. The latter criteria means
> no new keywords. The syntax should look nice as a single line with
> reasonably verbose variable names.
>
> One issue is that Python code is mostly 1-dimensional, characters in a
> line, and you're trying to express something which is 2-dimensional, in a
> sense. There's only so much you can do without newlines and indentation.
>



-- 

--
*Nicolas Rolin* | Data Scientist
+ 33 631992617 - nicolas.ro...@tiime.fr 


*15 rue Auber, **75009 Paris*
*www.tiime.fr *
___
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] list configuration

[Stephen J. Turnbull]

I've cc'd python-ideas-owner, the folks who can actually do something
about it.

Chris Barker via Python-ideas writes:

 > I've been replying to messages lately, and getting a bounce back:
[...]
 > And it's not quite clar to me if the message actually got through.

In my experience it does, because when this happens to me it's due to
my reply-all inserting both python.org and googlegroups addresses in
the To and Cc fields.

 > IIUC, this is a Mailman list -- so it must be getting mirrored
 > through google groups, and at least with some people's posts, the
 > reply-to header is getting messed up.
 > 
 > Anyone know what's going on?

I'm not sure about the process in your case.  What I've experienced is
that there are a couple of people who use googlegroups to read, and
when they post for some reason both the python.org and the
googlegroups addresses end up as addressees.  This might be Google
trying to monopolize mailing lists by putting the googlegroups address
in Reply-To, or it might be a poster error of using reply-all and not
cleaning out the googlegroups address (which doesn't bother them
because they're subscribed at googlegroups and googlegroups
deduplicates).

For historical reasons I use reply-all, so both addresses end up in
the addressees, and it bounces from googlegroups if I don't clean it
up.

 > It would be nice to fix this...

My personal approach would be to blackhole posts containing
googlegroups addresses in any header field, but that probably won't
fly. ;-)

I think it's probably not that hard to add some code to some handler
in Mailman's pipeline to strip out googlegroups addresses from the
list of addressees in outgoing posts, and if that makes googlegroups
unreliable, so be it.  It shouldn't, though, because the googlegroup
is subscribed to the list at python.org.

I don't see why this shouldn't be done globally for all lists at
python.org, for all googlegroups addresses.  AFAIK there are no
non-list mailboxes at googlegroups that would want to receive mail
there.

Steve

___
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] list configuration

[Jacco van Dorp]

I've had it to, bounces when attempting to reply or reply all, and it
tried to send to some google groups version.

2018-06-28 19:31 GMT+02:00 Eric Fahlgren :
> I've been getting those, too, but from the wxPython-dev group.  I concur
> that they look like googlegroups bounces (although I can't confirm that as
> I've been deleting them without much inspection).
>
> On Thu, Jun 28, 2018 at 9:35 AM Chris Barker via Python-ideas
>  wrote:
>>
>> Hey all,
>>
>> I've been replying to messages lately, and getting a bounce back:
>>
>> """
>> Hello chris.bar...@noaa.gov,
>>
>> We're writing to let you know that the group you tried to contact
>> (python-ideas) may not exist, or you may not have permission to post
>> messages to the group. A few more details on why you weren't able to post:
>> """
>>
>> And it's not quite clar to me if the message actually got through.
>>
>> IIUC, this is a Mailman list -- so it must be getting mirrored through
>> google groups, and at least with some people's posts, the reply-to header is
>> getting messed up.
>>
>> Anyone know what's going on? It would be nice to fix this...
>>
>> -CHB
>>
>> PS: I've seen a couple other notes about this -- I'm not the only one.
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> 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 mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/