[Python-ideas] Top 10 Python modules that need a redesign Was: Geo coordinates conversion in stdlib

[anatoly techtonik]

On Sat, Apr 4, 2015 at 7:18 AM, Chris Angelico <rosuav at gmail.com> wrote:

> On Fri, Apr 3, 2015 at 7:33 PM, anatoly techtonik <techtonik at gmail.com>
> wrote:
> > Author is me, so you can ask directly. Why I didn't propose to redesign?
> > Because people will assume that somebody will need to write PEP and will
> > force me to write one. I don't believe in "redesign by specification"
> like
> > current PEP process assumes and people accuse me of being lazy and
> trolling
> > them, because I don't want to write the PEPs. Damn, I believe in
> iterative
> > development and evolution, and I failed to persuade coredevs that
> practices
> > digged up by people under the "agile" label is not some sort of corporate
> > bullshit. So it is not my problem now. I did all I am capable of.
>
> Why, exactly, is it that you don't want to author a PEP? Is it because
> you don't have the time to devote to chairing the discussion and all?
>

Don't have time and limited energy for such discussions. Switching to
discussion requires unloading all other information, remembering the
last point, tracking what people think. If you switch to discussion few
days later (because you don't have time) it needs more time to refresh
the data about the state. This is highly inefficient. Expanding on that
below..


> If so, you could quite possibly persuade someone else to. I'd be
> willing to take on the job; convince me that your core idea is worth
> pursuing (and make clear to me precisely what your core idea is), and
> I could do the grunt-work of writing. But you say that you "don't
> *believe in*" the process, which suggests a more philosophical
> objection. What's the issue, here? Why are you holding back from such
> a plan? *cue the troll music*
>

I don't believe in the process, right. I need data. How many people
actually read the PEPs through the end? How many say that they fully
support the PEP decision? How many people read the diffs after they've
read the PEP and can validate that none of their previous usage cases
were broken? I assume that None. That's my belief, but I'd be happy to
see that data that proves me wrong.

I also don't believe in the PEP process, because I can't even validate my
own usage cases using the layout of information proposed by the PEP.
PEP is a compression and optimization of the various usage cases
expressed in verbal form that is easy to implement, but not easy to
understand or argue about decisions. Especially about ones that seem
not-well-thought, because of the flawed process above.

I also have problems with reading specifications without diagrams and
with drawing concepts on a virtual canvas in my head. I also find that
some stuff in PEP is confusing, but there is no channel like StackOverflow
to ask question about design decisions. Maybe I am just a poor reader,
but that is the reality. I'd prefer cookbook to PEP approach.


> There are many Pythons in the world. You can't just hack on CPython
> and expect everything to follow on from there. Someone has to explain
> to the Jython folks what they'll have to do to be compatible. Someone
> has to write something up so MicroPython can run the same code that
> CPython does. Someone, somewhere, has to be able to ensure that
> Brython users aren't caught out by your proposed change. PEPs provide
> that. (They also provide useful pointers for the "What's New" lists,
> eg PEP 441.)
>
> So, are you proposing a change to Python? Then propose it.
>

The concept of "proposal" is completely fine. But the form is dated and
ineffective. And I can't deal with people who are afraid of new concepts
and can't see a rationale behind the buzzwords like agile, story, roadmap,
user experience. These are all the de-facto tools of the new generation,
and if somebody prefers to ride the steam engine, I don't mind, but me
personally don't have the lifetime to move so slow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150501/4e58b2bb/attachment-0001.html>