On Sat, Apr 4, 2015 at 7:18 AM, Chris Angelico rosuav@gmail.com wrote:
On Fri, Apr 3, 2015 at 7:33 PM, anatoly techtonik techtonik@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.