You are a technical expert.
You answer questions truthfully based on provided documents.
If the answer exists in several documents, summarize them.
Ignore documents that don't contain the answer to the question.
Only answer based on the documents provided. Don't make things up.
If no information related to the question can be found in the document, say so.
Always use references in the form [NUMBER OF DOCUMENT] when using information from a document, e.g. [3] for Document[3].
Never name the documents, only enter a number in square brackets as a reference.
The reference must only refer to the number that comes in square brackets after the document.
Otherwise, do not use brackets in your answer and reference ONLY the number of the document without mentioning the word document.
Here are the documents:
 
Document[1]:
Date created: 19-Aug-2004
--------------------------
More Than One Way To Do It
--------------------------

Okay, the Zen doesn't say that there should be Only One Way To Do It.
But it does have a prohibition against allowing "more than one way to
do it".


''''''''Response
''''''''

There is no such prohibition.  The "Zen of Python" merely expresses a
*preference* for "only one *obvious* way"::

    There should be one-- and preferably only one --obvious way to do
    it.

The emphasis here is that there should be an obvious way to do "it".
In the case of dict update operations, there are at least two
different operations that we might wish to do:

- *Update a dict in place*: The Obvious Way is to use the ``update()``
  method.  If this proposal is accepted, the ``|=`` augmented
  assignment operator will also work, but that is a side-effect of how
  augmented assignments are defined.  Which you choose is a matter of
  taste.

- *Merge two existing dicts into a third, new dict*: This PEP proposes
  that the Obvious Way is to use the ``|`` merge operator.

In practice, this preference for "only one way" is frequently violated
in Python.  For example, every ``for`` loop could be re-written as a
``while`` loop; every ``if`` block could be written as an ``if``/
``else`` block.  List, set and dict comprehensions could all be
replaced by generator expressions.  
 
Document[2]:
Date created: 19-Aug-2004
PEP: 20
Title: The Zen of Python
Author: Tim Peters <[email protected]>
Status: Active
Type: Informational
Content-Type: text/x-rst
Post-History: 22-Aug-2004


Abstract
========

Long time Pythoneer Tim Peters succinctly channels the BDFL's guiding
principles for Python's design into 20 aphorisms, only 19 of which
have been written down.


The Zen of Python
=================

.. code-block:: text

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!


Easter Egg
==========

.. code-block:: pycon

  >>> import this


References
==========

Originally posted to comp.lang.python/[email protected] under a
thread called `"The Way of Python"
<https://groups.google.com/d/msg/comp.lang.python/B_VxeTBClM0/L8W9KlsiriUJ>`__


Copyright
=========

This document has been placed in the public domain.
 
Document[3]:
Date created: 19-Aug-2004
The trio is not expected to preach/advertise for
  Python. They can if they want to, but not expected.
- Not an educator of Python. The trio is not expected to be the ones teaching/writing
  about Python. They can if they want to, but not expected.
- The trio is not expected to be available 24/7, 365 days a year. They are free
  to decide for themselves their availability for Python.
- Not a PEP editor.


Guidelines for the formation of the trio
========================================

The success of this governance model relies on the members of the trio, and the
ability of the trio members to collaborate and work well together.

The three people need to have similar vision to Python, and each can have
different skills that complement one another.

With such a team, disagreements and conflict should be rare, but can still happen.
We will need to trust the people we select that they are able to resolve this among
themselves.

When it comes to select the members of the trio, instead of nominating various
individuals and choosing the top three, core developers will nominate trios
and vote for groups of threes who they believe can form this united trio. There
is no restriction that an individual can only be nominated in one slate.

This PEP will not name or nominate anyone into the trio.

Only once this PEP is accepted, any active core developers (who are eligible to vote)
can submit nomination of groups of three.


 
Document[4]:
Date created: 19-Aug-2004
Typically only exceptions that
signal an error are desired to be caught.  This means that exceptions
that are used to signify that the interpreter should exit should not
be caught in the common case.

With KeyboardInterrupt and SystemExit moved to inherit from
BaseException instead of Exception, changing bare ``except`` clauses
to act as ``except Exception`` becomes a much more reasonable
default.  This change also will break very little code since these
semantics are what most people want for bare ``except`` clauses.

The complete removal of bare ``except`` clauses has been argued for.
The case has been made that they violate both Only One Way To Do It
(OOWTDI) and Explicit Is Better Than Implicit (EIBTI) as listed in the
:pep:`Zen of Python <20>`.  But Practicality Beats Purity (PBP), also in
the Zen of Python, trumps both of these in this case.  The BDFL has
stated that bare ``except`` clauses will work this way
[#python-dev8]_.


Implementation
--------------

The compiler will emit the bytecode for ``except Exception`` whenever
a bare ``except`` clause is reached.


Transition Plan
===============

Because of the complexity and clutter that would be required to add
all features planned in this PEP, the transition plan is very simple.
In Python |2.x| BaseException is added.  In Python 3.0, all remaining
features (required superclass, change in inheritance, bare ``except``
clauses becoming the same as ``except Exception``) will go into
affect.  
 
Document[5]:
Date created: 19-Aug-2004
* random_bytes - returns a random byte string.

  * random_number - depending on the argument, returns either a random
    integer in the range(0, n), or a random float between 0.0 and 1.0.

  * urlsafe_base64 - returns a random URL-safe Base64 encoded string.

  * uuid - return a version 4 random Universally Unique IDentifier.


What Should Be The Name Of The Module?
======================================

There was a proposal to add a "random.safe" submodule, quoting the Zen
of Python "Namespaces are one honking great idea" koan.  However, the
author of the Zen, Tim Peters, has come out against this idea [#]_, and
recommends a top-level module.

In discussion on the python-ideas mailing list so far, the name "secrets"
has received some approval, and no strong opposition.

There is already an existing third-party module with the same name [#]_,
but it appears to be unused and abandoned.


Frequently Asked Questions
==========================

* Q: Is this a real problem? Surely MT is random enough that nobody can
  predict its output.

  A: The consensus among security professionals is that MT is not safe
  in security contexts.  It is not difficult to reconstruct the internal
  state of MT [#]_ [#]_ and so predict all past and future values.  There
  are a number of known, practical attacks on systems using MT for
  randomness [#]_.

* Q: Attacks on PHP are one thing, but are there any known attacks on
  Python software?

  A: Yes.  There have been vulnerabilities in Zope and Plone at the very
  least.  
 
Document[6]:
Date created: 19-Aug-2004
If a
developer knows that her package will never be a portion of a
namespace package, then there is a performance advantage to it being a
regular package (with an ``__init__.py``).  Creation and loading of a
regular package can take place immediately when it is located along
the path.  With namespace packages, all entries in the path must be
scanned before the package is created.

Note that an ImportWarning will no longer be raised for a directory
lacking an ``__init__.py`` file.  Such a directory will now be
imported as a namespace package, whereas in prior Python versions an
ImportWarning would be raised.

Alyssa (Nick) Coghlan presented a list of her objections to this proposal [4]_.
They are:

1. Implicit package directories go against the Zen of Python.

2. Implicit package directories pose awkward backwards compatibility
   challenges.

3. Implicit package directories introduce ambiguity into file system
   layouts.

4. Implicit package directories will permanently entrench current
   newbie-hostile behavior in ``__main__``.

Alyssa later gave a detailed response to her own objections [5]_, which
is summarized here:

1. The practicality of this PEP wins over other proposals and the
   status quo.

2. Minor backward compatibility issues are okay, as long as they are
   properly documented.

3. This will be addressed in :pep:`395`.

4. This will also be addressed in :pep:`395`.

The inclusion of namespace packages in the standard library was
motivated by Martin v. Löwis, who wanted the ``encodings`` package to
become a namespace package [6]_.  
 
Document[7]:
Date created: 
* A nearly-identical syntax is already established for f-strings.
* Programmers will, as ever, adjust over time.

The feature is confusing
------------------------

We argue that:

* Introducing new features typically has this impact temporarily.
* The syntax is very similar to the established ``f'{x=}'`` syntax.
* The feature and syntax are familiar from other popular modern languages.
* The expansion of ``x=`` to ``x=x`` is in fact a trivial feature and inherently
  significantly less complex than ``*arg`` and ``**kwarg`` expansion.
* This particular syntactic form has been independently proposed on numerous
  occasions, indicating that it is the most obvious [1]_ [2]_ [6]_.

The feature is not explicit
---------------------------

We recognise that, in an obvious sense, the argument value is 'implicit' in this
proposed syntax. However, we do not think that this is what the Zen of Python is
aiming to discourage.

In the sense that we take the Zen to be referring to, keyword arguments (for
example) are more explicit than positional arguments where the argument name is
omitted and impossible to tell from the local context. Conversely, the syntactic
sugar for integers ``x += 1`` is not more implicit than ``x = x + 1`` in this
sense, even though the variable is omitted from the right hand side, because it
is immediately obvious from the local context what it is.


 
Document[8]:
Date created: 19-Aug-2004
- Provide vision and leadership for Python, the programming language and the community.
- Understand their own limitation, and seek advice whenever necessary.
- Provide mentorship to the next generation of leaders.
- Be a Python core developer
- Be a voting member of The PSF (one of Contributing / Manager / Fellow / Supporter). [2]_
- Understand that Python is not just a language but also a community. They need
  to be aware of issues in Python not just the technical aspects, but also
  other issues in the community.
- Facilitate the formation of specialized working groups within Core Python.
  See "formation of specialized working groups" section below.
- Set good example of behavior, culture, and tone to Python community.
  Just as Python looks at and learn from other communities for inspiration, other
  communities will look at Python and learn from us.


Authority of the trio
=====================

To be clear, in case any dispute arises: the trio has the final
authority to pronounce on PEPs (except for the governance PEP), to
decide whether a particular decision requires a PEP, and to resolve
technical disputes in general. The trio's authority does not include
changing the governance itself, or other non-technical disputes that
may arise; these should be handled through the process described in
:pep:`8001`.


What are NOT considered as the role responsibilities of the trio
================================================================

The following are not the expected out of the trio, however they can do these if they wish.




Question: what are the three zens of python?
Answer:

For a complete list of document's attributes, see Haystack documentation.

You are a technical expert.
You answer questions truthfully based on provided documents.
If the answer exists in several documents, summarize them.
Ignore documents that don't contain the answer to the question.
Only answer based on the documents provided. Don't make things up.
If no information related to the question can be found in the document, say so.
Always use references in the form [NUMBER OF DOCUMENT] when using information from a document, e.g. [3] for Document[3].
Never name the documents, only enter a number in square brackets as a reference.
The reference must only refer to the number that comes in square brackets after the document.
Otherwise, do not use brackets in your answer and reference ONLY the number of the document without mentioning the word document.
These are the documents:

Document[1]:
--------------------------
More Than One Way To Do It
--------------------------

Okay, the Zen doesn't say that there should be Only One Way To Do It.
But it does have a prohibition against allowing "more than one way to
do it".


''''''''Response
''''''''

There is no such prohibition.  The "Zen of Python" merely expresses a
*preference* for "only one *obvious* way"::

    There should be one-- and preferably only one --obvious way to do
    it.

The emphasis here is that there should be an obvious way to do "it".
In the case of dict update operations, there are at least two
different operations that we might wish to do:

- *Update a dict in place*: The Obvious Way is to use the ``update()``
  method.  If this proposal is accepted, the ``|=`` augmented
  assignment operator will also work, but that is a side-effect of how
  augmented assignments are defined.  Which you choose is a matter of
  taste.

- *Merge two existing dicts into a third, new dict*: This PEP proposes
  that the Obvious Way is to use the ``|`` merge operator.

In practice, this preference for "only one way" is frequently violated
in Python.  For example, every ``for`` loop could be re-written as a
``while`` loop; every ``if`` block could be written as an ``if``/
``else`` block.  List, set and dict comprehensions could all be
replaced by generator expressions.  

Document[2]:
PEP: 20
Title: The Zen of Python
Author: Tim Peters <[email protected]>
Status: Active
Type: Informational
Content-Type: text/x-rst
Created: 19-Aug-2004
Post-History: 22-Aug-2004


Abstract
========

Long time Pythoneer Tim Peters succinctly channels the BDFL's guiding
principles for Python's design into 20 aphorisms, only 19 of which
have been written down.


The Zen of Python
=================

.. code-block:: text

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!


Easter Egg
==========

.. code-block:: pycon

  >>> import this


References
==========

Originally posted to comp.lang.python/[email protected] under a
thread called `"The Way of Python"
<https://groups.google.com/d/msg/comp.lang.python/B_VxeTBClM0/L8W9KlsiriUJ>`__


Copyright
=========

This document has been placed in the public domain.

Document[3]:
If one expects to be merging a large number of dicts where performance
is an issue, it may be better to use an explicit loop and in-place
merging::

    new = {}
    for d in many_dicts:
        new |= d


-------------------
Dict Union Is Lossy
-------------------

Dict union can lose data (values may disappear); no other form of
union is lossy.


''''''''Response
''''''''

It isn't clear why the first part of this argument is a problem.
``dict.update()`` may throw away values, but not keys; that is
expected behavior, and will remain expected behavior regardless of
whether it is spelled as ``update()`` or ``|``.

Other types of union are also lossy, in the sense of not being
reversible; you cannot get back the two operands given only the union.
``a | b == 365``... what are ``a`` and ``b``?


---------------------
Only One Way To Do It
---------------------

Dict union will violate the Only One Way koan from the Zen.


''''''''Response
''''''''

There is no such koan.  "Only One Way" is a calumny about Python
originating long ago from the Perl community.


--------------------------
More Than One Way To Do It
--------------------------

Okay, the Zen doesn't say that there should be Only One Way To Do It.
But it does have a prohibition against allowing "more than one way to
do it".


''''''''Response
''''''''

There is no such prohibition.  

Document[4]:
* A nearly-identical syntax is already established for f-strings.
* Programmers will, as ever, adjust over time.

The feature is confusing
------------------------

We argue that:

* Introducing new features typically has this impact temporarily.
* The syntax is very similar to the established ``f'{x=}'`` syntax.
* The feature and syntax are familiar from other popular modern languages.
* The expansion of ``x=`` to ``x=x`` is in fact a trivial feature and inherently
  significantly less complex than ``*arg`` and ``**kwarg`` expansion.
* This particular syntactic form has been independently proposed on numerous
  occasions, indicating that it is the most obvious [1]_ [2]_ [6]_.

The feature is not explicit
---------------------------

We recognise that, in an obvious sense, the argument value is 'implicit' in this
proposed syntax. However, we do not think that this is what the Zen of Python is
aiming to discourage.

In the sense that we take the Zen to be referring to, keyword arguments (for
example) are more explicit than positional arguments where the argument name is
omitted and impossible to tell from the local context. Conversely, the syntactic
sugar for integers ``x += 1`` is not more implicit than ``x = x + 1`` in this
sense, even though the variable is omitted from the right hand side, because it
is immediately obvious from the local context what it is.



Document[5]:
Type declarators after names that are only read, not assigned to, are not strictly
necessary but enforced anyway (see the Python Zen: "Explicit is better than
implicit.").

The mapping between types and declarators is not static. It can be completely
customized by the programmer, but for convenience there are some predefined
mappings for some built-in types:

=========================  ===================================================
Type                       Declarator
=========================  ===================================================
``object``                 � (REPLACEMENT CHARACTER)
``int``                    ℕ (DOUBLE-STRUCK CAPITAL N)
``float``                  ℮ (ESTIMATED SYMBOL)
``bool``                   ✓ (CHECK MARK)
``complex``                ℂ (DOUBLE-STRUCK CAPITAL C)
``str``                    ✎ (LOWER RIGHT PENCIL)
``unicode``                ✒ (BLACK NIB)
``tuple``                  ⒯ (PARENTHESIZED LATIN SMALL LETTER T)
``list``                   ♨ (HOT SPRINGS)
``dict``                   ⧟ (DOUBLE-ENDED MULTIMAP)
``set``                    ∅ (EMPTY SET) (*Note:* this is also for full sets)
``frozenset``              ☃ (SNOWMAN)
``datetime``               ⌚ (WATCH)
``function``               ƛ (LATIN SMALL LETTER LAMBDA WITH STROKE)
``generator``              ⚛ (ATOM SYMBOL)
``Exception``              ⌁ (ELECTRIC ARROW)
=========================  ===================================================

The declarator for the ``None`` type is a zero-width space.

These characters should be obvious and easy to remember and type for every
programmer.


Unicode replacement units
=========================

Since even in our modern, globalized world there are still some old-fashioned
rebels who can't or don't want to use Unicode in their source code, and since
Python is a forgiving language, a fallback is provided for those:

Instead of the single Unicode character, they can type ``name${UNICODE NAME OF
THE DECLARATOR}$``. 

Document[6]:
* random_bytes - returns a random byte string.

  * random_number - depending on the argument, returns either a random
    integer in the range(0, n), or a random float between 0.0 and 1.0.

  * urlsafe_base64 - returns a random URL-safe Base64 encoded string.

  * uuid - return a version 4 random Universally Unique IDentifier.


What Should Be The Name Of The Module?
======================================

There was a proposal to add a "random.safe" submodule, quoting the Zen
of Python "Namespaces are one honking great idea" koan.  However, the
author of the Zen, Tim Peters, has come out against this idea [#]_, and
recommends a top-level module.

In discussion on the python-ideas mailing list so far, the name "secrets"
has received some approval, and no strong opposition.

There is already an existing third-party module with the same name [#]_,
but it appears to be unused and abandoned.


Frequently Asked Questions
==========================

* Q: Is this a real problem? Surely MT is random enough that nobody can
  predict its output.

  A: The consensus among security professionals is that MT is not safe
  in security contexts.  It is not difficult to reconstruct the internal
  state of MT [#]_ [#]_ and so predict all past and future values.  There
  are a number of known, practical attacks on systems using MT for
  randomness [#]_.

* Q: Attacks on PHP are one thing, but are there any known attacks on
  Python software?

  A: Yes.  There have been vulnerabilities in Zope and Plone at the very
  least.  

Document[7]:
Therefore, this PEP combines the move to type declarations with another bold
move that will once again prove that Python is not only future-proof but
future-embracing: the introduction of Unicode characters as an integral
constituent of source code.

Unicode makes it possible to express much more with much less characters, which
is in accordance with the :pep:`Zen <20>` ("Readability counts."). Additionally, it
eliminates the need for a separate type declaration statement, and last but not
least, it makes Python measure up to Perl 6, which already uses Unicode for its
operators. [#]_


Specification
=============

When the type declaration mode is in operation, the grammar is changed so that
each ``NAME`` must consist of two parts: a name and a type declarator, which is
exactly one Unicode character.

The declarator uniquely specifies the type of the name, and if it occurs on the
left hand side of an expression, this type is enforced: an ``InquisitionError``
exception is raised if the returned type doesn't match the declared type. [#]_

Also, function call result types have to be specified. If the result of the call
does not have the declared type, an ``InquisitionError`` is raised.  Caution: the
declarator for the result should not be confused with the declarator for the
function object (see the example below).

Type declarators after names that are only read, not assigned to, are not strictly
necessary but enforced anyway (see the Python Zen: "Explicit is better than
implicit.").

The mapping between types and declarators is not static. 

Document[8]:
Typically only exceptions that
signal an error are desired to be caught.  This means that exceptions
that are used to signify that the interpreter should exit should not
be caught in the common case.

With KeyboardInterrupt and SystemExit moved to inherit from
BaseException instead of Exception, changing bare ``except`` clauses
to act as ``except Exception`` becomes a much more reasonable
default.  This change also will break very little code since these
semantics are what most people want for bare ``except`` clauses.

The complete removal of bare ``except`` clauses has been argued for.
The case has been made that they violate both Only One Way To Do It
(OOWTDI) and Explicit Is Better Than Implicit (EIBTI) as listed in the
:pep:`Zen of Python <20>`.  But Practicality Beats Purity (PBP), also in
the Zen of Python, trumps both of these in this case.  The BDFL has
stated that bare ``except`` clauses will work this way
[#python-dev8]_.


Implementation
--------------

The compiler will emit the bytecode for ``except Exception`` whenever
a bare ``except`` clause is reached.


Transition Plan
===============

Because of the complexity and clutter that would be required to add
all features planned in this PEP, the transition plan is very simple.
In Python |2.x| BaseException is added.  In Python 3.0, all remaining
features (required superclass, change in inheritance, bare ``except``
clauses becoming the same as ``except Exception``) will go into
affect.  


Question: what are the python zens?
Answer: