Re: [Python-Dev] GitHub mirror (Was: Bitbucket mirror?)
anatoly techtonik wrote: On the subject. Is there a mirror of CPython on GitHub? https://github.com/akheron/cpython changes to repository (and allows anonymous to do this). I've made more than a dozen proposal for fixing docs, because as a matter of fact - filling a bug AND explaining why docs are wrong, why they need to be fixed, what should be added - all of this is a way *much easier* (and less time consuming!) than just fixing them. Unfortunately. You won't get any changes in to CPython by creating pull requests. We use http://bugs.python.org/ for that, sorry. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)
Before anything else I must apologize for significant lags in my
replies. I can not read all of them to hold in my head, so I reply one
by one as it goes trying not to miss a single point out there. It
would be much easier to do this in unified interface for threaded
discussions, but for now there is no capabilities for that neither in
Mailman nor in GMail. And when it turns out that the amount of text is
too big, and I spend a lot of time trying to squeeze it down and then
it becomes pointless to send at all.
Now back on the topic:
On Sun, Jul 1, 2012 at 12:09 AM, Terry Reedy tjre...@udel.edu wrote:
On 6/29/2012 4:32 PM, Georg Brandl wrote:
On 26.06.2012 10:03, anatoly techtonik wrote:
Now that Python 3 is all about iterators (which is a user killer
feature for Python according to StackOverflow -
http://stackoverflow.com/questions/tagged/python) would it be nice to
introduce more first class functions to work with them? One function
to be exact to split string into chunks.
Nothing special about strings.
It seemed so, but it just appeared that grouper recipe didn't work for me.
itertools.chunks(iterable, size, fill=None)
This is a renaming of itertools.grouper in 9.1.2. Itertools Recipes. You
should have mentioned this. I think of 'blocks' rather than 'chunks', but I
notice several SO questions with 'chunk(s)' in the title.
I guess `block` gives too low signal/noize ration in search results.
That's why it probably also called chunks in other languages, where
`block` stand for something else (I speak of Ruby blocks).
Which is the 33th most voted Python question on SO -
http://stackoverflow.com/questions/312443/how-do-you-split-a-list-into-evenly-sized-chunks-in-python/312464
I am curious how you get that number. I do note that there are about 15
other Python SO questions that seem to be variations on the theme. There
might be more if 'blocks' and 'groups' were searched for.
It's easy:
1. Go http://stackoverflow.com/
2. Search [python]
3. Click `votes` tab
4. Choose `30 per page` at the bottom
5. Jump to the second page, there it is 4th from the top:
http://stackoverflow.com/questions/tagged/python?page=2sort=votespagesize=30
As for duplicates - feel free to mark them as such. SO allows
everybody to do this (unlike Roundup).
Anatoly, so far there were no negative votes -- would you care to go
another step and propose a patch?
That is because Raymond H. is not reading either list right now ;-)
Hence the Cc:. Also because I did not yet respond to a vague, very
incomplete idea.
From Raymond's first message on http://bugs.python.org/issue6021 , add
grouper:
This has been rejected before.
I quite often see such arguments and I can't stand to repeat that
these are not arguments. It is good to know, but when people use that
as a reason to close tickets - that's just disgusting. To the
Raymond's honor he cares to explain.
* It is not a fundamental itertool primitive. The recipes section in
the docs shows a clean, fast implementation derived from zip_longest().
What is the definition of 'fundamental primitive'?
To me the fact that top answer for chunking strings on SO has 2+ times
more votes than itertools versions is a clear 5 sigma indicator that
something is wrong with this Standard model without chunks boson.
* There is some debate on a correct API for odd lengths. Some people
want an exception, some want fill-in values, some want truncation, and
some want a partially filled-in tuple. The alone is reason enough not
to set one behavior in stone.
use case 3.1: odd lengths exception (CHOOSE ONE)
1. I see that no itertools function throws exceptions, check manually:
len(iterable) / float(size) == len(iterable) // float(size)
2. Explicitly
- itertools.chunks(iterable, size, fill=None)
+ itertools.chunks(iterable, size, fill=None, exception=False)
use case 3.2. fill in value. it is here (SOLVED)
use case 3.3: truncation
no itertools support truncation, do manually
chunks(iter, size)[:len(iter)//size)
use case 4: partially filled-in tuple
What should be there?
chunks('ABCDEFG', 3, 'x')
|
More replies and workarounds to some of the raised points are below.
* There is an issue with having too many itertools. The module taken as
a whole becomes more difficult to use as new tools are added.
There can be only two reasons to that:
* chosen basis is bad (many functions that are rarely used or easily emulated)
* basis is good, but insufficient, because iterators universe is more
complicated
than we think
This is not to say that the question should not be re-considered. Given the
StackOverflow experience in addition to that of the tracker and python-list
(and maybe python-ideas), a special exception might be made in relation to
points 1 and 3.
--[offtopic about Python enhancements / proposals feedback]--
Yes, without SO I probably wouldn't trigger this at all. Because
tracker doesn't help with raising importance - there are
Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)
On Sun, Jul 1, 2012 at 3:01 PM, Stefan Behnel stefan...@behnel.de wrote: To address the main problem of users not finding what they need, what about simply extending the docstring of the grouper() function with a sentence like this: This functionality is also called 'chunking' or 'blocking' and can be used for load distribution and sharding. That would make it easy for users to find what they are looking for when they search the page for chunk. I find that a much more common and less ambiguous name than grouping, which reminds me more of group by. In appeared that chunking and grouping are different kind of tasks. You can chunk a sequence (sting) by slicing it into smaller sequences, but you can not chunk in iterable - you can only group it. There is an data loss about the structure that occurs when a sequence (string) becomes an iterator: chunks ABCDE - AB CD E group ABCDE - A B C D E - (A B) (C D) (D E) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)
On Jul 05, 2012, at 04:36 PM, anatoly techtonik wrote: It would be much easier to do this in unified interface for threaded discussions, but for now there is no capabilities for that neither in Mailman nor in GMail. You might like to read the mailing lists via NNTP on Gmane. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)
On Wed, Jul 4, 2012 at 9:31 PM, Terry Reedy tjre...@udel.edu wrote:
On 7/4/2012 5:57 AM, anatoly techtonik wrote:
On Fri, Jun 29, 2012 at 11:32 PM, Georg Brandl g.bra...@gmx.net wrote:
Anatoly, so far there were no negative votes -- would you care to go
another step and propose a patch?
Was about to say no problem,
Did you read that there *are* strong negative votes? And that this idea has
been rejected before? I summarized the objections in my two responses and
pointed to the tracker issues. One of the objections is that there are 4
different things one might want if the sequence length is not an even
multiple of the chunk size. Your original 'idea' did not specify.
I actually meant that there is a problem to propose a patch in the
sense of getting checkout, working on a diff, sending it by attaching
to bug tracker as developer guide says.
For now the best thing I can do (I don't risk even to mention anything
with 3.3) is to copy/paste code from the docs here:
from itertools import izip_longest
def chunks(iterable, size, fill=None):
Split an iterable into blocks of fixed-length
# chunks('ABCDEFG', 3, 'x') -- ABC DEF Gxx
args = [iter(iterable)] * size
return izip_longest(fillvalue=fill, *args)
Python ideas is about Python 3 ideas. Please post Python 3 code.
This is actually a one liner
return zip_longest(*[iter(iterable)]*size, fillvalue=file)
We don't generally add such to the stdlib.
Can you figure out from the code what this stuff does?
It doesn't give chunks of strings.
BTW, this doesn't work as expected (at least for strings). Expected is:
chunks('ABCDEFG', 3, 'x') -- 'ABC' 'DEF' 'Gxx'
got:
chunks('ABCDEFG', 3, 'x') -- ('A' 'B' 'C') ('D' 'E' 'F') ('G' 'x' 'x')
One of the problems with idea of 'add a chunker' is that there are at least
a dozen variants that different people want.
That's not the problem. People always want something extra. The
problem that we don't have a real wish distribution. If 1000 people
want chunks and 1 wants groups with exception - we still account these
as equal variants.
Therefore my idea is deliberately limited to string to chunks user
story, and SO implementation proposal.
I discussed the problem of
return types issue in my responses. I showed how to get the 'expected'
response above using grouper, but also suggested that it is the wrong basis
for splitting strings. Repeated slicing make more sense for concrete
sequence types.
def seqchunk_odd(s, size):
# include odd size left over
for i in range(0, len(s), size):
yield s[i:i+size]
print(list(seqchunk_odd('ABCDEFG', 3)))
#
['ABC', 'DEF', 'G']
Right. That's the top answer on SO that people think should be in
stdlib. Great we are talking about the same thing actually.
def seqchunk_even(s, size):
# only include even chunks
for i in range(0, size*(len(s)//size), size):
yield s[i:i+size]
print(list(seqchunk_even('ABCDEFG', 3)))
#
['ABC', 'DEF']
This is deducible from seqchunk_odd(s, size)
def strchunk_fill(s, size, fill):
# fill odd chunks
q, r = divmod(len(s), size)
even = size * q
for i in range(0, even, size):
yield s[i:i+size]
if size != even:
yield s[even:] + fill * (size - r)
print(list(strchunk_fill('ABCDEFG', 3, 'x')))
#
['ABC', 'DEF', 'Gxx']
Also deducible from seqchunk_odd(s, size)
Because the 'fill' value is necessarily a sequence for strings,
strchunk_fill would only work for lists and tuples if the fill value were
either required to be given as a tuple or list of length 1 or if it were
internally converted inside the function. Skipping that for now.
Having written the fill version based on the even version, it is easy to
select among the three behaviors by modifying the fill version.
def strchunk(s, size, fill=NotImplemented):
# fill odd chunks
q, r = divmod(len(s), size)
even = size * q
for i in range(0, even, size):
yield s[i:i+size]
if size != even and fill is not NotImplemented:
yield s[even:] + fill * (size - r)
print(*strchunk('ABCDEFG', 3))
print(*strchunk('ABCDEFG', 3, ''))
print(*strchunk('ABCDEFG', 3, 'x'))
#
ABC DEF
ABC DEF G
ABC DEF Gxx
I now don't even think that fill value is needed as argument.
if len(chunk) size:
chunk.extend( [fill] * ( size - len(chunk)) )
I already described how something similar could be done by checking each
grouper output tuple for a fill value, but that requires that the fill value
be a sentinal that could not otherwise appear in the tuple. One could modify
grouper to fill with a private object() and check the last item of each
group for that sentinal and act accordingly (delete, truncate, or replace).
A generic api needs some thought, though.
I just need to chunk strings and sequences. Generic API is too complex
without counting all usecases and iterating over them.
An issue I did not previously mention is that people
Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)
anatoly techtonik wrote: On Wed, Jul 4, 2012 at 9:31 PM, Terry Reedy tjre...@udel.edu wrote: A sliding window for a generic iterable requires a deque or ring buffer approach that is quite different from the zip-longest -- grouper approach. That's why I'd like to drastically reduce the scope of proposal. itertools doesn't seem to be the best place anymore. How about sequence method? string.chunks(size) - ABC DEF G list.chunks(size) - [A,B,C], [C,D,E],[G] -1 This is a fairly trivial problem to solve, and there are many variations on it. Many people will not find the default behaviour helpful, and will need to write their own. Why complicate the API for all sequence types with this? I don't believe that we should enshrine one variation as a built-in method, without any evidence that it is the most useful or common variation. Even if there is one variation far more useful than the others, that doesn't necessarily mean we ought to make it a builtin method unless it is a fundamental sequence operation, has wide applicability, and is genuinely hard to write. I don't believe chunking meets *any* of those criteria, let alone all three. Not every six line function needs to be a builtin. I believe that splitting a sequence (or a string) into fixed-size chunks is more of a programming exercise problem than a genuinely useful tool. That does not mean that there is never any real use-cases for splitting into fixed-size chunks, only that this is the function that *seems* more useful in theory than it turns out in practice. Compare this with more useful sequence/iteration tools, like (say) zip. You can hardly write a hundred lines of code without using zip at least once. But I bet you can write tens of thousands of lines of code without needing to split sequences into fixed chunks like this. Besides, the name chunks is more general than how you are using it. For example, I consider chunking to be splitting a sequence up at a various delimiters or separators, not at fixed character positions. E.g. the third word of item two of the fourth line is a chunk. This fits more with the non-programming use of the term chunk or chunking, and has precedence in Apple's Hypertalk language, which literally allowed you to talk about words, items and lines of text, each of which are described as chunks. This might be a good candidate for a utility module made up of assorted useful functions, but not for the string and sequence APIs. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GitHub mirror (Was: Bitbucket mirror?)
On Thu, Jul 05, 2012 at 03:49:52PM +0300, Petri Lehtinen wrote: anatoly techtonik wrote: On the subject. Is there a mirror of CPython on GitHub? https://github.com/akheron/cpython changes to repository (and allows anonymous to do this). I've made more than a dozen proposal for fixing docs, because as a matter of fact - filling a bug AND explaining why docs are wrong, why they need to be fixed, what should be added - all of this is a way *much easier* (and less time consuming!) than just fixing them. Unfortunately. You won't get any changes in to CPython by creating pull requests. We use http://bugs.python.org/ for that, sorry. Question -- is there a reason to abide by this rule for docs? That is, if we could get a sympathetic core dev to look at pull requests for docs as part of a streamlined process, would it cause problems? (What I'm really asking is whether or the bugs.python.org process is considered critical for potentially minor doc changes and additions.) thanks, --titus -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)
anatoly techtonik wrote: Which is the 33th most voted Python question on SO - http://stackoverflow.com/questions/312443/how-do-you-split-a-list-into-evenly-sized-chunks-in-python/312464 I am curious how you get that number. I do note that there are about 15 other Python SO questions that seem to be variations on the theme. There might be more if 'blocks' and 'groups' were searched for. It's easy: 1. Go http://stackoverflow.com/ 2. Search [python] 3. Click `votes` tab 4. Choose `30 per page` at the bottom 5. Jump to the second page, there it is 4th from the top: http://stackoverflow.com/questions/tagged/python?page=2sort=votespagesize=30 Yes. I don't think this is particularly significant. Have a look at some of the questions with roughly the same number of votes: #26 How can I remove (chomp) a newline in Python? 176 votes #33 How do you split a list into evenly sized chunks in Python? 149 votes #36 Accessing the index in Python for loops 144 votes Being 33rd most voted question doesn't really mean much. By the way, why is this discussion going to both python-dev and python-ideas? -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)
anatoly techtonik, 05.07.2012 15:36: On Sun, Jul 1, 2012 at 12:09 AM, Terry Reedy wrote: From Raymond's first message on http://bugs.python.org/issue6021 , add grouper: This has been rejected before. I quite often see such arguments and I can't stand to repeat that these are not arguments. It is good to know, but when people use that as a reason to close tickets - that's just disgusting. The *real* problem is that people keep bringing up topics (and even spell them out in the bug tracker) without searching for existing discussions and/or tickets first. That's why those who do such a search (or who know what they are talking about anyway) close these tickets with the remark this has been rejected before, instead of repeating an entire heap of arguments all over again to feed a discussion that would only lead to the same result as it did before, often several times before. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GitHub mirror (Was: Bitbucket mirror?)
You won't get any changes in to CPython by creating pull requests. We use http://bugs.python.org/ for that, sorry. Question -- is there a reason to abide by this rule for docs? That is, if we could get a sympathetic core dev to look at pull requests for docs as part of a streamlined process, would it cause problems? How do you communicate a pull request? On bitbucket, there is a pull request UI resulting in a tracker item being generated (and an email being sent), but hg.python.org doesn't have a notion of pull requests. Of course, you could use any communication means (email, telephone call, carrier pigeon) to request a pull from a sympathetic core dev. (What I'm really asking is whether or the bugs.python.org process is considered critical for potentially minor doc changes and additions.) The sympathetic core dev is mostly free to bypass any submission process initially; commits that bypass established procedures will likely be questioned only after the fact. In the specific case, I'd be worried to verify that the submitter has provided a contributor form. That's easy to do in the bug tracker, but difficult to do in an offline pull request. Of course, for a really minor doc change (e.g. typo fixes), no contrib form is necessary. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bloody FAQ (Was: [Python-ideas] itertools.chunks(iterable, size, fill=None))
On Thu, Jul 5, 2012 at 7:50 PM, Stefan Behnel stefan...@behnel.de wrote: anatoly techtonik, 05.07.2012 15:36: On Sun, Jul 1, 2012 at 12:09 AM, Terry Reedy wrote: From Raymond's first message on http://bugs.python.org/issue6021 , add grouper: This has been rejected before. I quite often see such arguments and I can't stand to repeat that these are not arguments. It is good to know, but when people use that as a reason to close tickets - that's just disgusting. The *real* problem is that people keep bringing up topics (and even spell them out in the bug tracker) without searching for existing discussions and/or tickets first. That's why those who do such a search (or who know what they are talking about anyway) close these tickets with the remark this has been rejected before, instead of repeating an entire heap of arguments all over again to feed a discussion that would only lead to the same result as it did before, often several times before. Make the bloody FAQ and summarize this stuff? Why waste each others time? If people don't enjoy repeating themselves over and over - there is a bloody wiki. What should happen to people to start extracting gems of knowledge from piles of dusty sheets called list archives for others to admire. No, it is easier to say it was already discussed many times, why don't you Google yourself, so far you're only complaining, etc. If people can't find anything - why everybody thinks they are ignorant and lazy. Even if it so, why nobody thinks that maybe that bloody Xapian index is dead again for a bloody amount of moons nobody knows why and how many exactly? Why nobody thinks that lazy coders can also help with development? Maybe that laziness is the primary reason some major groups actually prefer Python to Java, C++ and other more interesting languages (such as PHP) when it comes to typing? Make it easy and the patches will follow. Answers like this was discussed before don't make it easy to understand, and leaving users rereading old 19xx archives that people don't reread themselves will likely make users bounce and never (NEVER!) come up with some proposal again. An organic way to keep traffic low. Miscommunication is a bad experience for users, bad experience for developers, everybody is annoyed and as a result such nice language as Python loses points on TIOBE (and convenient chunk() functions to munch-munch on the sequence data). Wheew. :-F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bloody FAQ (Was: [Python-ideas] itertools.chunks(iterable, size, fill=None))
On 05/07/2012 20:41, anatoly techtonik wrote: On Thu, Jul 5, 2012 at 7:50 PM, Stefan Behnel stefan...@behnel.de wrote: anatoly techtonik, 05.07.2012 15:36: On Sun, Jul 1, 2012 at 12:09 AM, Terry Reedy wrote: From Raymond's first message on http://bugs.python.org/issue6021 , add grouper: This has been rejected before. I quite often see such arguments and I can't stand to repeat that these are not arguments. It is good to know, but when people use that as a reason to close tickets - that's just disgusting. The *real* problem is that people keep bringing up topics (and even spell them out in the bug tracker) without searching for existing discussions and/or tickets first. That's why those who do such a search (or who know what they are talking about anyway) close these tickets with the remark this has been rejected before, instead of repeating an entire heap of arguments all over again to feed a discussion that would only lead to the same result as it did before, often several times before. Make the bloody FAQ and summarize this stuff? Why waste each others time? If people don't enjoy repeating themselves over and over - there is a bloody wiki. What should happen to people to start extracting gems of knowledge from piles of dusty sheets called list archives for others to admire. No, it is easier to say it was already discussed many times, why don't you Google yourself, so far you're only complaining, etc. If people can't find anything - why everybody thinks they are ignorant and lazy. Even if it so, why nobody thinks that maybe that bloody Xapian index is dead again for a bloody amount of moons nobody knows why and how many exactly? Why nobody thinks that lazy coders can also help with development? Maybe that laziness is the primary reason some major groups actually prefer Python to Java, C++ and other more interesting languages (such as PHP) when it comes to typing? Make it easy and the patches will follow. Answers like this was discussed before don't make it easy to understand, and leaving users rereading old 19xx archives that people don't reread themselves will likely make users bounce and never (NEVER!) come up with some proposal again. An organic way to keep traffic low. Miscommunication is a bad experience for users, bad experience for developers, everybody is annoyed and as a result such nice language as Python loses points on TIOBE (and convenient chunk() functions to munch-munch on the sequence data). Wheew. :-F Can I safely assume that you are volunteering to do the work required? -- Cheers. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bloody FAQ (Was: [Python-ideas] itertools.chunks(iterable, size, fill=None))
anatoly techtonik, 05.07.2012 21:41: On Thu, Jul 5, 2012 at 7:50 PM, Stefan Behnel wrote: anatoly techtonik, 05.07.2012 15:36: On Sun, Jul 1, 2012 at 12:09 AM, Terry Reedy wrote: From Raymond's first message on http://bugs.python.org/issue6021 , add grouper: This has been rejected before. I quite often see such arguments and I can't stand to repeat that these are not arguments. It is good to know, but when people use that as a reason to close tickets - that's just disgusting. The *real* problem is that people keep bringing up topics (and even spell them out in the bug tracker) without searching for existing discussions and/or tickets first. That's why those who do such a search (or who know what they are talking about anyway) close these tickets with the remark this has been rejected before, instead of repeating an entire heap of arguments all over again to feed a discussion that would only lead to the same result as it did before, often several times before. Make the bloody FAQ and summarize this stuff? Why waste each others time? Yes, that is exactly the question. It takes time to write things up nicely. I mean, once someone has pointed out to you that this has been discussed before, you could just go, look it up (or search for it), and then put it into a Wiki or blog post yourself, or sum it up and send it to the mailing list as a reply. Why rely on others to do it for you? Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bloody FAQ (Was: [Python-ideas] itertools.chunks(iterable, size, fill=None))
Stefan Behnel wrote: anatoly techtonik, 05.07.2012 21:41: Make the bloody FAQ and summarize this stuff? Why waste each others time? Yes, that is exactly the question. It takes time to write things up nicely. I mean, once someone has pointed out to you that this has been discussed before, you could just go, look it up (or search for it), and then put it into a Wiki or blog post yourself, or sum it up and send it to the mailing list as a reply. Why rely on others to do it for you? To be fair, Anatoly has done quite a bit of maintenance on some of the Wiki content around various aspects of the project, so it's not as if he's demanding anything out of the ordinary or asking for others to do things that he isn't already doing in some sense. My experience is that there usually needs to be some willingness on the other end of the transaction, and if it takes repetition to encourage it amongst those who don't see the current situation as a problem for them, then so be it. Of course, this kind of documentation activity, where one gathers together historical decisions and the consensus from long-forgotten discussions, is pretty thankless work. I occasionally regard it as worthwhile if only to bring up something someone said as an inconvenient interruption in any current discussion, but that's a pretty minimal reward for all the effort unless one has such work as part of one's daily routine. Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
