5 ms·

That isn't practical. The PEP process is already exhausting and we aim to solicit feedback before the PEP is decided. By the time a beta is out, we're already

• coldtea 7y ago
  >That isn't practical. The PEP process is already exhausting and we aim to solicit feedback before the PEP is decided. By the time a beta is out, we're already in feature freeze and it is somewhat late in the game. Isn't it the case tho, that a PEP is usually just a document + discussion? I've seen someone having a PoC sometimes, but iirc it's not often readily available for use. Unless a feature is available to try (in alpha, beta, whatever), people can't really evaluate its ergonomics and how it affects or integrates with their use cases. I know that at least a few languages, including Go and Rust, don't commit to a feature after the relevant proposal is accepted, but have version you can try, that they might change and/or revoke. As someone in the Python community often says, "there must be a better way"! Maybe a PEP could include the stage where there is something like a "from __pep_proposals__ import new_feature". This might slow down the PEP rate (if every new candidate feature needs a trial implementation), but that's not necessarily a bad thing. Or it could just be required for larger changes to the language. (THE RaymondH? !!!)