Fabien Schwob wrote:
> Hello,
>
> I've often read new PEP that are published, and they are often about new
> additions to the core language. Why not using them with the standard
> library.
PEPs are used to make changes to the Standard Library - there's a bunch of
them listed in PEP 0. However, a formal PEP is often not required when there
is no significant dissent on c.l.p or python-dev that requires a BDFL
pronouncement - in such cases, the relevant module maintainer (or python-dev
collectively) may just accept the change and check it in. If there's no
controversy about a change, the overhead involved in making a PEP just isn't
worth it.
Making changes to the core language (especially syntax changes, but also
adding or significantly altering builtins) always requires a BDFL
pronouncement, is almost always controversial, and hence almost always
involves a full PEP.
(The only syntax change I know of that Guido has approved without a PEP is to
fix the minor irritation where keyword arguments can't come after a *argument.
However, even that should probably be made into a full PEP so that some
potential extensions to define keyword-only arguments and function default
values can be debated).
> Guido often say that he don't want to include new module that aren't
> widely used in the community. It's a good thing, but it lead to the
> creation of a lot of API incompatible modules. Why not using PEP in
> order to create standard API like the Java world do with JSRs (Java
> Specification Requests) ?
>
> What do you think about that ?
Some PEP's are already about exactly such issues - there are a few listed
under "Other Informational PEP's" in PEP 0.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
