Skip to content
Projeler
Gruplar
Parçacıklar
Yardım
Yükleniyor...
Oturum aç / Kaydol
Gezinmeyi değiştir
C
cpython
Proje
Proje
Ayrıntılar
Etkinlik
Cycle Analytics
Depo (repository)
Depo (repository)
Dosyalar
Kayıtlar (commit)
Dallar (branch)
Etiketler
Katkıda bulunanlar
Grafik
Karşılaştır
Grafikler
Konular (issue)
0
Konular (issue)
0
Liste
Pano
Etiketler
Kilometre Taşları
Birleştirme (merge) Talepleri
0
Birleştirme (merge) Talepleri
0
CI / CD
CI / CD
İş akışları (pipeline)
İşler
Zamanlamalar
Grafikler
Paketler
Paketler
Wiki
Wiki
Parçacıklar
Parçacıklar
Üyeler
Üyeler
Collapse sidebar
Close sidebar
Etkinlik
Grafik
Grafikler
Yeni bir konu (issue) oluştur
İşler
Kayıtlar (commit)
Konu (issue) Panoları
Kenar çubuğunu aç
Batuhan Osman TASKAYA
cpython
Commits
0481d24d
Kaydet (Commit)
0481d24d
authored
Eki 02, 2001
tarafından
Tim Peters
Dosyalara gözat
Seçenekler
Dosyalara Gözat
İndir
Eposta Yamaları
Sade Fark
CVS patch [#466628] Doc changes for doctest patch (#466616), from
Tim Hochberg. Doctest no longer searches imported objects.
üst
fe1fd0e6
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
2 additions
and
25 deletions
+2
-25
libdoctest.tex
Doc/lib/libdoctest.tex
+2
-25
No files found.
Doc/lib/libdoctest.tex
Dosyayı görüntüle @
0481d24d
...
...
@@ -186,7 +186,7 @@ attempted.
See
\file
{
docstring.py
}
for all the details. They're unsurprising: the
module docstring, and all function, class and method docstrings are
searched, with the exception of docstrings attached to objects with private
names.
names.
Objects imported into the module are not searched.
In addition, if
\code
{
M.
__
test
__}
exists and "is true", it must be a
dict, and each entry maps a (string) name to a function object, class
...
...
@@ -211,9 +211,7 @@ By default, each time testmod finds a docstring to test, it uses a
doesn't change the module's real globals, and so that one test in
\module
{
M
}
can't leave behind crumbs that accidentally allow another test
to work. This means examples can freely use any names defined at top-level
in
\module
{
M
}
, and names defined earlier in the docstring being run. It
also means that sloppy imports (see below) can cause examples in external
docstrings to use globals inappropriate for them.
in
\module
{
M
}
, and names defined earlier in the docstring being run.
You can force use of your own dict as the execution context by passing
\code
{
globs=your
_
dict
}
to
\function
{
testmod()
}
instead. Presumably this
...
...
@@ -320,27 +318,6 @@ that triggered it.
\begin{enumerate}
\item
Sloppy imports can cause trouble; e.g., if you do
\begin{verbatim}
from XYZ import XYZclass
\end{verbatim}
then
\class
{
XYZclass
}
is a name in
\code
{
M.
__
dict
__}
too, and doctest
has no way to know that
\class
{
XYZclass
}
wasn't
\emph
{
defined
}
in
\module
{
M
}
. So it may try to execute the examples in
\class
{
XYZclass
}
's docstring, and those in turn may require a
different set of globals to work correctly. I prefer to do
``
\code
{
import *
}
''-friendly imports, a la
\begin{verbatim}
from XYZ import XYZclass as
_
XYZclass
\end{verbatim}
and then the leading underscore makes
\class
{_
XYZclass
}
a private name so
testmod skips it by default. Other approaches are described in
\file
{
doctest.py
}
.
\item
\module
{
doctest
}
is serious about requiring exact matches in expected
output. If even a single character doesn't match, the test fails. This
will probably surprise you a few times, as you learn exactly what Python
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment